FIPS 140-3: Security Levels, Validation, and 140-2 Sunset

FIPS 140-3 is the mandatory cryptographic module standard for U.S. federal agencies, published by the National Institute of Standards and Technology under authority of 44 U.S.C. ยง 3553. It defines four escalating security levels and a validation process that currently averages well over 18 months from lab submission to issued certificate.1Federal Register. Announcing Issuance of Federal Information Processing Standard (FIPS) 140-3, Security Requirements for Cryptographic Modules Any vendor selling cryptographic hardware or software to the federal government needs a current FIPS 140-3 certificate, and with the FIPS 140-2 sunset arriving on September 22, 2026, the runway for validation is short.2Computer Security Resource Center. FIPS 140-3 Transition Effort

The standard adopts ISO/IEC 19790:2012 for module security requirements and ISO/IEC 24759:2017 for testing, with federal-specific additions layered on through NIST’s SP 800-140 series.3National Institute of Standards and Technology. FIPS 140-3 Standards Modules are evaluated across eleven requirement areas, and the level a module claims determines how strictly each area is tested.

The Four Security Levels

Level 1

Level 1 is the baseline. A module has to use at least one approved cryptographic algorithm, but there are no specific physical security requirements beyond production-quality components. Software-only modules running on general-purpose computers usually target this level. Most commercial encryption libraries live here because it covers the widest range of deployments at the lowest hardware cost.

Level 2

Level 2 adds tamper-evidence: coatings, seals, or pick-resistant enclosures that leave visible signs if someone tries to open the module. It also introduces role-based authentication, so an operator has to prove membership in an authorized role before performing cryptographic operations. Many enterprise hardware security modules and network appliances sit at this level.

Level 3

Level 3 shifts from tamper-evidence to active tamper response. If someone breaches the physical boundary, the module has to detect the intrusion and automatically erase all sensitive cryptographic material, including plaintext keys and authentication credentials. Authentication is identity-based rather than role-based, so the module verifies the specific person requesting access. This is where most high-assurance hardware security modules sit, and it is the highest level most commercial vendors pursue.

Level 4

Level 4 is designed for physically hostile environments where sophisticated, well-funded attacks are a real concern. The module needs a complete protective envelope that detects tampering from every direction and responds immediately. It also has to handle environmental fault protection, staying secure under voltage or temperature extremes that an attacker might induce to create exploitable glitches. Very few commercial products carry Level 4 validation; the hardware engineering costs are steep and the use cases are narrow.

Who Has to Comply

Federal agencies are legally required to use FIPS-validated cryptographic modules when protecting sensitive but unclassified information, and that requirement flows down to contractors through procurement rules. NIST SP 800-171, which governs how contractors must protect Controlled Unclassified Information, explicitly requires FIPS-validated cryptography.

Defense contractors carry an additional obligation through DFARS clause 252.204-7012, which mandates compliance with SP 800-171 for anyone handling Covered Defense Information. The clause reaches nearly every defense contract other than those exclusively for commercial off-the-shelf items.4Department of Defense. Safeguarding Covered Defense Information – The Basics A cryptographic module without a current FIPS validation is effectively unsellable in the federal market and increasingly in the broader government contractor ecosystem.

Core Technical Requirements

Some requirements apply to every module regardless of level, though the bar rises as the level does.

Cryptographic Key Management

The standard governs the whole lifecycle of keys and other sensitive security parameters, from generation through storage, use, and destruction. Keys have to be generated using approved random number generators drawing from validated entropy sources. Storage has to prevent unauthorized disclosure or modification, and destruction has to be thorough enough that recovered hardware yields nothing useful.

Self-Testing

Every module has to run self-tests at startup and periodically during operation to verify that algorithms are producing correct results and that integrity checks pass. A failed self-test forces the module into an error state that blocks further cryptographic operations until the problem is resolved. This catches hardware degradation and software corruption before either can produce silently wrong output.5Computer Security Resource Center. FIPS 140-3 – Security Requirements for Cryptographic Modules

Non-Invasive Security

This requirement area targets side-channel attacks, where an adversary extracts secrets by observing the module’s physical behavior rather than breaking the math. Power analysis, electromagnetic emanation monitoring, and timing attacks all fall in this category. Modules either implement countermeasures or document which attacks lie outside the claimed security boundary. Non-invasive security did not exist as a standalone evaluation area under FIPS 140-2.

Operational Environment

For software and firmware modules, the operating system or platform has to be configured to prevent unauthorized modification of the cryptographic code. The standard also requires lifecycle assurance: the manufacturer has to follow documented procedures during design and production to keep vulnerabilities from being introduced before the product ships.

Approved Algorithms

A validated module can only use algorithms NIST has specifically approved. The current list, maintained in NIST SP 800-140C, covers these categories:6NIST Computer Security Resource Center. SP 800-140C – Approved Security Functions

  • Symmetric encryption: AES across multiple modes. Triple-DES was restricted to decryption and legacy verification only as of January 2024.
  • Digital signatures: DSA, RSA, ECDSA, and EdDSA, alongside the post-quantum signature algorithms ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+).7Computer Security Resource Center. FIPS 205 – Stateless Hash-Based Digital Signature Standard
  • Hash functions: the SHA-2 family (SHA-256, SHA-384, SHA-512, and variants) and SHA-3. SHA-1 remains listed but is restricted in practice.
  • Message authentication: HMAC, CMAC, KMAC, and authenticated encryption modes like AES-GCM and AES-CCM.
  • Lightweight cryptography: Ascon-Hash256, Ascon-AEAD128, and Ascon-XOF128 for resource-constrained environments.
  • Random number generation: entropy sources conforming to SP 800-90B and deterministic random bit generators conforming to SP 800-90A.

