Is FIPS 140-3 mandatory in Europe?

No. FIPS 140-3 is a US federal standard adopted by NIST, mandatory for cryptographic modules used by US and Canadian federal agencies. In Europe it is not a regulatory requirement, but it is frequently requested by financial-sector customers, defence buyers and large industrial operators as an assurance reference. For formal European needs, the EUCC scheme under the Cybersecurity Act and Common Criteria Protection Profiles remain the security-evaluation references recognised under Union law.

What is the difference between CMVP and CAVP?

CMVP (Cryptographic Module Validation Program) validates complete cryptographic modules, that is to say the hardware or software scope that implements the cryptographic services and its operational environment. CAVP (Cryptographic Algorithm Validation Program) validates individual algorithm implementations (AES, SHA, RSA, ML-KEM and so on) against test vectors. A CMVP certificate is always built on CAVP certificates for each approved algorithm used by the module. CAVP is a prerequisite, CMVP is the envelope.

How long does a FIPS 140-2 certificate stay valid?

NIST closed acceptance of new 140-2 submissions on 21 September 2021. Existing 140-2 certificates remain on the active list until 21 September 2026, after which they move to the historical list and may no longer be cited as an in-force validation for US federal procurement. From that date forward, every new validation must be issued under FIPS 140-3.

What are the four security levels of FIPS 140-3?

Level 1 is the lowest, requiring only that approved algorithms be used, with no specific physical requirement. Level 2 adds tamper-evident packaging and role-based authentication. Level 3 introduces tamper detection and tamper response together with identity-based authentication and strong separation of interfaces. Level 4 targets hostile environments and imposes an active detection envelope, environmental-failure protection and resistance to non-invasive attacks.

What is a non-invasive attack and how does FIPS 140-3 address it?

Non-invasive attacks extract information without physically altering the module, by analysing power consumption (DPA, Differential Power Analysis), electromagnetic emanations or execution timing. FIPS 140-2 did not explicitly address these attacks. FIPS 140-3, through ISO/IEC 19790:2012 and SP 800-140F, adds a dedicated chapter. Requirements rise in severity from level 1 to level 4 and impose, at the highest level, a documented side-channel evaluation.

Which post-quantum algorithms are approved under FIPS 140-3?

In August 2024, NIST standardised three post-quantum algorithms: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, formerly SPHINCS+) for signatures. These algorithms have been added to the SP 800-140C list of approved security functions and are eligible for CAVP validation, a prerequisite for inclusion in a CMVP-validated module. A progressive migration of modules to these primitives is expected over the 2025-2035 decade.

What role do CSTLs play and who accredits them?

CSTLs (Cryptographic and Security Testing Laboratories) are the accredited laboratories that run the tests leading to CMVP validation. Their accreditation is delivered by NVLAP (National Voluntary Laboratory Accreditation Program) at NIST, or by the equivalent Canadian body under CCCS. The vendor selects a CSTL and provides the module, documentation, source code where relevant, and the CAVP reports. The CSTL produces a test report submitted to CMVP, which issues the final validation.

Does FIPS 140-3 apply to software-only modules or only hardware?

Both. FIPS 140-3 recognises four operational-environment profiles: hardware module, software module, firmware module and hybrid module combining software and hardware. A software module running on a commercial platform (Windows, Linux, an RTOS) can be validated up to level 2 and sometimes level 3 depending on the applicable environment protections. Levels 3 and 4 generally require dedicated hardware or an integrated secure element.

FIPS 140-3: cryptographic module validation

Author Hugues Orgitello Last updated 27 May 2026 ~15 min read

Guide · FIPS 140-3

Published by NIST in March 2019 and in force since September 2019, FIPS 140-3 (Federal Information Processing Standard 140-3) defines the security requirements for cryptographic modules used by US and Canadian federal agencies. The associated validation programme, the CMVP (Cryptographic Module Validation Program), jointly operated by NIST and the Canadian CCCS, issues the certificates recognised on both markets. Beyond the federal perimeter, FIPS 140 has become the de facto assurance reference for cryptographic modules required by the financial sector, defence buyers, telecom operators and a growing share of industrial customers. This guide presents the 140-1 / 140-2 / 140-3 lineage, the division of roles between CMVP and CAVP, the four security levels, the approved algorithms listed in the SP 800-140 series, the FIPS 140-2 sunset timeline and the ongoing migration to post-quantum algorithms.

FIPS 140 lineage: thirty years of continuity

