FIPS 140-3 FAQ

FIPS 140-3 is a U.S. federal cryptographic-module standard administered through CMVP by NIST and the Canadian Centre for Cyber Security. U.S. federal departments and agencies must use it when cryptographic protection is required for sensitive information, including modules operated for them under contract. Other organizations may require a validated module through procurement terms, customer controls, or deployment rules, but FIPS 140-3 does not automatically apply to every private product that uses cryptography.

First identify the specific cryptographic module claimed for the FIPS 140-3 use case, the agency or customer requirement that creates the need, and the module certificate or validation evidence supporting the claim. The buyer or agency defines the requirement, the vendor identifies the module and evidence, an accredited CST laboratory tests a submitted module, CMVP issues the validation decision, and the buyer or operator checks the procured version and Security Policy.

No. A CAVP certificate validates a cryptographic algorithm implementation; a CMVP certificate validates a cryptographic module. The CMVP implementation guidance separates these concepts and says the algorithm certificate identifies the validated algorithm implementation and tested operational environment, while the module certificate identifies the validated module and tested operational environment.

For evidence review, treat CAVP certificates as inputs to a module-validation case. They do not replace the CMVP module certificate, the module security policy, or the validation boundary that explains how the algorithms are used by the module.

A module-boundary answer should identify what is inside the cryptographic module, what is outside it, and which services, roles, interfaces, algorithms, sensitive security parameters, self-tests, and operational environments are part of the validated claim. This matters because FIPS 140-3 evaluates the secure design, implementation, and operation of a cryptographic module, not every surrounding product component.

If the module embeds or binds to another validated module, the evidence must keep the implementation under test separate from the existing validated module. The CMVP guidance says the security policy and validation test report must identify the existing module by name, certificate number, and version, and clearly separate services, algorithms, SSPs, self-tests, and zeroisation mechanisms.

Approved-mode claims should be tied to the module Security Policy, the service behavior that indicates approved use, and the certificates for the algorithms actually used by the module. Under IG 2.4.C, the required indicator is for each approved security service, not merely for the module's general mode. One API can implement several services depending on its parameters, and one service can call several APIs, so evidence must follow the service the operator invokes.

Operational-environment evidence should match the certificate claim. The CMVP guidance says a validated algorithm implementation embedded in a module must be unmodified and tested in an operational environment that is identical to, or fully included in, the module testing environment. For software modules, the listed environment includes operating system, platform, processor, and hypervisor when used.

A vendor- or user-affirmed port is a separate case. If the Management Manual's porting rules are met, the module can be affirmed on an environment that was not part of validation testing, but CMVP makes no statement about correct operation or generated-key strength on an environment not listed on the certificate. For vendor affirmation, the Security Policy and claim should label that environment as affirmed, not tested; for user affirmation, the claim should make that distinction.

A useful response should include the module name and version, current CMVP certificate record, Security Policy, claimed security levels, operational environment, approved and non-approved services, algorithm certificates, and any caveats that affect the deployment. Check whether the supplied product contains that exact module and configuration. For federal procurement, NIST directs users to the CMVP validated modules list and says the Historical list is for reference rather than procurement decisions.

If the module relies on another validated module, include the bound or embedded module evidence and the security-policy markings that show exactly which functions came from that module. If the deployment changes software, firmware, processor architecture, operating system, hypervisor, boundary, or algorithm implementation, do not reuse the old evidence without checking whether the certificate scope still matches.

A standard FIPS 140-3 validation is normally placed on the Active list for five years. An Interim Validation is Active but has a two-year sunset because CMVP reviewed the submission for completeness after an accredited CST laboratory fully tested it. A programmatic transition, sunset date, or dependency on another validation can move a record to Historical earlier. Historical means the record is no longer current for new procurement; it is not the same as revocation, and an agency may document its own continued-use risk decision.

Revoked means the validation is no longer valid and may not be cited to demonstrate FIPS 140 conformity. Check the live CMVP entry before a purchase, release, audit response, or trust-center update, record the status-check date and sunset date, and reopen the review when a dependency or algorithm transition changes.