Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Applicability Test

A test for deciding whether a cryptographic module, use case, or procurement claim should be handled as FIPS 140-3 work.

Use it to separate federal-agency applicability, voluntary commercial adoption, module validation scope, and unsupported product-level claims.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

This page is for product security, procurement, compliance, and engineering teams deciding whether FIPS 140-3 belongs in a requirement, evidence request, or customer statement. It does not decide whether a product is secure. It tests whether the claim is about a cryptographic module that fits the FIPS 140-3 and CMVP evidence model.

Section 1

FIPS 140-3 applies first to federal agency cryptographic module use

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

For private or commercial organizations, the standard is available for adoption, but the page should not turn that availability into a universal legal requirement. Treat commercial use as applicable only when a customer requirement, procurement clause, contract, internal assurance policy, or market claim asks for FIPS 140-3 validated cryptography.

Mark applicable when the module will protect federal agency sensitive information or will be operated for a federal agency under contract.
Mark potentially applicable when a commercial customer or internal policy requires a FIPS 140-3 validated module.
Mark not established when the only evidence is a general desire for strong cryptography without a module, procurement, or assurance trigger.
Keep classified-use substitutions separate: FIPS 140-3 allows cryptographic modules approved for classified use to be used instead of modules validated against the standard.

Sources for this answer

NIST FIPS 140-3, section 6 Applicability

Grounds the core applicability rule for federal agencies, contracted agency operation, classified-use substitutions, and voluntary private or commercial adoption.

NIST FIPS 140-3, Cryptographic Module Validation Program summary

Explains why procurement teams ask for CMVP validation: validated modules give agencies a security metric when buying equipment containing cryptographic modules.

NIST CMVP information page

Official CMVP page referenced by FIPS 140-3 for program information about cryptographic module validation.

Section 2

Test whether the claim is about a cryptographic module

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, translate it into the module actually providing cryptographic services. If no module boundary can be identified, the correct outcome is not "FIPS 140-3 compliant"; it is an unresolved scope claim that needs boundary evidence.

Record the module name, version, type, cryptographic boundary, operational environment, and the product or service that embeds or calls it.
List the services the module provides, such as encryption, authentication, digital signature, and key management.
Separate module validation scope from product, protocol, deployment, and organizational security claims.
Reject evidence that cites a different module, version, operational environment, or boundary unless the validation documentation supports that relationship.

Sources for this answer

NIST FIPS 140-3, section 9 Implementations

Supports focusing the applicability test on hardware, software, firmware, or hybrid cryptographic module implementations rather than broad product claims.

CMVP Implementation Guidance, binding and embedding modules

Grounds boundary-sensitive treatment for modules that bind to or embed another validated module, including the need to distinguish the module under test from the embedded validated module.

NIST FIPS 140-3, section 7 Applications

Identifies the kinds of cryptographic services and environments that affect applicability and security-level selection.

Section 3

Check the security level and service fit

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.

Record the claimed overall security level and any requirement-area levels relevant to the use case.
Tie the level choice to the application, environment, and services being protected.
List approved security functions and the service or mode that uses each one.
Do not treat non-approved algorithms, protocol support, or helper functions as covered by FIPS 140-3 unless the Security Policy and CMVP guidance support the claim.

Sources for this answer

NIST FIPS 140-3, section 7 Applications

Grounds the need to choose a security level appropriate to the module's application, environment, and security services.

NIST FIPS 140-3, section 10 Approved Security Functions

Supports checking approved algorithms, key management techniques, and authentication techniques before relying on an approved-service claim.

CMVP Implementation Guidance, non-approved security functions

Grounds the distinction between approved mode, non-approved security functions, and non-approved algorithms used with no security claimed.

Section 4

Verify validation evidence before using the claim

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, Security Policy, relevant CAVP certificates, and any certificate caveats. Do not use the CMVP Historical list for procurement decisions; FIPS 140-3 describes that list as reference-only.

Check that the CMVP certificate names the same module, version, and operational environment used by the product or service.
Check that each CAVP certificate supports the algorithm implementation used by the module service.
Copy certificate caveats into the applicability record when entropy, operational environment, or service restrictions affect the claim.
Avoid procurement statements that rely only on historical certificates, unrelated algorithm certificates, or certificates for a different module boundary.

Sources for this answer

NIST FIPS 140-3, section 9 Implementations

Supports the rule that CMVP-validated cryptographic modules are considered conforming to FIPS 140-3.

NIST FIPS 140-3, section 12 Implementation Schedule

Grounds the procurement caution that the CMVP Historical list is for reference and should not be used for procurement decisions.

CMVP Implementation Guidance, section 2.3.A

Explains that CAVP and CMVP certificates state implementation or module name, version, and tested operational environment.

Recommended next step

Operationalize the FIPS 140-3 applicability test

Use this test to connect customer requests, module boundaries, CMVP certificates, CAVP evidence, and Security Policy caveats before making a FIPS 140-3 claim.

Assessment workflow

Open Assessment Autopilot for FIPS 140-3

Convert the applicability result into module evidence requests, certificate checks, and release gates.