FIPS 140 is one of the oldest US federal standards on cryptography. Its first version, FIPS 140-1, was published in January 1994 by NIST (then NBS). The intent was straightforward: provide a public reference text on which the US federal administration could rely to procure cryptographic products without having to re-run an internal evaluation in each agency. The 1994 text already introduced the notion of a cryptographic module, of a logical boundary, of operator roles, and a four-level security structure.

FIPS 140-2 replaced 140-1 in May 2001. It extended the perimeter to pure software modules, added explicit requirements on random-number generation (PRNG and DRBG) and formalised an annex A listing approved algorithms. For close to twenty years, FIPS 140-2 was the standard of reference, with several thousand validated modules listed on the CMVP register.

FIPS 140-3 was published in March 2019, with the first day of acceptance of new submissions set to September 2020. Its main structural difference is its anchoring on international standards: the text no longer restates security requirements in its own wording, it points to ISO/IEC 19790:2012 (security requirements) and ISO/IEC 24759:2017 (test methods), adding national annexes in the form of SP 800-140A to SP 800-140F. This articulation opens the door to international convergence, since several other jurisdictions already apply ISO/IEC 19790 directly.

The implication for vendors is twofold. First, the substantive security text is no longer renegotiated periodically at the national level, which limits the risk of divergence between FIPS and the rest of the world. Second, the national annexes can evolve at their own rhythm without amending the underlying standard, which proved decisive in 2024 when the three post-quantum FIPS publications had to be integrated into the list of approved algorithms quickly.

Version	Publication	Status
FIPS 140-1	January 1994	Withdrawn
FIPS 140-2	May 2001	Submissions closed September 2021
FIPS 140-3	March 2019	In force, the only route for new submissions

CMVP, CAVP and CSTL: three acronyms to keep apart

The US-Canadian cryptographic validation system relies on three complementary entities, often blurred together in procurement documents.

The CMVP is the validation programme for complete cryptographic modules. It is jointly administered by NIST (US side) and the Canadian Centre for Cyber Security (CCCS, Canadian side). It issues the certificates published on the NIST "Cryptographic Module Validation List". The validation covers a precisely identified module: trade name, version number, firmware revision, operational platform and the cryptographic boundary delimited in the documentation.

The CAVP is the validation programme for algorithms taken individually. It issues a CAVP certificate for each implementation of an algorithm (AES-128, SHA-256, RSA-PSS, ECDSA P-256, ML-KEM-768 and so on) validated against test vectors. A CAVP certificate carries little weight on its own from a customer standpoint; it serves as a building block of a CMVP submission. Without a CAVP certificate for a given algorithm, that algorithm cannot be claimed as approved in a module.

The CSTL (Cryptographic and Security Testing Laboratory) is the accredited testing laboratory that runs the tests. NVLAP accreditation at NIST covers the laboratory's competence to perform the tests described in ISO/IEC 24759 and the SP 800-140 documents. The vendor contracts directly with the CSTL of its choice. The CSTL prepares the test report and submits it to CMVP, which issues the final validation after review.

Acronym	Object	Actor	Deliverable
CMVP	Validation of the complete module	NIST + CCCS	Module certificate on the CMVP register
CAVP	Validation of an algorithm	NIST	Algorithm certificate
CSTL	Accredited testing laboratory	NVLAP / private laboratory	Test report to CMVP

The four security levels

FIPS 140-3 keeps the historical four-level structure, aligned with ISO/IEC 19790. The gradation applies to eleven domains of requirements (specification, interfaces, roles and services and authentication, software/firmware environment, physical environment, operational environment, sensitive security parameter management, self-tests, life-cycle assurance, mitigation of other attacks). The table below summarises the dominant progression.

Level	Physical security	Authentication	Environment	Non-invasive attacks
1	No specific requirement	No authentication required	General-purpose platform acceptable	Not addressed
2	Tamper-evident packaging	Role-based authentication	OS evaluated against a protection profile	Qualitatively covered
3	Tamper-detect and tamper-respond	Identity-based authentication	Strong separation of interfaces	Documented testing
4	Active detection envelope, environmental protection (voltage, temperature)	Multi-factor authentication	Separated security domains	Side-channel evaluation

Level 1 corresponds to everyday software use on a general-purpose platform. The only structuring constraint is that the algorithms used be on the list of approved algorithms. An OpenSSL library running in FIPS mode and validated typically corresponds to this level.

Level 2 introduces a physical dimension: the module enclosure must show a visible evidence of any opening attempt (seal, paint, destructive marking). Role-based authentication distinguishes at minimum the cryptographic operator from the maintenance administrator. The operational software environment must be evaluated, typically against a Common Criteria protection profile.

