Key Points
- FIPS 140-3 is the current U.S. federal standard that defines security requirements for cryptographic modules used to protect sensitive government and regulated-industry data.
- The standard establishes four security levels, from basic software-only implementations at Level 1 to fully hardened modules with environmental attack protections at Level 4.
- The Cryptographic Module Validation Program (CMVP) is a joint NIST and Canadian Centre for Cyber Security program that certifies modules through accredited independent laboratories.
- FIPS 140-2 certificates move to historical status on September 21, 2026, making FIPS 140-3 the only accepted standard for U.S. government procurements after that date.
- For PKI deployments, FIPS 140-3 Level 3 is the threshold most commonly required to protect certificate authority private keys.
Federal agencies and their vendors operate under a straightforward rule: any cryptographic module handling sensitive data must be validated against a FIPS 140 standard.
That rule has not changed since 1994.
What has changed is the standard itself. FIPS 140-3, approved in 2019 and mandatory for new procurements since 2022, raises the bar on algorithm requirements, testing rigor, and documentation.
With the September 2026 deadline approaching, organizations that still rely on FIPS 140-2 validated modules need to understand what FIPS 140-3 requires, how the four security levels map to real deployment scenarios, and what the validation path looks like.
This article covers each of those areas in order, grounding every claim in National Institute of Standards and Technology (NIST) and Cryptographic Module Validation Program (CMVP) source documents.
What Is FIPS 140-3?
Federal Information Processing Standard (FIPS) 140-3 is the U.S. government computer security standard that specifies security requirements for cryptographic modules, covering the secure design, implementation, and operation of hardware, software, and firmware components that perform encryption, key management, and related functions.
The standard was approved by the Secretary of Commerce on March 22, 2019, became effective September 22, 2019, and replaced FIPS 140-2, which had governed cryptographic module requirements since 2001.
FIPS 140-3 differs from its predecessor in a significant structural way: instead of defining all module requirements inline, it incorporates two international standards by reference:
- ISO/IEC 19790:2012 (security requirements for cryptographic modules)
- ISO/IEC 24759:2017 (test requirements for cryptographic modules)
Federal agencies are required to use FIPS 140-3 validated modules when protecting sensitive but unclassified information. Beyond government, the standard applies to or is adopted by:
- Federal contractors handling controlled unclassified information (CUI)
- Financial services organizations, for compliance and audit purposes
- Healthcare organizations, for the same regulatory reasons
A Brief History of the FIPS 140 Series
The FIPS 140 series dates to January 11, 1994, when NIST published FIPS 140-1, developed by a government and industry working group that established the foundational framework of four security levels and 11 requirement areas.
FIPS 140-2 followed on May 25, 2001, updating the standard to account for changes in available technology and incorporating feedback from vendor, tester, and user communities. FIPS 140-2 became the basis for ISO/IEC 19790:2006.
Work on a third revision began in the early 2000s but stalled twice, with draft versions ultimately abandoned due to unresolved technical issues.
The final FIPS 140-3 publication in 2019 resolved those issues by aligning with the updated ISO/IEC international standards rather than attempting to enumerate all requirements independently.
The Four FIPS 140-3 Security Levels
FIPS 140-3 specifies four increasing, qualitative levels of security intended to cover a wide range of potential applications and environments. Each level builds on the one below it.
- Level 1: Basic Security
- Level 2: Tamper-Evidence and Role-Based Access
- Level 3: Tamper Resistance and Identity-Based Authentication
- Level 4: Highest Assurance
Choosing the right level depends on the sensitivity of the data being protected and the physical environment where the module operates.
Level 1: Basic Security
Level 1 is the minimum threshold. Modules at this level must use NIST-approved cryptographic algorithms but face no requirements for physical security mechanisms or complex access controls.
Software libraries running in a general-purpose operating system on standard PC hardware can qualify at Level 1. This tier covers SaaS applications and containerized services where the operating environment itself provides the physical boundary.
Level 2: Tamper-Evidence and Role-Based Access
Level 2 adds two requirements that Level 1 omits:
- Tamper-evident seals or coatings on hardware
- Role-based access controls that verify a user holds a valid role before granting access to security functions
The tamper-evidence requirement means that any unauthorized physical access leaves a visible trace. Level 2 is common in mid-tier appliances and healthcare applications.
Level 3: Tamper Resistance and Identity-Based Authentication
Level 3 moves from detecting tampering to preventing it. Modules must include mechanisms that make physical access to security parameters difficult and that zeroize (erase) sensitive data if tampering is detected.
Level 3 also requires identity-based authentication, rather than role-based authentication, and stricter separation between the module’s interfaces and its critical security parameters.
For public key infrastructure (PKI) deployments, Level 3 is the threshold that matters most. Hardware security modules (HSMs) protecting certificate authority (CA) private keys are commonly validated at Level 3, and the CA/Browser Forum Baseline Requirements reference FIPS 140-2 Level 3 (now the functional equivalent under FIPS 140-3) for online subordinate CA keys.
Level 4: Highest Assurance
Level 4 provides the strongest physical security defined by the standard. Modules at this level must detect and respond to environmental attacks, including voltage and temperature variations, and must zeroize all sensitive data immediately upon any breach attempt.
This level is used almost exclusively in defense, intelligence, and high-value financial environments where the consequences of a key compromise are severe.
The 11 Requirement Areas
FIPS 140-3 (through ISO/IEC 19790) specifies four security levels for each of 11 distinct requirement areas. Every module submission must address all 11 areas, and the level attained in each area can differ from the overall module level.
The 11 areas are:
- Cryptographic module specification: Defines what the module is, its boundary and what security functions it provides
- Cryptographic module interfaces: Covers data input, data output, control input, status output, and control output interfaces
- Roles, services, and authentication: Specifies which roles (such as crypto officer) are required and how authentication is performed
- Software/firmware security: Addresses the integrity of the module’s software and firmware components, including approved integrity techniques
- Operating environment: Covers the software operating environment and any OS-level security requirements
- Physical security: Addresses enclosures, tamper evidence, and tamper resistance depending on the level
- Non-invasive security: Governs mitigation of non-invasive attacks such as side-channel, power analysis, timing, and electromagnetic attacks
- Sensitive security parameter management: Governs the generation, distribution, storage, entry, output, and destruction of keys and other sensitive security parameters
- Self-tests: Mandates pre-operational and conditional tests to verify correct operation throughout the module’s lifecycle
- Life-cycle assurance: Covers documentation and development processes that demonstrate the module was designed, implemented, and maintained securely
- Mitigation of other attacks: Addresses attacks not covered by the other requirement areas, where no testable requirements are currently specified
FIPS 140-3 vs. FIPS 140-2: Key Differences
The structural shift from self-contained requirements to ISO/IEC alignment is the most visible change, but several technical differences also apply.
| Area | FIPS 140-2 | FIPS 140-3 |
| Standard framework | Self-contained NIST document | References ISO/IEC 19790:2012 and ISO/IEC 24759:2017 |
| Module types | Primarily hardware | Hardware, software, firmware, hybrid software, hybrid firmware |
| Interfaces | Four logical interfaces | Five logical interfaces (adds control output) |
| Self-testing | Startup tests only | Startup tests plus conditional and runtime checks |
| Authentication | Crypto officer and user roles, maintenance role optional | Only crypto officer role required |
| Algorithm rules | “Allowed” and “Approved” algorithms | Approved-only; “Allowed” category eliminated |
| Side-channel testing | Required at Levels 3 and 4 | Required at all four levels |
| International alignment | Limited | Single validation accepted internationally via ISO/IEC |
The elimination of the “Allowed” algorithm category has practical consequences. Algorithms that were permitted under FIPS 140-2 in some configurations are no longer acceptable under FIPS 140-3 unless they appear on the NIST Approved list.
Organizations upgrading modules need to audit their algorithm usage before initiating a new validation submission.
The CMVP Validation Process
The Cryptographic Module Validation Program is the joint NIST and Canadian Centre for Cyber Security (CCCS) initiative that certifies modules against FIPS 140-3. The program is open to any vendor; validated modules can be used by U.S. and Canadian federal agencies and accepted across other regulated sectors.
CMVP cannot be self-attested. An accredited laboratory performs all testing, and accreditation is managed through the National Voluntary Laboratory Accreditation Program (NVLAP).
The validation path follows three phases:
- Scoping: The vendor defines the module boundary, identifying which hardware, software, and firmware components fall within scope. For containerized or software-only modules, this step is more complex and must document entropy sources clearly.
- Lab submission and testing: The vendor submits the module along with detailed documentation on algorithms, entropy sources, self-tests, and role definitions to a cryptographic and security testing laboratory (CSTL). The lab conducts conformance testing against ISO/IEC 24759.
- CMVP review and certification: The CSTL submits its test report to CMVP. CMVP reviews the report, resolves any comments with the lab, and issues a validation certificate. The module is then listed on the public CMVP validated modules registry.
The validation process is lengthy. Planning for several years from initial submission to certificate issuance is common. Once validated, a module is placed on the active list for five years.
As of September 22, 2020, CMVP began accepting FIPS 140-3 submissions. New FIPS 140-2 submissions were no longer accepted after April 1, 2022.
The September 2026 Deadline
September 21, 2026 is the compliance date every procurement and security team should mark. On that date, all active FIPS 140-2 validations move to the historical list. Modules on the historical list are no longer considered currently validated for new system deployments by U.S. federal agencies.
This deadline affects the full supply chain.
Vendors selling cryptographic products to federal agencies, contractors handling sensitive federal data, and technology providers subject to federal procurement requirements all need FIPS 140-3 validated modules in place before that date.
Organizations in financial services and healthcare that use FIPS 140-2 compliance as an audit checkpoint should begin planning transitions now, given the multi-year validation timeline.
FIPS 140-3 and PKI: Why Validation Level Matters
For organizations running public key infrastructure, FIPS 140-3 is not an abstract compliance checkbox. The cryptographic modules that protect certificate authority private keys are among the most sensitive components in an enterprise security stack.
A compromised CA private key allows an attacker to issue fraudulent certificates for any identity the CA covers.
Hardware security modules protecting root CA and subordinate CA private keys are typically evaluated at FIPS 140-3 Level 3 or higher.
- At Level 3, the tamper-resistance and zeroization requirements ensure that physical access to the HSM does not yield the underlying key material.
- At Level 2, validation may suffice for lower-sensitivity applications, but not for CA key protection.
SecureW2 PKI infrastructure addresses this directly. The JoinNow Dynamic PKI platform uses HSM-backed private key protection designed for environments where the underlying cryptographic infrastructure must meet strict validation requirements.
These guides offer more details:
- The SecureW2 HSM private key protection page covers how private keys are stored and protected within the platform.
- For organizations architecting their PKI from the ground up, the certificate authority design and deployment guide covers how validation requirements map to deployment decisions.
If your organization runs an internal certificate authority, understanding what a certificate authority is and how the underlying module validation requirements apply to CA key management is the right starting point before any FIPS 140-3 validation engagement.
FIPS 140-3 Compliance for Your Organization
With the September 2026 deadline approaching and validation running multi-year, the path to FIPS 140-3 compliance comes down to a few concrete steps:
- Inventory your cryptographic modules. Catalog every module in your environment and check each against the CMVP validated modules list.
- Flag anything on a FIPS 140-2 certificate. Those modules stay valid through September 2026 but need a validated 140-3 successor in place before that date.
- Engage an NVLAP-accredited CSTL early. Scope the module boundary, audit algorithm usage against the Approved-only requirement, and plan the documentation package before the CMVP review cycle begins.
For PKI environments, the module protecting your CA private key is the single highest-priority validation target. JoinNow Dynamic PKI provides HSM-backed key protection and the certificate-based authentication modern networks require — including issuance for 802.1X network access — in a cloud-native deployment, without standing up on-premises CA infrastructure.
Schedule a demo to see how SecureW2 PKI infrastructure handles FIPS-aligned key protection in a cloud-native deployment.
Frequently Asked Questions
What is FIPS 140-3 and who needs to comply?
FIPS 140-3 is the current U.S. federal standard specifying security requirements for cryptographic modules. Compliance is mandatory for U.S. federal agencies and their contractors handling sensitive but unclassified information. Financial institutions, healthcare organizations, and critical infrastructure operators widely adopt the standard for audit and regulatory purposes, even when not directly mandated by a federal contract.
What happens to FIPS 140-2 certificates after September 2026?
On September 21, 2026, all active FIPS 140-2 module certificates move to the historical list. Modules on the historical list are no longer accepted for new U.S. federal government deployments. Organizations relying on FIPS 140-2 validated modules for compliance documentation should confirm with their legal and compliance teams how their specific regulatory frameworks treat historical-status certificates after that date.
What FIPS 140-3 level is required for certificate authority key protection?
Certificate authority private keys, particularly for root and online subordinate CAs, are commonly protected by HSMs validated at FIPS 140-3 Level 3 or higher. Level 3 requirements for tamper resistance and zeroization align with the sensitivity of CA key material: a compromised CA key allows issuance of fraudulent certificates across the entire PKI hierarchy. Level 2 validation may be acceptable for lower-sensitivity cryptographic operations, but not for CA key storage.
How much does FIPS 140-3 validation cost?
FIPS 140-3 validation costs vary widely based on module complexity, but organizations should budget for both direct lab fees and internal engineering time. Testing through an accredited laboratory typically runs into the tens of thousands of dollars, and the multi-year timeline adds significant staff cost for documentation and remediation. For most organizations, buying a pre-validated module from a vendor is far more economical than validating one in-house.
Can I use a FIPS 140-3 validated module without enabling FIPS mode?
Having a validated module and operating it correctly are two different things. A module can be FIPS 140-3 validated, but it only provides FIPS-compliant protection when configured to run in its approved mode of operation. Using a validated module with non-approved settings or algorithms does not satisfy compliance requirements — the validation covers the module as tested, not every possible configuration of it.
Does FIPS 140-3 apply outside the United States?
Yes, in two senses. The CMVP is jointly run by the U.S. (NIST) and Canada (CCCS), so validation is recognized in both countries. More broadly, because FIPS 140-3 references the international ISO/IEC 19790 standard, a single validation carries weight in other jurisdictions that recognize that standard, which is one of the practical benefits of the 140-3 alignment over 140-2.
What is the difference between FIPS 140-3 validated and FIPS 140-3 compliant?
"Validated" means a module has been tested by an accredited lab and issued a CMVP certificate listed on the public registry. "Compliant" is a looser, often self-asserted claim that a product uses FIPS-approved cryptography without necessarily holding a certificate. For federal procurement, only validated modules count — "compliant" language without a CMVP certificate number should be treated with caution.
