--- 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" 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 1 of 2. Showing 20 of 25 items.* ### [What does an algorithm certificate prove under FIPS 140-3?](/artifacts/global/fips-140-3/faq/algorithm-certificates.md#what-does-an-algorithm-certificate-prove-under-fips-140-3) *Module: [FIPS 140-3 Algorithm Certificates](/artifacts/global/fips-140-3/faq/algorithm-certificates.md)* A CAVP algorithm certificate supports the algorithm part of a FIPS 140-3 evidence package. The CMVP implementation guidance says cryptographic algorithm implementations are tested and validated under CAVP, while cryptographic modules are tested and validated under CMVP. - Use the CAVP certificate to identify the tested algorithm implementation, implementation version, and operational environment. - Use the CMVP module certificate and Security Policy to support a FIPS 140-3 module-validation claim. - Keep customer and procurement wording separate: CAVP-tested algorithm implementation is not the same claim as CMVP-validated cryptographic module. 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 the distinction between CAVP testing for algorithm implementations and CMVP validation for cryptographic modules. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains that CMVP validates cryptographic modules and that validated modules are the procurement metric for agencies. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for checking algorithm validation records used as supporting evidence. ### [What should I check before reusing a certificate in module evidence?](/artifacts/global/fips-140-3/faq/algorithm-certificates.md#what-should-i-check-before-reusing-a-certificate-in-module-evidence) *Module: [FIPS 140-3 Algorithm Certificates](/artifacts/global/fips-140-3/faq/algorithm-certificates.md)* Check the certificate number, algorithm name, implementation version, and tested operational environment, then compare those details with the module configuration that will rely on the algorithm. The CMVP guidance says the certificate serves as a benchmark for the configuration and operational environment used during validation. - Compare the certificate's implementation name and version with the implementation shipped in the module. - Compare the certificate's operating system, platform, processor, and hypervisor details with the module's tested operational environment. - Treat changed code, changed processor bit size, changed operating system, or changed hardware implementation as a reason to re-check CAVP testing coverage. 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 reuse rule for binding cryptographic algorithm validation certificates to modules under test. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup for confirming the certificate entry, algorithm name, implementation details, and listed operating environment. ### [What evidence should be kept with algorithm certificates?](/artifacts/global/fips-140-3/faq/algorithm-certificates.md#what-evidence-should-be-kept-with-algorithm-certificates) *Module: [FIPS 140-3 Algorithm Certificates](/artifacts/global/fips-140-3/faq/algorithm-certificates.md)* Keep enough evidence to show why the certificate supports the current module claim. The record should connect the CAVP entry to the module boundary, the Security Policy table or service row where the algorithm is used, and the operational environment tested for the module. - Record the CAVP certificate number, algorithm name, implementation name, implementation version, and tested operational environment. - Map each certificate to the module service or Security Policy row that relies on that algorithm implementation. - Re-check the evidence when the algorithm implementation, module version, operating environment, processor acceleration path, supplier component, or CMVP module status changes. - For PAA or PAI use, verify whether the guidance requires testing in both software/firmware-only execution and accelerated execution. 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 evidence fields for certificate binding, operating environment checks, and PAA/PAI testing considerations. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports retaining module-level CMVP validation evidence separately from algorithm-certificate evidence. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this source to re-check the public certificate entry instead of relying only on copied text or screenshots. ### [How should teams maintain a FIPS 140-3 certificate claim?](/artifacts/global/fips-140-3/faq/certificate-maintenance.md#how-should-teams-maintain-a-fips-140-3-certificate-claim) *Module: [FIPS 140-3 Certificate Maintenance](/artifacts/global/fips-140-3/faq/certificate-maintenance.md)* Treat the CMVP certificate entry as living evidence. Before using it in procurement, customer trust, audit, or product-security material, verify the current validation status, certificate number, module name, vendor, version, tested configuration, caveats, Security Policy, and validation history on the official NIST CMVP site. - Record the official CMVP URL, certificate number, validation status, module name, vendor, module version, tested configuration, and date checked. - Compare the product or embedded module being offered with the certificate entry and the non-proprietary Security Policy. - Re-check the CMVP entry before renewing public claims, responding to procurement questionnaires, or accepting a vendor's updated module package. Sources for this answer: - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Supports using the current NIST database entry, not only certificate copies, because validation entries can be updated during the validation life cycle. - [CMVP validated modules search](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/search?ref=sorena.io) - Official search page for checking certificate number, vendor, module name, validation status, and certificate details. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains that CMVP validates cryptographic modules and that federal agencies use validated modules as a procurement metric. ### [What changes trigger a maintenance review?](/artifacts/global/fips-140-3/faq/certificate-maintenance.md#what-changes-trigger-a-maintenance-review) *Module: [FIPS 140-3 Certificate Maintenance](/artifacts/global/fips-140-3/faq/certificate-maintenance.md)* Review the certificate whenever the module, product packaging, embedded validated module, operational environment, algorithm set, Security Policy wording, vendor evidence, or vulnerability status changes. The review question is whether the current certificate still describes the module and configuration being claimed. - Check whether the offered product is the validated module itself or a product that incorporates a validated module. - Check whether module version, hardware version, software or firmware version, tested configuration, and caveats still match the deployed or supplied item. - If a validated module is embedded or bound to another module, watch for changes in the referenced module's status because CMVP guidance can make the dependent claim inherit Historical status. Sources for this answer: - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Grounds the post-validation maintenance rule: vendors use new validation or revalidation through a CSTL, and unhandled changes can invalidate the module. - [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 checking embedded or bound validated module status, including cases where an implementation under test inherits Historical status from an embedded validated module. - [CMVP validated modules overview](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Explains that certificate detail pages include module information, algorithm references, Security Policies, certificate images, and vendor links when provided. ### [What evidence should be kept for certificate maintenance?](/artifacts/global/fips-140-3/faq/certificate-maintenance.md#what-evidence-should-be-kept-for-certificate-maintenance) *Module: [FIPS 140-3 Certificate Maintenance](/artifacts/global/fips-140-3/faq/certificate-maintenance.md)* Keep a compact evidence record that lets a reviewer repeat the check. It should show the official CMVP entry, the Security Policy used, the exact product or module version in scope, the claim being made, and any change or revalidation question that remains open. - Save the CMVP certificate URL, certificate number, current status, validation date shown on the entry, Security Policy URL or file reference, caveats, and validation-history notes. - For vendor responses, keep the vendor's signed or written statement that identifies the validated module or incorporated validated module and its certificate number, then compare it with the CMVP entry. - Track open maintenance actions separately: CSTL revalidation question, algorithm transition check, vulnerability or flaw assessment, Security Policy update, or product-version mismatch. - Do not cite an IUT or MIP listing as completed FIPS 140-3 validation; wait for the module certificate to be issued and posted. Sources for this answer: - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Supports evidence fields for certificate checks and cautions that IUT and MIP list postings do not guarantee validation. - [CMVP validated modules overview](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules?ref=sorena.io) - Supports comparing vendor claims with CMVP certificate details and the posted Security Policy before accepting a validation claim. - [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 checking CAVP, approved service, embedded module, and operational-environment evidence when a certificate claim depends on those details. ### [What should entropy evidence answer first?](/artifacts/global/fips-140-3/faq/entropy-evidence.md#what-should-entropy-evidence-answer-first) *Module: [FIPS 140-3 Entropy Evidence](/artifacts/global/fips-140-3/faq/entropy-evidence.md)* Start with the entropy path, not the product claim. The evidence should identify whether the module generates entropy itself, calls a well-defined source through a GetEntropy() interface, passively receives externally supplied entropy, or combines active and passive inputs. CMVP Implementation Guidance 9.3.A treats those cases differently because the laboratory may be able to corroborate some entropy-strength estimates directly while other deployments require warning caveats. - Map every entropy source to the cryptographic boundary, TOEPP, physical perimeter, and DRBG instantiation or reseed event it supports. - Distinguish direct GetEntropy() access from seed loaders, LOAD commands, preloaded seeds, caller-supplied API buffers, files, and other passive inputs. - Record the minimum entropy amount used for SSP generation and the evidence basis for that amount. - Check whether the design triggers a certificate caveat such as modified SSP strength or no assurance of minimum generated-SSP strength. 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) - IG 9.3.A is the main grounding for entropy-source scenarios, GetEntropy access, Security Policy entropy statements, and certificate caveats. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - FIPS 140-3 establishes the cryptographic-module context and includes sensitive security parameter management among the module security requirement areas. ### [What SP 800-90B evidence belongs in the file?](/artifacts/global/fips-140-3/faq/entropy-evidence.md#what-sp-800-90b-evidence-belongs-in-the-file) *Module: [FIPS 140-3 Entropy Evidence](/artifacts/global/fips-140-3/faq/entropy-evidence.md)* When an entropy evaluation is required, CMVP guidance points teams to SP 800-90B and IG D.K. The evidence package should include raw noise-source access details, statistical-test results, the entropy assessment tool version, and the laboratory's heuristic analysis of how the noise source works and why the claimed entropy rate is supported. - Keep the entropy-source description, raw data collection method, and rationale that collection does not alter source behavior. - Attach statistical-test outputs and the version of the CMVP SP 800-90B entropy assessment tool used. - Include the heuristic entropy analysis, not only the statistical-test result. - Document known or suspected noise-source failure modes and the health tests intended to detect them. 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) - IG D.J and D.K support the SP 800-90B evidence expectations: raw data, statistical testing, heuristic analysis, IID rationale, health tests, and Security Policy entropy amounts. - [NIST SP 800-90B entropy assessment tool](https://github.com/usnistgov/SP800-90B_EntropyAssessment?ref=sorena.io) - CMVP guidance cites this public tool for SP 800-90B statistical testing; the tool output does not supersede the lab's heuristic analysis. ### [How should teams review Security Policy and certificate evidence?](/artifacts/global/fips-140-3/faq/entropy-evidence.md#how-should-teams-review-security-policy-and-certificate-evidence) *Module: [FIPS 140-3 Entropy Evidence](/artifacts/global/fips-140-3/faq/entropy-evidence.md)* Review the Security Policy and certificate together. CMVP guidance requires different public statements depending on whether the module uses an internal source, a known source inside the TOEPP, an external source, a passive load, or a hybrid design. If entropy is externally loaded or cannot be directly verified for all deployments, the certificate may need a no-assurance caveat rather than a broad strength claim. - Compare the design description, Security Policy entropy statement, ESV or ENT notation, and certificate caveat for the same module version. - Confirm that caller guidance is present when an external party must provide entropy with a minimum claimed strength. - For multiple sources, document independence before summing credited entropy. - Do not treat a CAVP algorithm certificate, DRBG name, or generic FIPS reference as proof that the module's entropy evidence supports the deployed configuration. 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) - IG 9.3.A and D.O support the Security Policy, certificate caveat, ESV or ENT notation, and multiple-source entropy review points. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - CAVP records can support approved algorithm implementation checks, but algorithm evidence does not by itself establish module boundary or entropy-source validity. ### [What is the module boundary under FIPS 140-3?](/artifacts/global/fips-140-3/faq/module-boundaries.md#what-is-the-module-boundary-under-fips-140-3) *Module: [FIPS 140-3 Module Boundaries](/artifacts/global/fips-140-3/faq/module-boundaries.md)* FIPS 140-3 applies to cryptographic modules and covers security requirement areas such as module specification, module interfaces, roles and services, software and firmware security, operating environment, physical security, sensitive security parameter management, self-tests, and lifecycle assurance. - For software modules, CMVP guidance describes the software cryptographic module as the executable code that includes security-relevant algorithms, security functions, processes, and module components. - The operating system, computing platform, and other general-purpose applications can be in the tested operational environment while remaining outside the software module's cryptographic boundary. - When a component is outside the boundary, do not describe its behavior as validated module behavior unless the applicable CMVP documentation supports that 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) - Identifies the FIPS 140-3 security requirement areas that apply to cryptographic module design, implementation, and operation. - [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) - Explains how software module boundaries relate to the tested operational environment, general-purpose computing platform, and applications outside the cryptographic boundary. ### [How do bound and embedded modules affect the boundary?](/artifacts/global/fips-140-3/faq/module-boundaries.md#how-do-bound-and-embedded-modules-affect-the-boundary) *Module: [FIPS 140-3 Module Boundaries](/artifacts/global/fips-140-3/faq/module-boundaries.md)* CMVP implementation guidance treats binding and embedding from the perspective of the module under validation, called the Implementation Under Test. An embedded existing validated module is wholly contained within the IUT module boundary and provides services solely to the IUT. - For software, firmware, and hybrid binding cases, the IUT and the existing validated module must each operate on tested operational environments that are the same or one is within the other. - If the IUT relies on the existing validated module to meet a FIPS 140-3 requirement, the test report must show how the relied-upon requirement is met without violating other FIPS 140-3 requirements. - A FIPS 140-3 IUT cannot embed or bind to a FIPS 140-2 existing validated module under the cited CMVP guidance. 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) - Defines embedded and binding modules, including separate or contained boundaries, operational environment expectations, and FIPS 140-2 restrictions for FIPS 140-3 IUTs. ### [What should be documented before making a boundary claim?](/artifacts/global/fips-140-3/faq/module-boundaries.md#what-should-be-documented-before-making-a-boundary-claim) *Module: [FIPS 140-3 Module Boundaries](/artifacts/global/fips-140-3/faq/module-boundaries.md)* Boundary documentation should be specific enough for a customer, assessor, or procurement reviewer to understand the module being claimed without confusing product packaging with the validated cryptographic module. - Keep a boundary diagram or written boundary description that separates in-boundary components from the operating system, hardware platform, applications, and services outside the cryptographic boundary. - List the module interfaces, approved services, algorithms, self-tests, sensitive security parameter handling, and software or firmware integrity expectations that depend on the boundary. - For a bound or embedded existing validated module, identify the module by name, CMVP certificate number, version, and the subset of EVM functionality used by the IUT. 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 boundary discussions tied to the FIPS 140-3 module requirement areas rather than broad product-level claims. - [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) - States documentation expectations for IUT submissions that use an existing validated module, including clear separation of IUT and EVM information. ### [What does operational environment mean in FIPS 140-3?](/artifacts/global/fips-140-3/faq/operational-environments.md#what-does-operational-environment-mean-in-fips-140-3) *Module: [FIPS 140-3 operational environments](/artifacts/global/fips-140-3/faq/operational-environments.md)* FIPS 140-3 names operating environment as one of the security requirement areas for cryptographic modules. That matters because the validated security level is chosen for the application, environment, and services where the module will be used. - Treat operational environment as part of the module claim boundary, not as a deployment note that can be changed freely. - For software, firmware, and hybrid modules, identify the module components, computing platform, and operating system before relying on a FIPS 140-3 claim. - Use the module security policy and certificate evidence to understand restrictions on the environment where the module was tested. 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) - Identifies operating environment as a FIPS 140-3 security requirement area and ties validation level selection to the application and environment where the module is used. - [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) - Defines operational environment for software, firmware, and hybrid modules as including module components, computing platform, and operating system. ### [How should teams check a tested operational environment?](/artifacts/global/fips-140-3/faq/operational-environments.md#how-should-teams-check-a-tested-operational-environment) *Module: [FIPS 140-3 operational environments](/artifacts/global/fips-140-3/faq/operational-environments.md)* Start with the certificate, security policy, and algorithm validation evidence for the exact module and version. CMVP guidance says cryptographic module validation certificates state the module name, version, and tested operational environment; CAVP algorithm certificates also state the tested operational environment for the algorithm implementation. - Record the module name, version, certificate evidence, and security policy before mapping it to a product or customer environment. - For software modules, capture operating system, platform, processor, and hypervisor if used. - When embedding a validated algorithm implementation, check that the algorithm's tested operational environment is identical to, or fully included in, the module environment being tested. 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) - Explains that CAVP and CMVP certificates state tested operational environments and gives software-module listing requirements for operating system, platform, processor, and hypervisor. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for checking algorithm validation certificates when operational-environment evidence is part of a module review. ### [What mistakes create unreliable FIPS 140-3 operational-environment claims?](/artifacts/global/fips-140-3/faq/operational-environments.md#what-mistakes-create-unreliable-fips-140-3-operational-environment-claims) *Module: [FIPS 140-3 operational environments](/artifacts/global/fips-140-3/faq/operational-environments.md)* The main mistake is stretching a validation claim beyond the environment that was tested. CMVP guidance says a claim cannot be made for a different processor bit size when an implementation was tested on one bit size, and a claim cannot be made for another operating system when the implementation was tested on one operating system for module testing. - Do not rely on a validation for a different operating system, processor bit size, platform, or hypervisor unless the evidence supports that environment. - Do not substitute administrative procedures for operating-system capabilities that the CMVP guidance says must be enforced by the module or environment. - Do not present a product as FIPS 140-3 validated merely because it uses a validated algorithm; the module, version, configuration, and tested operational environment still have to match the claim. 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 the limits on porting operational-environment claims across operating systems and processor bit sizes, and the Level 1 software expectations for process separation and SSP control. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains that FIPS 140-3 applies to cryptographic modules and that validated modules under CMVP are considered conforming to the standard. ### [What do FIPS 140-3 security levels mean?](/artifacts/global/fips-140-3/faq/security-levels.md#what-do-fips-140-3-security-levels-mean) *Module: [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md)* FIPS 140-3 defines four increasing qualitative security levels, Level 1 through Level 4, for cryptographic modules. The standard applies the levels across requirement areas such as 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. - Name the cryptographic module, version, boundary, and operating environment before using a level claim. - Tie the selected level to the application, deployment environment, and cryptographic services the module will provide. - Separate module validation evidence from wider system risk decisions; FIPS 140-3 conformance alone does not prove that the whole system is secure. 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) - Defines FIPS 140-3 as a cryptographic-module standard with four qualitative security levels and named 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) - Explains CMVP guidance, validation evidence, and how implementation details are clarified for FIPS 140-3 submissions. ### [How should a team choose a FIPS 140-3 security level?](/artifacts/global/fips-140-3/faq/security-levels.md#how-should-a-team-choose-a-fips-140-3-security-level) *Module: [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md)* 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. - Choose the level against the actual cryptographic module, not an adjacent application feature. - Confirm whether the required evidence is a CMVP module validation, an algorithm certificate, a security policy entry, or a supplier statement that still needs validation support. - For federal procurement language, avoid relying on the CMVP Historical list as the proof point for current procurement decisions. 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) - States that the validated security level is selected for the application, environment, and security services of the module. - [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) - Distinguishes CMVP module validation from CAVP algorithm validation and identifies certificate and operating-environment evidence. ### [What evidence should support a security-level claim?](/artifacts/global/fips-140-3/faq/security-levels.md#what-evidence-should-support-a-security-level-claim) *Module: [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md)* 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. - Keep the public certificate number, module name, module version, tested operating environment, and security policy together. - For bound or embedded modules, identify the existing validated module by name, certificate number, version, and the functions actually used. - Do not treat a CAVP algorithm certificate as proof that the containing cryptographic module has a FIPS 140-3 security level. 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) - Gives evidence expectations for bound and embedded modules, including certificate, version, boundary, and security-level relationships. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Official NIST search entry point for checking cryptographic algorithm validation certificates used as supporting evidence. ### [What mistakes should teams avoid?](/artifacts/global/fips-140-3/faq/security-levels.md#what-mistakes-should-teams-avoid) *Module: [FIPS 140-3 security levels: how to choose and evidence them](/artifacts/global/fips-140-3/faq/security-levels.md)* The most common mistake is changing the scope of the claim: a validated cryptographic module becomes a validated product, a product becomes a validated service, or an algorithm certificate becomes a module certificate. FIPS 140-3 evidence should keep those layers separate. - Do not use Level 2, Level 3, or Level 4 language unless the CMVP evidence supports that level for the exact module scope. - Do not combine multiple module certificates into one product-level security-level claim without explaining each boundary. - Do not ignore certificate status changes, algorithm transitions, module updates, or operating-environment changes when reusing older evidence. 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) - Warns that conformance to the standard is not by itself enough to prove the security of a particular module or system. - [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 review triggers around bound or embedded modules, validation status, certificate status, and operating-environment evidence. ### [When can vendor affirmation be used under FIPS 140-3?](/artifacts/global/fips-140-3/faq/vendor-affirmation.md#when-can-vendor-affirmation-be-used-under-fips-140-3) *Module: [FIPS 140-3 Vendor Affirmation](/artifacts/global/fips-140-3/faq/vendor-affirmation.md)* Vendor affirmation is available only for specific cases described in CMVP Implementation Guidance. The clearest HSS example is IG C.O for SP 800-208: HSS can be vendor-affirmed when the implementation performs the required cryptographic algorithm self-tests, the underlying LMS operations have the required CAVP certificates, and the CSTL verifies each supported HSS operation through source-code review. - Confirm the exact IG section that allows the vendor affirmation claim, such as IG C.O for SP 800-208 HSS or IG D.H for SP 800-133 key generation. - Keep CAVP certificate numbers for the underlying algorithms that the IG requires, including the LMS operations used by an HSS implementation. - Make sure the Security Policy places the claim in the correct table or disclosure location required by the applicable IG. 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 the specific IG C.O conditions for SP 800-208 HSS vendor affirmation, including CASTs, LMS CAVP certificates, CSTL source-code review, Security Policy placement, and transition when CAVP testing becomes available. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports the distinction between CMVP module validation, accredited CST laboratory testing, and the procurement role of validated modules. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search page for checking algorithm-validation certificate evidence that an IG may require before a vendor-affirmed claim is usable. ## 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: 1 of 2 Pages: [1](/artifacts/global/fips-140-3/faq/items.md) | [2](/artifacts/global/fips-140-3/faq/items/page/2.md) [Next page](/artifacts/global/fips-140-3/faq/items/page/2.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