The addition of post-quantum algorithms is significant. NIST finalized its first three post-quantum standards in 2024, and modules can now include ML-DSA, SLH-DSA, and stateful hash-based schemes like LMS and XMSS. Vendors designing modules today should give serious thought to including post-quantum options.

The Validation Process

Validation runs through the Cryptographic Module Validation Program, a joint effort between NIST and the Canadian Centre for Cyber Security.8National Institute of Standards and Technology. Cryptographic Module Validation Program It has two phases: testing by an accredited lab, then government review of that lab’s findings.

Lab Testing

Before formal testing starts, a vendor has to contract with a Cryptographic and Security Testing laboratory accredited under the National Voluntary Laboratory Accreditation Program.9Computer Security Resource Center. CST Lab Accreditation and Fees These are private, third-party entities authorized to perform FIPS 140-3 conformance testing. NIST does not publish lab pricing, and rates vary by provider and module complexity, so vendors should get quotes from multiple accredited labs.

The lab needs a substantial documentation package. Two pieces matter most. The Security Policy describes the module’s security rules, cryptographic functions, roles and services, and the physical or logical boundary that defines it; after validation, a non-proprietary version is posted publicly on the NIST website.10National Institute of Standards and Technology. NIST Special Publication 800-140Br1 – Cryptographic Module Validation Program (CMVP) Security Policy Requirements The Finite State Model is a formal diagram of every operational state and transition, including startup, normal operation, error states, and key entry modes. Software and firmware submissions include source code. Hardware submissions include schematics and bills of materials.

NIST Review

After the lab submits its report, NIST and the Canadian Centre for Cyber Security perform a secondary review. The module’s status on the CMVP website shifts to “In Review” during this period, and back-and-forth between the lab and the reviewers is normal.

Timeline

The full run from lab submission to issued certificate has been averaging over 18 months, with some modules taking significantly longer depending on complexity and backlog. If a contract deadline depends on having a validated module, planning has to account for that.

NIST Fees

On top of lab fees, NIST charges cost recovery fees for its review. As of January 2026, the fees for a full new submission are:11National Institute of Standards and Technology. NIST Cost Recovery Fees

  • Level 1: $16,000
  • Level 2: $17,000
  • Level 3: $17,500
  • Level 4: $19,000

An extended cost recovery fee of $3,000 to $4,000 can apply if review requires additional time due to complexity or submission quality. Separate entropy source validations carry their own fees, up to $5,500 for a full submission.

Keeping a Certificate Current

A certificate is not the end. Patching a vulnerability, adding an algorithm, or updating firmware can require a follow-on submission, and the type depends on the scope of the change. The CMVP Management Manual defines the scenarios:12National Institute of Standards and Technology. FIPS 140-3 Cryptographic Module Validation Program Management Manual

  • Full Submission: new modules, or modifications too extensive for any lighter scenario.
  • Update: hardware, software, or firmware changes affecting security-relevant items where less than 30% of security functions were modified. NIST fee is $5,500, and a new sunset date is issued.
  • CVE Response: security patches for specific vulnerabilities, with no new features or cryptographic capabilities. NIST fee is $2,500.
  • Non-Security Relevant: changes that don’t affect any security-relevant items; the lab verifies that nothing security-critical was touched. NIST fee is $2,500.
  • Operational Environment Update: adding or changing tested operating systems or platforms without altering the module. NIST fee is $2,500.
  • Vendor Update: administrative changes such as updated contact information. No NIST fee.

Only full submissions and updates reset the sunset date. CVE responses, non-security-relevant changes, and operational environment updates inherit the original expiration, so a module approaching its five-year sunset cannot extend its life through a minor scenario alone.

Certificate Lifecycle and the Historical List

A validated module sits on the CMVP Active List for five years.8National Institute of Standards and Technology. Cryptographic Module Validation Program After that, it moves to the Historical List. Historical placement doesn’t revoke the certificate, but it signals that the validation documentation is outdated and may not reflect current guidance or algorithm transitions.

Federal agencies aren’t supposed to include Historical List modules in new system acquisitions, though they can make a risk-based decision to keep using them in existing legacy systems.13National Institute of Standards and Technology. Validated Modules In practice, most agencies treat Historical status as a strong signal to replace or re-validate.

The September 2026 FIPS 140-2 Sunset

On September 22, 2026, all remaining FIPS 140-2 certificates move to the Historical List regardless of when they were originally issued.2Computer Security Resource Center. FIPS 140-3 Transition Effort The CMVP stopped accepting new FIPS 140-2 submissions in April 2022, so the only path forward for any module that needs an active certificate is FIPS 140-3.

Because validations are averaging well over 18 months, any vendor that has not already submitted is behind schedule. Agencies relying on FIPS 140-2 validated modules should be inventorying their cryptographic dependencies now and procuring FIPS 140-3 replacements before the cutoff pushes the older modules onto the Historical List.