FIPS 140-3 FAQ

FIPS 140-3 has been the live CMVP path since submissions opened on 22 September 2020. According to the current CMVP overview page, FIPS 140-2 active modules remain acceptable for new systems only through 21 September 2026.

On 22 September 2026, FIPS 140-2 validations move to the Historical list. That does not erase existing deployments, but it does mean new procurement and product planning should center on FIPS 140-3.

FIPS PUB 140-3 specifies security requirements for cryptographic modules and defines four increasing, qualitative security levels. It covers 11 requirement areas including interfaces, roles and services, software or firmware security, operating environment, physical security, non-invasive security, SSP management, self-tests, lifecycle assurance, and mitigation of other attacks.

It is the baseline standard that federal agencies use when cryptography must provide actual protection instead of unvalidated plaintext-level assurance.

The CMVP FAQ separates these terms clearly. Compliant means a vendor believes its implementation meets the standard. Validated means the module has gone through CSTL testing and CMVP review and has a certificate.

If there is no certificate number, do not describe the module as CMVP validated. That distinction matters in procurement language, product pages, and customer attestations.

The Cryptographic Module Validation Program is a joint effort between NIST and the Canadian Centre for Cyber Security. Vendors work with independent accredited Cryptographic and Security Testing laboratories, and the CMVP validates the results.

Practically, that means the vendor owns the implementation and evidence pack, the CSTL executes test work against the current rules, and the CMVP reviews and issues the certificate.

Approved mode is an operational claim about how the module behaves. It defines which services are approved, which security functions are approved, whether self-tests have run as required, and how the module signals that approved state.

The current guidance treats approved mode as something you prove through implementation, documentation, and tests. If those three views do not match, the approved-mode claim is weak.

The boundary is the core scoping decision. It determines what is tested, what the Security Policy must describe, what SSP protections exist, and what services are actually inside the module.

Most expensive rework comes from boundary drift. If architecture, documentation, and tests disagree about what is inside the module, the submission becomes unstable fast.

The Security Policy is the public-facing and lab-critical description of the module. It should describe the boundary, interfaces, roles, services, approved mode, SSP handling, self-tests, and operational environment accurately.

In strong programs, the Security Policy is not a late-stage writing task. It is a controlled artifact tied directly to the tested build and evidence pack.

No. The CMVP FAQ is explicit that a product using an embedded validated module cannot claim that the overall product is itself validated solely because it contains that embedded module.

The safer claim is that the product uses an embedded validated module. The separate CMVP logo-and-phrases guidance also distinguishes between a validated module and a product containing a validated module.

Choose the level based on real deployment assumptions: physical access risk, operator model, environment control, and the impact of SSP compromise. Higher levels mean stronger proof obligations, not just more marketing value.

If you cannot explain why the deployment needs a particular level, the level choice is probably not stable enough for audit or lab review.

Sometimes yes, but only if the module keeps those capabilities clearly outside the approved-mode story and the applicable guidance allows that treatment. The dangerous pattern is exposing a cryptographic service that operators can confuse with an approved security function.

If a service looks like security to the caller, you should assume the lab will require clean separation, explicit documentation, and unambiguous mode signaling.

Treat the validated configuration like a controlled product line. Platform changes, compiler changes, dependency changes, and refactors can all affect the evidence story even when the feature set looks unchanged.

Set a validation-impact review gate for boundary changes, algorithm changes, SSP changes, and major environment changes so you do not drift away from the certified scope.

Continuously enough that your evidence pack always names the exact revision you implemented against. The local grounding set reflects an Implementation Guidance update dated 27 February 2026, and current CMVP work can turn on guidance details about embedding, service indicators, SSP handling, and self-tests.

Treat a guidance revision like a controlled change. Reassess the service map, Security Policy, and tests together instead of updating one artifact at a time.