FIPS 140-3 Applicability Test

Federal agency use is the direct applicability trigger in FIPS 140-3. The standard applies to federal agencies that use cryptography-based security systems to protect sensitive information and to cryptographic modules operated by federal departments and agencies or for them under contract.

For private or commercial organizations, the standard is available for adoption, but that does not make it a universal legal requirement. Treat commercial use as applicable when a customer requirement, procurement clause, contract, internal assurance policy, or market claim calls for FIPS 140-3 validated cryptography. The CMVP is jointly operated by NIST and the Canadian Centre for Cyber Security, and the FIPS publication states that validated modules are accepted by U.S. and Canadian federal agencies for their respective sensitive-information uses.

Assign the decision to the actor who controls the requirement. The agency or buyer states whether validated cryptography is required; the product or module vendor identifies the implementation and supplies its evidence; an accredited CST laboratory tests a module submitted for validation; CMVP reviews the submission and issues the public validation record; and the buyer or operator checks that the procured version and deployment match that record and its Security Policy.

FIPS 140-3 is not a whole-product security label. It covers cryptographic modules, including hardware, software, firmware, or combinations of those implementations. The applicability test should therefore identify the module boundary before discussing certificates, algorithms, or customer claims.

If the claim names a product, cloud service, appliance, library, or platform, identify the module that provides the cryptographic services. Without an identifiable module boundary, record an unresolved scope claim and request boundary evidence instead of describing the product as "FIPS 140-3 compliant."

After the module boundary is clear, decide whether the claimed FIPS 140-3 security level fits the application and environment. FIPS 140-3 provides four qualitative security levels. The selected level has to be appropriate for how the module will be used and for the services it provides, not simply copied from a nearby certificate.

Also check whether the module uses approved security functions for the services being claimed. A module can contain code paths or algorithms that are not part of an approved service, so the applicability record should identify which services are in the approved mode and which are not claimed for FIPS 140-3 purposes.

The same validation record can support different products only when each deployment stays within the module identity, boundary, version, operational-environment, service, and caveat conditions stated by CMVP. Start with the actual deployment rather than the supplier's product category.

For every pattern, the buyer names the required protection and checks the public record; the product vendor maps its build and configuration to the validated module; the module vendor and CST laboratory own validation or revalidation evidence; and the operator keeps the approved-mode and environment settings in force. A change to any of those facts reopens the decision.

A FIPS 140-3 applicability decision is only useful if it points to validation evidence that matches the module and use case. FIPS 140-3 says cryptographic modules validated under the CMVP are considered conforming to the standard. CMVP guidance also explains that algorithm validation certificates identify the implementation and tested operational environment.

For procurement and customer assurance, the evidence should identify the CMVP certificate, module name and version, tested operational environment, any separately identified vendor-affirmed environment, Security Policy, relevant CAVP certificates, and certificate caveats. The CMVP Historical list should not be used for a new procurement decision. Historical is not the same as Revoked: an agency may document a risk decision for continued use of a Historical module, while a Revoked validation may not be cited to show FIPS 140 conformity.

Use the fields below to turn the applicability test into an evidence record, supplier questionnaire, or procurement note. The record should show why FIPS 140-3 applies, what module is in scope, which evidence supports the claim, and which limits remain.

Recommended fields: use-case trigger; customer or agency requirement; product or service name; cryptographic module name and version; module type; boundary summary; operational environment; claimed security level; CMVP certificate number and status; Security Policy location; relevant CAVP certificate numbers; approved services; non-approved or not-claimed functions; certificate caveats; procurement decision; unresolved questions.

A weak applicability answer usually overstates what FIPS 140-3 validates. The standard and CMVP program focus on cryptographic modules and their tested evidence. They do not make every product, deployment, protocol, or organization automatically compliant.

Stop and collect more evidence when the claim cannot identify the module boundary, when the certificate does not match the deployed version or environment, when a historical certificate is being used for procurement, or when a non-approved function is being described as an approved FIPS 140-3 service.