Level 3 strengthens the physical requirement by mandating active detection of intrusion attempts coupled with a response: secret erasure, alarm, module lockdown. Authentication is based on the individual operator's identity. The interfaces used to input and output secret values must be physically separated from other interfaces. A cryptographic HSM (Hardware Security Module) card, or a smart card embedding a secure element, typically targets this level.

Level 4 is for physically hostile environments. The module must detect and react to environmental variations (out-of-range supply voltage, abnormal temperature, radiation). An active detection envelope surrounds the module, capable of erasing secrets in case of drilling, piercing or alteration. Authentication is multi-factor. Non-invasive attacks, explicitly added by FIPS 140-3, are subject to a documented evaluation at this level. A tactical HSM, a secure cartridge for smart munitions or a module integrated into a sovereign key infrastructure typically falls under level 4.

Module types: hardware, software, firmware, hybrid

FIPS 140-3 recognises four operational-environment profiles, defined in clause 7.2 of ISO/IEC 19790 and detailed in SP 800-140B.

Hardware module: dedicated physical implementation whose cryptographic boundary is hardware. A PCIe HSM, a Trusted Platform Module (TPM), a secure element embedded in a SIM card or a smart card all fall in this category. These modules can target any level, 1 through 4.
Software module: pure software implementation running on a general-purpose platform (commercial OS). The cryptographic boundary covers the module's code and data structures, the host OS being the evaluated operational environment but outside the boundary. Typical ceiling: level 1 or 2.
Firmware module: software implementation running on a constrained hardware environment, usually not field-reprogrammable (microcontroller, radio board, gateway). The boundary includes both the firmware and its execution hardware. Levels 1, 2, or 3 depending on the physical protections in place.
Hybrid module: combination of a software component and a hardware component, inseparable for the delivery of cryptographic services. A software library coupled to a secure element through a dedicated interface constitutes a hybrid module.

The choice of environment type is one of the structuring decisions of the submission. A late reclassification can force a new test campaign, since the scope of testing differs significantly across profiles.

In practice, the boundary between software and hybrid is the most contentious. A library that calls AES-NI instructions on x86 is generally accepted as software, the instructions being treated as a property of the operational environment. By contrast, a library shipped together with a specific accelerator chip designed for the cryptographic services, even if interfaced through standard system calls, will usually be reclassified as hybrid. Vendors who wish to retain a software-only classification should document, early in the design phase, that the module does not rely on a co-designed hardware component.

Approved algorithms: the SP 800-140 series

Under FIPS 140-2, approved algorithms were listed in annex A of the text. FIPS 140-3 has pulled this list out of the standard into a separate document, SP 800-140C ("CMVP Approved Security Functions"), updated independently in step with NIST publications. This modularity allows new algorithms (notably post-quantum ones) to be added without amending the main standard.

The SP 800-140 family covers the following domains:

SP 800-140A: modifications to ISO/IEC 24759 (test methods).
SP 800-140B: requirements on the Security Policy document.
SP 800-140C: approved security functions (cryptographic algorithms).
SP 800-140D: sensitive security parameters (keys, seeds, nonces).
SP 800-140E: approved key establishment.
SP 800-140F: non-approved services and functions.

SP 800-140C lists the families of algorithms accepted for a validated module. The table below summarises the main categories with their current status.

Category	Representative algorithms	Status
Symmetric encryption	AES (FIPS 197) in ECB, CBC, GCM, CCM, XTS modes	Approved
Legacy asymmetric encryption	RSA OAEP, RSA-PSS	Approved, transition monitored
Classical key exchange	DH, ECDH (NIST P-256, P-384, P-521 curves)	Approved
Digital signature	ECDSA, RSA-PSS, EdDSA (since FIPS 186-5)	Approved
Hash	SHA-2 (SHA-256, SHA-384, SHA-512), SHA-3	Approved
MAC	HMAC, KMAC, CMAC	Approved
Deterministic generators	Hash_DRBG, HMAC_DRBG, CTR_DRBG (SP 800-90A)	Approved
Post-quantum encapsulation	ML-KEM (FIPS 203, formerly Kyber)	Approved since 2024
Post-quantum signature	ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Approved since 2024
Legacy cryptography	DES, MD5, SHA-1 (signature)	Not approved

A module that implements algorithms outside the list is not necessarily disqualified: it can be validated by placing those algorithms outside the approved cryptographic perimeter, with an explicit mention in the security policy. The commercial risk lies elsewhere: a federal buyer may consider that the presence of a non-approved algorithm in the module affects the overall assurance.

Post-quantum migration: ML-KEM, ML-DSA, SLH-DSA

