--- title: "FIPS 140-3 Applicability Test" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/applicability-test" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/applicability-test" author: "Sorena AI" description: "Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 140-3 applicability" - "CMVP validation" - "cryptographic module boundary" - "CAVP certificates" - "FIPS 140-3" - "applicability test" - "cryptographic module validation" - "CMVP" - "CAVP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 Applicability Test Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence. *Artifact Guide* *GLOBAL* *FIPS 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. 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. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://www.nist.gov/cmvp?ref=sorena.io) - Official CMVP page referenced by FIPS 140-3 for program information about cryptographic module validation. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Identifies the kinds of cryptographic services and environments that affect applicability and security-level selection. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports checking approved algorithms, key management techniques, and authentication techniques before relying on an approved-service claim. - [CMVP Implementation Guidance, non-approved security functions](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the distinction between approved mode, non-approved security functions, and non-approved algorithms used with no security claimed. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the rule that CMVP-validated cryptographic modules are considered conforming to FIPS 140-3. - [NIST FIPS 140-3, section 12 Implementation Schedule](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Explains that CAVP and CMVP certificates state implementation or module name, version, and tested operational environment. *Recommended next step* *Placement: after practical guidance* ## 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. - [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert the applicability result into module evidence requests, certificate checks, and release gates. - [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited NIST and CMVP sources to resolve module scope, certificate, and evidence questions before implementation. - [Talk through implementation](/contact.md): Review module scope, customer triggers, evidence gaps, and the next FIPS 140-3 actions with Sorena. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the record fields for applicability trigger, module implementation type, security level, and approved security functions. - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports recording module boundary, operational environment, certificate caveats, CAVP references, and Security Policy evidence when applying FIPS 140-3 guidance. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for checking algorithm certificate identity before citing CAVP evidence in an applicability record. ## 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](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - 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](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports checking whether a service indicator and Security Policy evidence actually identify approved service use. - [CMVP Implementation Guidance, section 2.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the operational-environment red flag because certificate evidence is tied to tested configurations. ## Primary sources - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary source for FIPS 140-3 applicability, applications, module implementation types, approved security functions, CMVP conformance, and procurement caution about historical certificates. - Quote: "This standard is applicable to all Federal agencies" - [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Program guidance for applying FIPS 140-3 to module boundaries, bound or embedded modules, CAVP evidence, operational environments, approved services, and Security Policy caveats. - Quote: "Implementation Guidance for FIPS 140-3" - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for verifying CAVP algorithm certificate evidence before using it in a FIPS 140-3 applicability record. - Quote: "validation-search" ## Related Topic Guides - [FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary](/artifacts/global/fips-140-3/algorithm-certificate-mapping.md): Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence. - [FIPS 140-3 Algorithm Certificates FAQ](/artifacts/global/fips-140-3/faq/algorithm-certificates.md): How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence. - [FIPS 140-3 Approved and Non-Approved Mode Workflow](/artifacts/global/fips-140-3/approved-and-non-approved-mode-workflow.md): Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence. - [FIPS 140-3 approved-mode evidence workflow](/artifacts/global/fips-140-3/approved-mode-evidence-workflow.md): A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review. - [FIPS 140-3 Certificate Maintenance FAQ](/artifacts/global/fips-140-3/faq/certificate-maintenance.md): How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records. - [FIPS 140-3 Change Impact Review](/artifacts/global/fips-140-3/change-impact.md): Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence. - [FIPS 140-3 compliance guide](/artifacts/global/fips-140-3/compliance.md): A grounded FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, CMVP validation evidence, and procurement review. - [FIPS 140-3 Entropy and DRBG Evidence](/artifacts/global/fips-140-3/entropy-and-drbg.md): FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling. - [FIPS 140-3 Entropy Evidence FAQ](/artifacts/global/fips-140-3/faq/entropy-evidence.md): How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats. - [FIPS 140-3 FAQ for Cryptographic Modules](/artifacts/global/fips-140-3/faq.md): Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence. - [FIPS 140-3 Module Boundaries FAQ](/artifacts/global/fips-140-3/faq/module-boundaries.md): Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules. - [FIPS 140-3 Module Boundary Selector Workflow](/artifacts/global/fips-140-3/module-boundary-selector-workflow.md): A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence. - [FIPS 140-3 operational environments FAQ](/artifacts/global/fips-140-3/faq/operational-environments.md): Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim. - [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md): A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes. - [FIPS 140-3 Security Policy Template](/artifacts/global/fips-140-3/security-policy-template.md): Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence. - [FIPS 140-3 Validation Checklist](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence. - [FIPS 140-3 Validation Maintenance](/artifacts/global/fips-140-3/validation-maintenance.md): Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence. - [FIPS 140-3 Validation Maintenance Change Workflow](/artifacts/global/fips-140-3/validation-maintenance-change-impact-workflow.md): A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records. - [FIPS 140-3 Vendor Affirmation FAQ](/artifacts/global/fips-140-3/faq/vendor-affirmation.md): When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep. - [FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759](/artifacts/global/fips-140-3/fips-140-3-vs-iso-19790.md): Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims. - [FIPS 140-3: CMVP Lifecycle Timeline](/artifacts/global/fips-140-3/cmvp-lifecycle-timeline.md): Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints. - [FIPS 140-3: FIPS 140-2 vs FIPS 140-3](/artifacts/global/fips-140-3/fips-140-2-vs-fips-140-3.md): Compare FIPS 140-2 legacy references with FIPS 140-3 requirements, ISO/IEC 19790 alignment, CMVP testing evidence, and guidance mappings. - [FIPS 140-3: Module Boundary and Service Mapping](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence. - [FIPS 140-3: Module Boundary Selector](/artifacts/global/fips-140-3/module-boundary-selector.md): Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence. - [FIPS 140-3: Operational Environment](/artifacts/global/fips-140-3/operational-environment.md): FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims. - [FIPS 140-3: Security Levels Explained](/artifacts/global/fips-140-3/security-levels-explained.md): Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation. - [FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules](/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow.md): Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence. - [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md): Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/applicability-test