Search every question across sub-FAQs

FIPS 140-3 defines four increasing qualitative security levels, Level 1 through Level 4, for cryptographic modules. A certificate can show an overall security level and section-level ratings; do not assume every requirement area has the same rating without checking the public certificate and Security Policy. The requirement areas include module specification, interfaces, roles and authentication, software and firmware security, operating environment, physical security, non-invasive security, sensitive security parameter management, self-tests, life-cycle assurance, and mitigation of other attacks.

A security-level statement should therefore identify the cryptographic module and the requirement areas or certificate evidence behind the statement. It should not be written as a broad claim that an entire product, platform, tenant, or organization is "FIPS Level 3" unless the public CMVP evidence supports exactly that scope.

Start from the module's intended use, not from a desired marketing label. FIPS 140-3 says the security level must be appropriate for the application and environment in which the module will be used and for the security services it will provide.

For procurement or architecture work, record the use case, exposed environment, cryptographic services, selected module, required overall or section-level rating, and whether CMVP already lists the module for that scope. FIPS 140-3 does not prescribe one universal level for every use case. The acquiring authority, system requirement, or contract must supply the needed assurance target, and the module evidence must then match it.

A strong evidence packet links the claim to the CMVP certificate, the module security policy, module version, tested operating environment, cryptographic boundary, approved services, and any CAVP algorithm certificates used by the module. The evidence should also show whether the module is active for the intended procurement or use case.

If the implementation depends on another validated module, document whether the relationship is bound or embedded. CMVP guidance treats those cases differently: a bound existing validated module must be at the same or higher security level as the module under test for all FIPS 140-3 sections except mitigation of other attacks, while an embedded module may be lower only when the submission demonstrates that the higher-level requirements are still met.

The most common mistake is changing the scope of the claim: a validated cryptographic module becomes a validated product, a product becomes a validated service, or an algorithm certificate becomes a module certificate. FIPS 140-3 evidence should keep those layers separate.

Another mistake is copying a supplier's security-level language without checking the exact certificate, module version, operational environment, and validation status. If those details do not match the deployed module, the public claim can be materially misleading even when the supplier has a real validation elsewhere.

Vendor affirmation is available only for specific cases described in CMVP Implementation Guidance. For SP 800-208 HSS, IG C.O permits it only when the implementation performs the required cryptographic algorithm self-tests, the underlying LMS operations and parameter sets have the required CAVP certificates, and the CSTL verifies each supported HSS operation through source-code review. The same IG preserves the separate state-management requirements in Section 8 of SP 800-208.

Do not describe vendor affirmation as a general validation status. The FIPS 140-3 standard says cryptographic modules are validated through CMVP, with testing by accredited CST laboratories, while CAVP addresses approved security function and sensitive security parameter generation and establishment method testing.

For SP 800-208 HSS, IG C.O lists concrete conditions rather than a self-attestation shortcut. If HSS key generation or signature generation is implemented, the underlying LMS key generation and LMS signature generation operations need CAVP certificates. If HSS signature verification is implemented, the underlying LMS signature verification operation needs a CAVP certificate.

The same IG requires every LMS parameter set used inside the HSS tree to have the applicable CAVP certificates. It also requires CSTL source-code review of each supported HSS operation against RFC 8554 Sections 6.1, 6.2, and 6.3, with the results documented in TE02.20.04 of the Test Report. This review supports the HSS vendor-affirmation path; it does not turn HSS into a separate CAVP-certified implementation.

Keep a compact evidence packet for each vendor-affirmed claim. It should identify the IG section, the module and version, the exact algorithm or key-generation method, the Security Policy table or disclosure, the CAVP certificates that remain required, and the CSTL or test-report evidence that the IG says must exist.

For SP 800-133 Rev. 2 key generation, IG D.H requires vendor affirmation for methods covered by Sections 4 and 6.3 when a symmetric key or seed for asymmetric key generation starts with a random bit string. The four Section 4 examples are informative; the approved-DRBG output and applicable independence requirements are normative. The Security Policy must describe each method, while the validation certificate has a CKG entry only when the module generates keys for symmetric-key algorithms.

Start with the validated cryptographic module and the service the operator invokes. FIPS 140-3 specifies requirements for cryptographic modules, and IG 2.4.C distinguishes an approved security service from other services that may run while the module is in an approved mode. Show-status, version, and other non-security services do not become approved security services merely because they are available in that mode.

For a customer, procurement, or audit answer, identify the specific module certificate and version, the service being called, the approved algorithm or process used by that service, and the operator-visible indicator that shows the service is approved. A broad statement that a product is "in FIPS mode" is not enough when the module can expose approved and non-approved services or use context-sensitive algorithms.

The evidence must let a reader trace the answer from a module certificate and Security Policy to the exact service behavior. IG 2.4.C requires the Security Policy to list approved and non-approved services with their details and applicable indicators. The module must provide an externally accessible, operator-verifiable indicator; Security Policy text can explain that indicator but cannot replace it.

Evidence should also show the treatment of non-approved algorithms. IG 2.4.A permits limited uses in approved mode only when the algorithm does not meet a FIPS 140-3 requirement, does not compromise or improperly share an approved algorithm's CSP, and cannot be confused with a security function. A non-approved security function that claims security is not made approved by a mode setting or disclaimer.

Most approved-mode mistakes come from treating the mode as a switch that validates every cryptographic operation. FIPS 140-3 and the CMVP guidance require a more precise answer: which module, which service, which approved security function, which indicator, and which Security Policy rule.