FIPS 140-3 How to handle security levels

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.

A claim overstates its scope when it describes a validated module as a validated containing product or service, or uses an algorithm certificate as proof of module validation. Keep each claim tied to its own certificate and boundary.

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.