Explore next step

Research workflow

Research FIPS 140-3 source questions

Use cited NIST and CMVP sources to resolve module scope, certificate, and evidence questions before implementation.

Explore next step

Talk to Sorena

Talk through implementation

Review module scope, customer triggers, evidence gaps, and the next FIPS 140-3 actions with Sorena.

Explore next step

Section 5

Applicability record fields

Use the fields below when turning the applicability test into an internal record, supplier questionnaire, or procurement note. The goal is to make the answer reviewable: 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.

Use "applicable" only when a federal-agency, contract, procurement, or voluntary adoption trigger is tied to a specific cryptographic module.
Use "not applicable" when the request is not about a cryptographic module or no FIPS 140-3 trigger exists.
Use "needs evidence" when the trigger exists but the module boundary, certificate scope, operational environment, or Security Policy evidence is missing.
Use "do not claim" when the only available evidence is an algorithm certificate, marketing statement, historical certificate, or different module validation.

Sources for this answer

NIST FIPS 140-3, sections 6 through 10

Supports the record fields for applicability trigger, module implementation type, security level, and approved security functions.

CMVP Implementation Guidance for FIPS 140-3

Supports recording module boundary, operational environment, certificate caveats, CAVP references, and Security Policy evidence when applying FIPS 140-3 guidance.

NIST CAVP validation search

Public search page for checking algorithm certificate identity before citing CAVP evidence in an applicability record.

Section 6

Red flags that make the applicability answer unreliable

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.

A product says "FIPS compliant" but names no CMVP-validated module.
A supplier provides only a CAVP algorithm certificate and no module validation evidence.
The deployed operating environment is broader or different from the tested environment on the certificate.
The claim ignores Security Policy caveats about entropy, approved services, operational environment, or non-approved functions.
The evidence uses a historical certificate as procurement support instead of reference material.

Sources for this answer

NIST FIPS 140-3, implementation and procurement guidance

Grounds red flags involving non-matching module evidence, procurement use of historical certificates, and claims beyond CMVP validation scope.

CMVP Implementation Guidance, approved mode and service indicators

Supports checking whether a service indicator and Security Policy evidence actually identify approved service use.

CMVP Implementation Guidance, section 2.3.A

Supports the operational-environment red flag because certificate evidence is tied to tested configurations.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Supports recording module boundary, operational environment, certificate caveats, CAVP references, and Security Policy evidence when applying FIPS 140-3 guidance.

"Security Policy"

CMVP Implementation Guidance, approved mode and service indicators

csrc.nist.gov

Referenced sections

Supports checking whether a service indicator and Security Policy evidence actually identify approved service use.

"approved mode of operation"

CMVP Implementation Guidance, binding and embedding modules

csrc.nist.gov

Referenced sections

Grounds boundary-sensitive treatment for modules that bind to or embed another validated module, including the need to distinguish the module under test from the embedded validated module.

"module boundary"

CMVP Implementation Guidance, non-approved security functions

csrc.nist.gov

Referenced sections

Grounds the distinction between approved mode, non-approved security functions, and non-approved algorithms used with no security claimed.

"Non-approved security functions shall not be used"

CMVP Implementation Guidance, section 2.3.A

csrc.nist.gov

Referenced sections

Supports the operational-environment red flag because certificate evidence is tied to tested configurations.

"tested operational environment"

NIST CAVP validation search

csrc.nist.gov

Referenced sections

Public search page for checking algorithm certificate identity before citing CAVP evidence in an applicability record.

"validation-search"

NIST CMVP information page

nist.gov

Referenced sections

Official CMVP page referenced by FIPS 140-3 for program information about cryptographic module validation.

"CMVP"

NIST FIPS 140-3 security requirements for cryptographic modules

doi.org

Referenced sections

Primary source for FIPS 140-3 applicability, applications, module implementation types, approved security functions, CMVP conformance, and procurement caution about historical certificates.

"This standard is applicable to all Federal agencies"

NIST FIPS 140-3, Cryptographic Module Validation Program summary

doi.org

Referenced sections

Explains why procurement teams ask for CMVP validation: validated modules give agencies a security metric when buying equipment containing cryptographic modules.

"security metric to use in procuring equipment"

NIST FIPS 140-3, implementation and procurement guidance

doi.org

Referenced sections

Grounds red flags involving non-matching module evidence, procurement use of historical certificates, and claims beyond CMVP validation scope.

"Cryptographic modules that are validated"

NIST FIPS 140-3, section 10 Approved Security Functions

doi.org

Referenced sections

Supports checking approved algorithms, key management techniques, and authentication techniques before relying on an approved-service claim.

"shall employ Approved security functions"

NIST FIPS 140-3, section 12 Implementation Schedule

doi.org

Referenced sections

Grounds the procurement caution that the CMVP Historical list is for reference and should not be used for procurement decisions.

"should not be used for procurement decisions"

NIST FIPS 140-3, section 6 Applicability

doi.org

Referenced sections

Grounds the core applicability rule for federal agencies, contracted agency operation, classified-use substitutions, and voluntary private or commercial adoption.