--- title: "FIPS approved mode procurement: certificates, boundaries, and evidence" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/approved-mode-procurement" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/approved-mode-procurement" author: "Sorena AI" description: "Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 140-3 procurement" - "CMVP certificate" - "CAVP validation" - "approved mode" - "cryptographic module evidence" - "FIPS 140-3" - "CMVP" - "CAVP" - "cryptographic module procurement" --- **[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 approved mode procurement: certificates, boundaries, and evidence Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase. *Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithm requirements* ## FIPS approved mode procurement Certificates, boundaries, and evidence A procurement review guide for checking whether a supplier's FIPS approved mode claim is tied to a validated cryptographic module, tested configuration, and usable evidence. Use this for security, procurement, and audit reviews before relying on broad supplier claims about validated cryptography. Approved mode procurement is not a keyword check. The useful question is whether the product, service, or component you are buying can be matched to a CMVP-validated cryptographic module, the module's tested operational environment, the approved services you intend to use, and the CAVP evidence behind the algorithm implementations. ## What does approved mode procurement need to prove? Start with the module, not the marketing claim. FIPS 140-3 applies to cryptographic modules and says CMVP validation is the metric agencies can use when procuring equipment containing validated cryptographic modules. The procurement file should therefore identify the validated module, certificate status, module version, tested operational environment, security level, and the services that will be used in the buyer's environment. An approved algorithm is only part of the story. A product can use AES, SHA, ECDSA, or another approved function and still fail the procurement test if the supplier cannot show that the implementation is inside the validated module boundary and used through an approved service in the tested configuration. - Require the supplier to name the exact CMVP certificate, module name, module version, security level, and validation status. - Check whether the certificate is Active for procurement use; do not treat the CMVP Historical list as a procurement approval list. - Ask which approved services cover the actual use case, such as encryption, authentication, key establishment, hashing, signatures, or key management. - Record the tested operational environment and reject substitutions unless the supplier can show they are covered by the validation. 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 procurement focus on validated cryptographic modules, security levels, approved security functions, and the warning not to use the Historical list for procurement decisions. - [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 tests algorithm implementations while CMVP validates cryptographic modules and certificate configurations. ## Evidence to request from suppliers Ask for evidence that can be checked independently. The minimum useful packet is a CMVP certificate reference, the public Security Policy, the module version and tested environment, the list of approved services that the product will call, and the CAVP algorithm certificates or validation references for the implementations used by those services. For embedded or bound modules, require a boundary explanation. CMVP guidance requires the validation submission and Security Policy to distinguish the implementation under test from the existing validated module and to identify the existing module by name, certificate number, and version. Procurement should mirror that discipline instead of accepting a generic inherited-validation statement. - CMVP evidence: certificate number, module name, module version, validation status, security level, and Security Policy URL. - Configuration evidence: operating system, platform, processor, hypervisor when relevant, firmware or software version, and enabled crypto-provider settings. - Service evidence: approved services used by the product and any non-approved or allowed services that must be disabled or avoided. - Algorithm evidence: CAVP certificate numbers or validation-search entries for the algorithm implementations used by the approved services. - Dependency evidence: whether the module is embedded, bound to another validated module, or relying on an existing validated module for specific functions. 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 requests for certificate identifiers, tested operational environments, boundary distinctions, and CAVP algorithm evidence. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup used to verify CAVP algorithm validation entries cited by suppliers. *Recommended next step* *Placement: after practical guidance* ## Operationalize approved mode procurement Use this guide to convert supplier FIPS claims into certificate checks, configuration evidence, acceptance criteria, and exception decisions. - [Open Assessment Autopilot for FIPS procurement](/solutions/assessment.md): Turn certificate checks, supplier requests, and exceptions into assigned review work. - [Research FIPS source questions](/solutions/research-copilot.md): Resolve CMVP, CAVP, boundary, and approved mode questions against cited source material. - [Talk through approved mode evidence](/contact.md): Review supplier claims, certificate status, and procurement acceptance criteria with Sorena. ## How to write procurement acceptance criteria Write the requirement as a verifiable condition, not as a slogan. A clause such as "uses FIPS compliant encryption" is too broad because it does not say which module, mode, service, version, environment, or certificate will be delivered. The acceptance criteria should make the supplier identify the validated module and explain how the delivered configuration uses it in approved mode. Tie the evidence to the product lifecycle. NIST supply-chain guidance notes that acquirers often lack visibility into how technology is developed, integrated, and deployed; it also encourages due diligence, supplier engagement, and careful reuse of existing documentation when it actually applies. For crypto procurement, that means reused certificate evidence must still match the product version, operating environment, and intended cryptographic service. - Require delivery of the public CMVP certificate and Security Policy before acceptance. - Require a configuration statement showing how approved mode is enabled and which product features rely on the validated module. - Require notification when module version, operating environment, cryptographic boundary, certificate status, or approved-service behavior changes. - Require an exception path for features that use non-approved services, algorithms outside the validated boundary, or unvalidated fallback providers. - Require the supplier to map any reused validation evidence to the exact product, version, and deployment environment being purchased. Sources for this answer: - [NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Supports supplier due diligence, fit-for-purpose review, contractual security requirements, and careful reuse of supplier documentation. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports writing procurement criteria around validated cryptographic modules and approved security functions rather than broad product claims. ## Gaps that should block an approved mode claim Treat gaps as procurement risks until resolved. The most common problem is an evidence mismatch: the certificate exists, but it covers a different module version, operating environment, processor family, cloud image, firmware build, or use of the cryptographic service than the one being bought. Algorithm evidence alone is not enough. CAVP validation supports the tested algorithm implementation; CMVP validation supports the cryptographic module. A procurement decision that needs FIPS 140-3 assurance should not convert a CAVP certificate, an AES implementation claim, or a vendor datasheet into a module validation claim. - The supplier cites only an algorithm certificate and cannot identify a CMVP-validated module for the delivered product. - The module certificate is Historical, Revoked, or otherwise not usable for the procurement decision being made. - The product runs on an operating environment that is not identical to, or covered by, the tested environment in the validation evidence. - The supplier cannot distinguish approved services from non-approved services or show how approved mode is indicated to the operator. - A product uses AES or another approved algorithm without identifying the FIPS-approved or NIST-recommended mode of operation and the validated module boundary. 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 blocking mismatched tested environments, unclear module boundaries, unsupported inherited-validation claims, and missing approved-service indicators. - [NIST FIPS 197-upd1 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Supports the distinction between AES as a FIPS-approved algorithm and the need to use it with a FIPS-approved or NIST-recommended mode of operation. ## Approved mode procurement checklist Use this checklist as a pre-award and renewal gate. It is intentionally narrow: each item should be answered with a certificate, Security Policy excerpt, supplier configuration statement, or explicit exception before procurement relies on the approved mode claim. - Identify the validated cryptographic module, CMVP certificate number, version, security level, and current validation status. - Attach the public Security Policy and mark the services the product will use in the buyer's deployment. - Verify CAVP evidence for the algorithm implementations behind those approved services, but keep it separate from the module-validation decision. - Match the delivered operating environment to the tested environment, including operating system, platform, processor, and hypervisor where relevant. - Document whether any embedded or bound validated module is used, including certificate number, version, and boundary relationship. - Write acceptance criteria for approved mode configuration, change notice, status changes, and exceptions for non-approved services. - Reject broad FIPS compliant claims when certificate status, module boundary, service use, or tested configuration cannot be verified. 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 checklist items tied to validated modules, approved security functions, security levels, and procurement use of CMVP validation. - [NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Supports procurement checklist items for supplier due diligence, contractual evidence, lifecycle support, and reassessment when documentation no longer fits. ## 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 module validation, approved security functions, security levels, and procurement use of the CMVP validated modules list. - Quote: "metric to use in procuring equipment" - [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 used for CAVP versus CMVP distinctions, tested operational environments, approved service indicators, and embedded or bound module evidence. - Quote: "CAVP addresses the testing" - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public lookup for validating supplier-provided CAVP algorithm certificate references. - Quote: "validation-search" - [NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Grounding for supplier due diligence, contractual requirements, documentation reuse, and lifecycle reassessment in procurement. - Quote: "set expectations and requirements for suppliers" - [NIST FIPS 197-upd1 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Grounding for the statement that AES is a FIPS-approved algorithm but must be used with a FIPS-approved or NIST-recommended mode of operation. - Quote: "Advanced Encryption Standard (AES)" ## Related Topic Guides - [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims. - [CAVP and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim. - [CAVP Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records. - [FIPS 180-4 and FIPS 202 secure hash guidance](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims. - [FIPS 186-5 and FIPS 204 digital signatures](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries. - [FIPS 203 ML-KEM vs RSA and ECDH key establishment](/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh.md): Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding. - [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md): FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks. - [FIPS Algorithm Procurement Evidence FAQ](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md): What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers. - [FIPS approved algorithm selector workflow](/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow.md): A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims. - [FIPS crypto transition and deprecation tracker](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status. - [FIPS cryptographic algorithm selector](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope. - [FIPS KDF and MAC coverage for validated modules](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries. - [FIPS Key Management Mapping for Algorithms and SSP Evidence](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records. - [FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records. - [FIPS validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md): How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims. - [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms. - [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md): Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation. - [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md): Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries. - [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries. - [Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ. - [Post-Quantum Migration for FIPS Cryptography](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries. - [Post-Quantum Migration Tracker for FIPS 203, 204, and 205](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries. - [SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202](/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3.md): Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required. - [TLS use-case mapping for FIPS algorithm evidence](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims. - [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md): FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation. --- [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-crypto-algorithms/approved-mode-procurement