NIST concluded its post-quantum standardisation programme in August 2024, eight years after kick-off. Three FIPS standards were published and added to the list of approved algorithms:

FIPS 203 (ML-KEM): Module-Lattice-based Key Encapsulation Mechanism, derived from CRYSTALS-Kyber, intended to replace RSA and ECDH key exchange in the face of a possible cryptanalytically relevant quantum computer.
FIPS 204 (ML-DSA): Module-Lattice-based Digital Signature Algorithm, derived from CRYSTALS-Dilithium, for digital signatures.
FIPS 205 (SLH-DSA): Stateless Hash-based Digital Signature Algorithm, derived from SPHINCS+, hash-based signatures, slower but resting on a different security foundation (useful for defence in depth).

These algorithms are eligible for CAVP validation from late 2024. Their integration into CMVP-validated modules began in 2025. The trajectory expected by NIST is a progressive migration over the 2025-2035 decade, with a hybridisation period (classical plus post-quantum algorithms running side by side) during the transition. Several US federal agencies (NSA via the CNSA 2.0 memorandum, OMB via the associated circular) have published roadmaps fixing migration dates by system category.

For a European vendor targeting a mixed market (US federal plus global financial), the inclusion of a hybrid mechanism in the next generation of modules becomes as much a commercial argument as a technical one.

A second consideration concerns long-lived data. Information encrypted today with classical primitives and intercepted by an adversary can be stored against the day a quantum cryptanalytic capability emerges, a scenario commonly described as "harvest now, decrypt later". For data whose confidentiality requirement extends beyond ten or fifteen years (health records, defence archives, infrastructure-control telemetry), migration to post-quantum encapsulation is not a future concern but a present one. NIST guidance recommends that vendors targeting such sectors begin including ML-KEM in their key-exchange path during 2025 and 2026, even if the classical path remains active in parallel.

FIPS 140-2 to FIPS 140-3 transition

The transition timeline published by NIST has three milestones.

Date	Event
22 September 2020	First day of FIPS 140-3 submission acceptance
21 September 2021	Last day of FIPS 140-2 submission acceptance
21 September 2026	FIPS 140-2 certificates move to the historical list (sunset)

After 21 September 2026, already-issued 140-2 certificates do not vanish, but they leave the "Active" register for the historical list. For a federal buyer bound by the FIPS obligation, a product carrying only a 140-2 certificate after that date is at risk of being set aside. This deadline imposes on vendors a 140-3 revalidation schedule if the product is to remain on sale beyond it.

Revalidation is not a simple administrative migration. The gaps between 140-2 and 140-3 may require design changes: adding non-invasive coverage, strengthening the security policy, updating self-tests, aligning roles and authentication. For a software-only module, the effort remains tractable. For a hardware module at level 3 or 4, the duration between launch and certificate may reach eighteen to twenty-four months, with a non-negligible risk of partial redesign.

For vendors who are also examining a Common Criteria ISO/IEC 15408 route, part of the design artefacts can be reused, in particular the security policy document and the analysis of the cryptographic boundary.

Relationship to ISO/IEC 19790 and 24759

ISO/IEC 19790:2012 and the associated test text ISO/IEC 24759:2017 are the international standards on which FIPS 140-3 is anchored. The mapping is clear: FIPS 140-3 reproduces ISO/IEC 19790 without modifying it, and adds, through the SP 800-140 series, national annexes specifying the algorithms, services and security parameters accepted under the US-Canadian framework.

Text	Role
ISO/IEC 19790:2012	Security requirements for cryptographic modules
ISO/IEC 24759:2017	Test methods for the ISO/IEC 19790 requirements
FIPS 140-3	US national adoption of ISO/IEC 19790
SP 800-140A-F	National annexes on test methods and algorithms

This articulation has two practical consequences. First, a FIPS 140-3 validated module satisfies the ISO/IEC 19790 requirements by construction. Second, several jurisdictions outside North America (Japan with JCMVP, South Korea with KCMVP) that apply ISO/IEC 19790 directly may recognise, in whole or in part, a submission already prepared for CMVP, subject to local adaptations.

Common pitfalls

A few errors recur in cryptographic validation submissions.

Relying on a 140-2 certificate past September 2026. A product whose only certificate is 140-2 will become non-opposable to a federal buyer after the sunset. Planning the 140-3 revalidation at least eighteen months before that date avoids a commercial break.

Confusing algorithm and module validation. Holding CAVP certificates for AES, SHA and RSA does not constitute a FIPS 140 validation. CMVP requires a complete module submission; CAVP certificates are only one piece.

