green gradient background, "The Future of Application Security Is Already Here." and a read the report button.

Category: Technical Controls

Cryptographic Module Validation (FIPS 140-3)

Also known as: CMVP, FIPS 140-3, FIPS PUB 140-3, Cryptographic Module Validation Program, Security Requirements for Cryptographic Modules

Simply put

FIPS 140-3 is a U.S. government computer security standard that sets requirements for cryptographic modules—the hardware, software, or firmware components that perform encryption and related security functions. Rather than being validated automatically, a module must be tested and confirmed against the standard through the Cryptographic Module Validation Program (CMVP), a joint effort of the U.S. and Canadian governments. Validation under this program is how a module is recognized as meeting the standard's requirements. Readers should verify the current standard text and validation details against the official NIST source, as standards and program lists change over time.

Formal definition

FIPS 140-3 ('Security Requirements for Cryptographic Modules') is a U.S. government standard used to design, implement, and validate cryptographic modules that federal departments and agencies operate or that are operated on their behalf. The standard designates the Cryptographic Module Validation Program (CMVP), operated jointly by the U.S. and Canadian governments, as the validation authority; CMVP is the mechanism through which conformance is assessed and validated modules are listed. It is important to distinguish the standard (FIPS 140-3, which specifies the security requirements) from the validation program (CMVP, which determines and records whether a specific module conforms) and from a validated module itself (an individual product entry on CMVP's list). The evidence provided does not specify security levels, testing methodologies, effective or transition dates, or applicability outside the U.S. federal context; practitioners should consult the current FIPS 140-3 text and the CMVP validated-module search for authoritative, up-to-date details. This entry is informational and does not constitute compliance or legal advice; applicability to a particular module or procurement requires professional judgment.

Why it matters

For U.S. federal departments and agencies—and the vendors that supply them—the distinction between a cryptographic module that has been validated and one that merely claims to implement encryption is significant. FIPS 140-3 sets the security requirements for cryptographic modules, and the Cryptographic Module Validation Program (CMVP) is the mechanism through which a specific module is tested and confirmed against those requirements. A product's own assertion that it uses strong encryption is not the same as a CMVP-validated module: validation is recorded through the program, and a module either appears on the CMVP validated-module list or it does not. This matters because procurement, contractual, and internal security decisions in the federal context frequently turn on whether a module has actually been validated rather than on marketing claims.

Who it's relevant to

U.S. federal agencies and their contractors

The standard is expressly used in designing and implementing cryptographic modules that federal departments and agencies operate or that are operated on their behalf. Personnel responsible for procurement, security architecture, or vendor management in this context generally need to confirm whether a given module appears on the CMVP validated-module list rather than relying on a vendor's own claim. Applicability to a specific procurement requires professional judgment.

Cryptographic module vendors and product teams

Suppliers seeking to serve U.S. federal customers may need their modules tested and validated through CMVP so that the module is recorded on the validated-module list. Product and engineering teams should distinguish between implementing the requirements of FIPS 140-3 (the standard) and achieving CMVP validation (the recorded confirmation of conformance for a specific module).

Compliance officers and auditors

Those verifying that encryption components meet federal expectations should treat the standard, the validation program, and an individual validated module as distinct: FIPS 140-3 specifies the requirements, CMVP determines and records conformance, and a validated module is a specific entry on the program's list. Because standards and program lists change over time, verification should be made against the current NIST source and the CMVP search rather than against prior assumptions.

Organizations outside the U.S. federal context

The evidence describes FIPS 140-3 in relation to U.S. federal use; it does not establish applicability elsewhere. Organizations in other jurisdictions or sectors that encounter FIPS 140-3 as a contractual or customer requirement should confirm the scope and current requirements against authoritative sources, as this entry does not address use outside the federal context.

Inside CMVP

FIPS 140-3 Standard

A U.S. federal standard (aligned with ISO/IEC 19790 and ISO/IEC 24759) specifying security requirements for cryptographic modules. It is issued by NIST and applies to modules protecting sensitive but unclassified information in U.S. federal systems. FIPS 140-3 superseded FIPS 140-2; readers should verify the current status of legacy validations and transition timelines against official NIST sources.

Cryptographic Module Validation Program (CMVP)

A program jointly operated by NIST (U.S.) and the Canadian Centre for Cyber Security that validates cryptographic modules against the standard. Validation results in an entry on the CMVP validated modules list. Validation is distinct from certification of an entire product; it attests only to the tested module as configured and described.

Security Levels

The standard defines multiple ascending security levels, each imposing progressively more stringent requirements across areas such as physical security, authentication, and tamper resistance. The appropriate level depends on the deployment environment and risk profile; a higher level is not universally 'better' but reflects different threat assumptions.

Cryptographic Boundary and Approved Algorithms

Validation is scoped to a defined cryptographic boundary and to the use of approved (FIPS-validated) algorithms and modes. Operating a module outside its validated configuration or with non-approved algorithms generally places it outside the scope of the validation.

Testing by Accredited Laboratories

Conformance testing is performed by independent laboratories accredited under a recognized accreditation program before submission to the CMVP. This is a third-party assessment process rather than a self-declaration of compliance.

Common questions

Answers to the questions practitioners most commonly ask about CMVP.

Does a FIPS 140-3 validation certify that an entire product is secure?

No. FIPS 140-3 validation applies to a defined cryptographic module, not to the whole product, application, or system that incorporates it. The validation covers the specific module boundary, its cryptographic functions, and the conditions described in the module's security policy. A product may embed a validated module yet still be configured or deployed in ways that fall outside the validated boundary. Treat the validation as evidence about the module, not as an assurance of overall product security, and review the module's security policy to understand exactly what was tested.

Is FIPS 140-3 a law that all organizations must follow?

Not in itself. FIPS 140-3 is a standard for validating cryptographic modules rather than a generally applicable law. Its obligatory force typically arises where it is incorporated by reference, such as in certain U.S. federal procurement or agency requirements, or where a contract or sector-specific rule mandates validated modules. Outside those contexts it generally operates as a benchmark that organizations may adopt voluntarily. Whether it applies to a given organization depends on the applicable procurement rules, contractual terms, or sectoral requirements, which readers should verify against the current authoritative sources.

How does an organization confirm that a module it plans to use is validated?

Confirmation generally involves checking the official validation listing maintained under the validation program to locate the specific module, its certificate, and its associated security policy. It is important to match the exact module name, version, and configuration, because a validation applies only to the tested version and operational conditions. Readers should verify the current status of any certificate against the authoritative program listing, as entries are updated over time and validation states can change.

What is the difference between selecting a validated module and operating it in a validated manner?

Selecting a validated module addresses only part of the requirement. A module is generally validated to operate within specific conditions, algorithms, and configurations described in its security policy. Operating it in a validated manner means running the module within that documented boundary and approved mode. Configuration choices, enabled algorithms, or deployment outside the tested conditions may place operation outside the scope of the validation. Organizations should consult the module's security policy to understand the operational constraints that apply.

How should security levels within FIPS 140-3 be interpreted when planning an implementation?

FIPS 140-3 defines a graduated set of security levels reflecting increasing rigor in the requirements a module must meet. A higher level is not automatically necessary for every use case; the appropriate level generally depends on the sensitivity of the data, the threat environment, and any applicable procurement or contractual requirements. Selection is fact-specific, and organizations should align the chosen level with their risk assessment and applicable obligations rather than assuming a single level suits all deployments.

What should organizations consider about the lifecycle and versioning of a validation?

Validations are tied to specific module versions and can be affected by changes to the module, updates to the underlying requirements, or transitions in program status over time. A validation that is current today may later change state, and standards and validation schemes are periodically revised or superseded. Organizations should plan to monitor the status of the modules they rely on and verify against the latest authoritative program information rather than treating a validation as permanent. Application of these considerations to particular circumstances requires professional judgment.

Common misconceptions

FIPS 140-3 validation certifies that an entire product or system is secure.

Validation applies only to the specific cryptographic module as tested and configured within its defined cryptographic boundary. It does not certify the surrounding product, its deployment, or its overall security posture, and it says nothing about correct operational use.

FIPS 140-3 is a globally binding legal requirement.

FIPS 140-3 is a U.S. federal standard whose mandatory force applies primarily to U.S. federal agencies and their systems (with Canadian coordination via the CMVP). For other organizations and jurisdictions it is generally a voluntary or contractual requirement unless incorporated by a specific procurement rule, sector regulation, or agreement. Requirements differ across jurisdictions.

A validated module remains compliant no matter how it is deployed.

A module is validated only in its approved mode of operation and configuration. Using non-approved algorithms, operating outside the cryptographic boundary, or altering the tested configuration can place the module outside the scope of its validation.

Best practices

Confirm a module's current validation status and applicable security level directly on the CMVP validated modules list rather than relying on vendor marketing claims.

Verify that the module is deployed in its approved mode of operation, within its defined cryptographic boundary, and using only approved algorithms.

Determine whether FIPS 140-3 applies to your context as a legal, contractual, or voluntary requirement, and document the basis, noting that obligations differ by jurisdiction and sector.

Track the transition from legacy FIPS 140-2 validations and monitor NIST-published timelines, since certification schemes and their versions change over time.

Distinguish module validation from broader product certification and system compliance in internal documentation, so stakeholders do not overstate what the validation covers.

Consult the current authoritative NIST and CMVP sources, and engage qualified professionals, when applying these requirements to specific circumstances.