--- title: "FIPS 140-3 FAQ for Cryptographic Modules" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq/items/page/2" author: "Sorena AI" description: "Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 140-3 FAQ" - "CMVP validation" - "CAVP certificates" - "cryptographic modules" - "approved mode" - "FIPS 140-3" - "CMVP" - "cryptographic module validation" - "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 FAQ for Cryptographic Modules Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence. *Artifact Guide* *GLOBAL* *FIPS 140-3* ## FIPS 140-3 FAQ Direct answers to common FIPS 140-3 questions about cryptographic module scope, CMVP validation, algorithm evidence, and approved mode claims. Grounded in NIST FIPS 140-3 and CMVP implementation guidance. Use it for product, procurement, and evidence review; confirm live certificate status in CMVP records. FIPS 140-3 is about validated cryptographic modules, not a blanket approval for every system that uses cryptography. This FAQ explains the questions teams usually need to answer before they rely on a FIPS 140-3 claim in product design, procurement, security policy text, or customer evidence. ## Browse sub-FAQ modules ### [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. - 3 items ### [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. - 3 items ### [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. - 3 items ### [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. - 3 items ### [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. - 3 items ### [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. - 4 items ### [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. - 3 items ### [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. - 3 items Browse all indexed questions: [/artifacts/global/fips-140-3/faq/items](/artifacts/global/fips-140-3/faq/items.md) ## All FAQ items *Page 2 of 2. Showing 5 of 25 items.* ### [What does vendor affirmation require for HSS?](/artifacts/global/fips-140-3/faq/vendor-affirmation.md#what-does-vendor-affirmation-require-for-hss) *Module: [FIPS 140-3 Vendor Affirmation](/artifacts/global/fips-140-3/faq/vendor-affirmation.md)* 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. - Record the HSS operations implemented by the module: key generation, signature generation, signature verification, or a subset. - Map each implemented HSS operation to the required LMS CAVP certificates and parameter sets. - Verify that HSS appears in the Security Policy's Vendor-Affirmed Algorithms table and that LMS appears in the Approved Algorithms table with the associated certificate references. Sources for this answer: - [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) - Grounds the HSS-specific evidence requirements: required self-tests, LMS CAVP certificates, all HSS tree parameter sets, CSTL source-code review, Test Report documentation, and Security Policy tables. - [NIST SP 800-208 stateful hash-based signature schemes](https://doi.org/10.6028/NIST.SP.800-208?ref=sorena.io) - Referenced by IG C.O as the source for LMS, XMSS, HSS, and XMSSMT stateful hash-based signature schemes. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this public source to verify the underlying LMS algorithm certificate evidence referenced by an HSS vendor-affirmation claim. ### [What evidence should teams keep for vendor affirmation?](/artifacts/global/fips-140-3/faq/vendor-affirmation.md#what-evidence-should-teams-keep-for-vendor-affirmation) *Module: [FIPS 140-3 Vendor Affirmation](/artifacts/global/fips-140-3/faq/vendor-affirmation.md)* 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 HSS: keep the Vendor-Affirmed Algorithms table entry, Approved Algorithms table LMS entries, CAVP certificate references, CSTL source-code review record, and TE02.20.04 Test Report reference. - For SP 800-133: keep the Section 4 or Section 6.3 method mapping, DRBG-output explanation, independence rationale where relevant, CKG certificate-entry rationale, and Security Policy method details. - Set a review trigger when CAVP testing becomes available for a previously vendor-affirmed algorithm, because IG C.O points to the Management Manual transition process for moving from vendor affirmation to CAVP testing. Sources for this answer: - [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 both the HSS evidence package in IG C.O and the SP 800-133 key-generation vendor-affirmation requirements in IG D.H. - [NIST SP 800-133 Rev. 2 cryptographic key generation](https://doi.org/10.6028/NIST.SP.800-133r2?ref=sorena.io) - Referenced by IG D.H for key-generation methods used when claiming vendor affirmation to SP 800-133. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this public source to verify algorithm certificate numbers that remain required even when a related vendor-affirmed claim is permitted. ### [Handle approved-mode claims at the service level](/artifacts/global/fips-140-3/faq/approved-mode.md#handle-approved-mode-claims-at-the-service-level) *Module: [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md)* Start with the validated cryptographic module, not the product or platform around it. FIPS 140-3 specifies requirements for cryptographic modules, and CMVP guidance treats approved-mode analysis at the level of module services, security functions, indicators, and Security Policy descriptions. - Map the claim to the validated cryptographic module boundary and the service table in the module Security Policy. - Classify each callable service as an approved security service, a non-security service allowed in approved mode, a non-approved algorithm with no security claimed, or a service not available in approved mode. - Use the module's service indicator, return code, status output, log message, or other externally accessible signal only if it lets the operator unambiguously determine when an approved security service is in use. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Grounds the page scope: FIPS 140-3 applies to cryptographic modules and lists roles, services, authentication, self-tests, lifecycle assurance, and other module security requirement areas. - [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) - Grounds the distinction between approved mode, approved security services, service indicators, and services that are not available for approved-mode use. ### [What evidence supports an approved-mode answer?](/artifacts/global/fips-140-3/faq/approved-mode.md#what-evidence-supports-an-approved-mode-answer) *Module: [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md)* The strongest evidence is the set of records that let a reader trace the answer from a module certificate and Security Policy to the exact service behavior. The CMVP guidance says the Security Policy must list approved and non-approved services with details and applicable indicators; the Security Policy can explain the indicators, but its text alone does not satisfy the indicator requirement. - Module certificate number, module name, version, operational environment, and security level claims for the validated configuration. - Security Policy service table showing approved and non-approved services, approved security service indicators, and any operator guidance needed to use a service in an approved manner. - Algorithm validation evidence for the approved security functions used by the claimed service, plus records showing required self-tests and approved parameters where applicable. - Configuration or runtime evidence showing that disallowed services are unavailable in approved mode and that non-approved algorithms with no security claimed are not presented as security functions. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the need to keep approved-mode evidence tied to the cryptographic module and its required security areas rather than to a whole product label. - [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 the Security Policy evidence requirements for service lists, indicators, and non-approved algorithms allowed in approved mode with no security claimed. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for algorithm validation entries that can support service-level evidence when a FIPS 140-3 approved security service relies on a tested algorithm implementation. ### [What mistakes should teams avoid?](/artifacts/global/fips-140-3/faq/approved-mode.md#what-mistakes-should-teams-avoid) *Module: [How should teams handle approved mode under FIPS 140-3?](/artifacts/global/fips-140-3/faq/approved-mode.md)* 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. - Do not use a global approved-mode indicator by itself when the module can run approved and non-approved security services concurrently or when not all approved services are configured for the mode. - Do not rely on Security Policy narrative alone as the service indicator; the indicator must be externally accessible from the module's status interface and verifiable by the operator. - Do not call a non-approved cryptographic algorithm an approved-mode security function just because it is present while the module is in approved mode. - Do not reuse evidence from another certificate, module version, operational environment, or service table unless the validated boundary and configuration match the claim. Sources for this answer: - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports keeping the approved-mode answer within the cryptographic module security requirements and validated configuration. - [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 the cautions on global indicators, Security Policy-only explanations, non-approved algorithms, and disallowed non-approved security functions. ## FAQ Pagination - Canonical index (page 1): [/artifacts/global/fips-140-3/faq/items](/artifacts/global/fips-140-3/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 2 of 2 Pages: [1](/artifacts/global/fips-140-3/faq/items.md) | [2](/artifacts/global/fips-140-3/faq/items/page/2.md) [Previous page](/artifacts/global/fips-140-3/faq/items.md) *Recommended next step* *Placement: after practical guidance* ## Operationalize FIPS 140-3 questions Use this FAQ to turn FIPS 140-3 questions into scoped module reviews, certificate checks, and customer-ready evidence packets. - [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert FIPS 140-3 scope and evidence questions into owned review tasks and certificate checks. - [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited NIST and CMVP source material to resolve module scope, approved-mode, and evidence questions before implementation. - [Talk through implementation](/contact.md): Review module boundaries, certificate evidence, procurement claims, and next compliance actions with Sorena. --- [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/faq/items/page/2