Mis-classifying the operational environment. A module declared as software but leaning on specific hardware (AES-NI extensions, cryptographic instructions of a microcontroller) may be reclassified as hybrid during instruction, with an expanded test scope.

Omitting the operational-environment specification. The security policy must list the evaluated platform precisely (OS, version, hardware). A different host OS in production leads the federal customer to view the module as not operating under FIPS regime.

Including a non-approved algorithm in the perimeter. A proprietary or non-listed algorithm must be placed explicitly outside the approved cryptographic perimeter, otherwise the module is rejected at validation.

Underestimating the cryptographic boundary documentation. The precise definition of this boundary conditions the entire submission. A poorly drawn boundary forces major rework during instruction.

Ignoring platform portability. A module validated on Linux x86_64 is not automatically valid on Linux ARM64 or Windows. Cross-platform revalidation is provided by the programme but involves non-trivial additional testing.

Synthetic comparison 140-2 vs 140-3

Dimension	FIPS 140-2 (2001)	FIPS 140-3 (2019)
Reference text	NIST-specific	ISO/IEC 19790 + ISO/IEC 24759 + national annexes
Approved algorithms	Integrated annex A	SP 800-140C, separate document
Non-invasive attacks	Limited coverage	Dedicated chapter, requirements per level
Self-tests	Implicit distinction	Explicit distinction "pre-operational" and "conditional"
Level 4 authentication	Identity-based	Multi-factor explicitly
International convergence	Weak	Strong, via ISO/IEC 19790
Submission acceptance status	Closed (September 2021)	Open
Certificate sunset	21 September 2026	No expiry

For a vendor: a practical approach

A FIPS 140-3 validation effort that is useful for commercialisation goes through five phases.

1. Opportunity decision. Identify the markets that require FIPS 140 (US federal, certain financial contracts, Canadian government procurement, some industrial exporters to the United States). Quantify the impact of the absence of a certificate. Validation has a significant cost and lead time, only justified by a documented commercial objective.

2. Module and level scoping. Define the cryptographic boundary, the environment type (hardware, software, firmware, hybrid) and the target level. This decision conditions the choice of hardware, the software architecture and the evaluation cost. Better to aim at an attainable level and iterate later than to fail on a poorly prepared level 4.

3. CSTL selection. The choice of laboratory influences the lead time, the cost and the quality of the dialogue with CMVP. Request several quotes, verify the laboratory's familiarity with the module's technical profile (hardware, embedded software, HSM).

4. Submission preparation. The bulk of the work. The Security Policy is the central document, public after validation. It describes the module, its roles, its services, its sensitive security parameters, its interfaces and its boundary. Internal documentation includes CAVP reports, algorithm specifications, hardware schematics, code listings for the highest levels.

5. Validation and maintenance. After validation, the module enters the CMVP register. Any non-trivial change (firmware version change, addition of a supported platform, change of cryptographic-component supplier) triggers a revalidation or a "letter of attestation" procedure depending on the nature of the modification. Life-cycle management is as demanding as the initial validation.

For the European radio product dimension, these decisions interact with RED obligations and the IoT cybersecurity requirements of EN 303 645, which do not duplicate FIPS 140-3 but belong to other reference frameworks. The glossary consolidates the acronyms CMVP, CAVP, CSTL and their international counterparts.

Outlook

Three trends shape the 2025-2035 decade for FIPS 140-3.

The first is generalised post-quantum migration. ML-KEM, ML-DSA and SLH-DSA are now standardised, but their effective deployment in validated modules is only beginning. Part of the existing 140-3 certificates will be amended to include them, and new submissions increasingly integrate a hybrid classical / post-quantum route.

The second is international convergence through ISO/IEC 19790. Direct adoption of ISO/IEC 19790 by several national schemes (Japan, Korea, partially Australia via the ASD gateway) opens the possibility of progressive mutual recognition. The CMVP, the Japanese JCMVP and the Korean KCMVP could over time bring their procedures closer.

The third is the consolidation of automated evaluation tools. CAVP vectors can now be executed through the ACVP (Automated Cryptographic Validation Protocol), enabling a module to be tested in interaction with a central NIST server. This automation cuts the algorithmic-phase lead time of the submission, without changing the CMVP instruction phase, which remains documentation-heavy.

For a European vendor, FIPS 140-3 is not a regulatory requirement for CE marking, but it remains an assurance reference frequently demanded contractually. The September 2026 sunset timeline imposes that for any cryptographic product in service, the vendor either holds an already-issued 140-3 certificate or maintains a documented revalidation trajectory.