--- title: "FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/algorithm-certificate-mapping" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/algorithm-certificate-mapping" author: "Sorena AI" description: "Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "FIPS 140-3" - "CAVP certificates" - "CMVP validation" - "approved security functions" - "cryptographic module security policy" - "CAVP" - "CMVP" - "algorithm certificates" - "cryptographic modules" --- **[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 algorithm certificate mapping: ACVTS certificates to module boundary Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence. *Artifact Guide* *GLOBAL* *FIPS 140-3* ## FIPS 140-3 Algorithm Certificate Mapping Connect each CAVP algorithm certificate to the FIPS 140-3 module service, boundary, approved mode, and security policy claim that relies on it. Use this as implementation support for validation and procurement reviews, not for legal interpretation or a substitute for CMVP, CAVP, or lab direction. Algorithm certificate mapping is the traceability work that shows which tested cryptographic algorithm implementations support a FIPS 140-3 module claim. The useful output is not a generic certificate inventory; it is a service-by-service map from module boundary and approved mode claims to CAVP certificates, approved security functions, vendor-affirmed or component entries, and the security policy tables where those claims appear. ## What the mapping must prove Start with the FIPS 140-3 module claim, not with a library list. FIPS 140-3 requires conforming modules to employ Approved security functions, including algorithms specified in a FIPS, adopted in a FIPS, listed in SP 800-140C, or specified in SP 800-140D for sensitive security parameter establishment methods. The CMVP Implementation Guidance describes CAVP as the program that tests Approved Security Functions and Approved Sensitive Security Parameter Generation and Establishment Methods referenced by the SP 800-140 series. For a visitor reviewing a module, the mapping should therefore answer four questions: which module service uses the algorithm, which approved function or method the service relies on, which CAVP certificate or documented entry supports the implementation, and where the claim appears in the security policy or validation package. - Identify the cryptographic module boundary and the exact service using the algorithm implementation. - Classify the algorithm entry as approved, vendor affirmed, non-approved allowed, non-approved allowed with no security claimed, or non-approved not allowed when the validation materials require that distinction. - Record the CAVP certificate details from the public validation search when a CAVP certificate is the evidence source. - Tie the certificate entry to the security policy table, validation test report evidence, and any approved-mode indicator that depends on the algorithm. 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 requirement that conforming modules use Approved security functions and names FIPS, SP 800-140C, and SP 800-140D as approval sources. - [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 the role of CAVP testing and gives detailed security-policy mapping expectations for algorithm certificates, services, and bound or embedded modules. *Recommended next step* *Placement: after certificate mapping guidance* ## Operationalize FIPS 140-3 algorithm certificate mapping Use a service-by-service certificate map to keep CAVP evidence, module boundaries, security policy tables, and procurement claims aligned. - [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert algorithm certificate mapping into review tasks, evidence requests, and owner-ready validation checks. - [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited NIST and CMVP materials to resolve certificate, boundary, approved-mode, and security policy questions. - [Talk through FIPS 140-3 certificate mapping](/contact.md): Review module scope, CAVP evidence, reused-module dependencies, and the next validation actions with Sorena. ## Fields to capture for each certificate row A strong mapping table should be precise enough for an engineer, lab reviewer, or procurement reviewer to find the same claim again. Avoid rows that say only "AES" or "approved crypto"; those labels do not show the implementation, mode, parameter set, service, or certificate evidence behind the FIPS 140-3 claim. For each row, capture the algorithm name as shown in the validation evidence, the CAVP certificate identifier or documented validation entry, the module service that invokes it, the approved-mode use, relevant parameters or restrictions, and the source table where the claim is published. If the service uses only part of another validated module, list only the functionality the module actually uses. - Algorithm and capability: name, mode or component label, revision, key size, curve, hash, security strength, or other parameter that changes the approval claim. - Evidence pointer: CAVP certificate number or validation-search entry, vendor-affirmed entry, CVL notation, entropy evidence, or non-approved algorithm table entry as applicable. - Module use: service name, approved or non-approved service table row, SSP relationship, self-test relationship, and whether the use is internal or operator-accessible. - Scope guardrail: operating environment, module version, embedded or bound module dependency, and any usage restriction carried in the security policy. 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) - Provides the WebCryptik table mapping expectations, including CAVP certificate table marking, algorithm categories, security function implementations, services, SSPs, self-tests, and error states. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source for looking up CAVP validation entries that can be cited in an algorithm-certificate evidence row. ## Handle bound, embedded, and reused modules carefully Certificate reuse is where many mappings become misleading. The CMVP Implementation Guidance distinguishes an implementation under test from an existing validated module and requires clear separation of information associated with each. When an implementation under test uses an existing validated module, the security policy and validation test report must identify the existing module by name, CMVP certificate number, and version, and cite only the functionality actually used. This means a mapping cannot simply import every algorithm on another module certificate. It must show the reused service or algorithm, the relationship to the module boundary, whether the existing module is embedded or bound, and whether the reused function is approved at the time it is claimed in the submission. - Mark reused existing-validated-module entries distinctly, including the existing module name, CMVP certificate number, version, and the subset of services or algorithms used. - For bound software, firmware, or hybrid modules, verify that the tested operational environments align as described in the CMVP guidance before reusing the certificate relationship. - Do not claim unused algorithms from an existing module; keep the mapping limited to services, algorithms, SSPs, self-tests, and other security policy entries actually relied on by the implementation under test. - Track historical or revoked status separately from algorithm evidence because CMVP guidance links an implementation under test to the status of a relied-on existing validated 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) - Grounds the embedded and bound module handling, including the requirement to identify existing validated modules and clearly distinguish their algorithms and services from the implementation under test. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Grounds the CMVP validation context for cryptographic modules and the role of validated modules in federal procurement. ## Review checks before relying on the map Use the mapping as a validation-control artifact, not as a static appendix. Review it whenever the module boundary, cryptographic library, operating environment, algorithm implementation, parameter set, bound or embedded dependency, or security policy service table changes. The review should produce concrete corrections: remove certificate rows for unused functions, split rows where one algorithm appears in different services with different restrictions, add usage limits for component validations, and update the approved-mode evidence when an implementation moves between approved, vendor-affirmed, allowed, or no-security-claimed treatment. - Confirm that every approved service row points to the algorithm certificate or documented entry that supports the security claim. - Confirm that component validation list entries carry their usage restriction and are not presented as unrestricted standalone services. - Confirm that non-approved algorithms are not used as security functions in the approved mode unless the CMVP guidance explicitly supports the documented treatment. - Confirm that the public-facing security policy, internal validation evidence, and procurement response use the same certificate identifiers and module versions. 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 review checks for component validation list entries, approved services, non-approved algorithms, and security-policy treatment. - [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use to verify that cited algorithm certificate identifiers and capability labels match the public CAVP record. ## Common mapping errors Most certificate-mapping errors come from overstating what a certificate proves. A CAVP algorithm validation supports an implementation-specific algorithm claim; it does not by itself validate the cryptographic module, its boundary, its approved mode, or every service that happens to call the same library. Treat each mismatch as a validation risk until it is resolved in the security policy, test report, or source evidence. The safest correction is usually to narrow the claim: show the exact service, algorithm capability, certificate entry, parameter set, and approved-mode condition that the module can support. - Do not equate a CAVP algorithm certificate with a full CMVP module validation. - Do not reuse another module's certificate rows unless the bound or embedded module relationship is documented and the used functionality is limited to the actual dependency. - Do not list algorithms that are present in a library but outside the validated module boundary or outside the claimed approved-mode service. - Do not omit usage restrictions for CVL entries, pre-hashed signature components, key agreement components, or other component tests that are approved only in a defined context. 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) - Distinguishes CAVP algorithm testing from CMVP module validation and describes restrictions on components, reused modules, and non-approved security functions. - [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Grounds the distinction between a cryptographic module validation and the approved security functions used by that module. ## 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 scope, CMVP context, and approved security function requirements. - Quote: "shall employ 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) - Primary program guidance for CAVP testing, binding of algorithm validation certificates, component validation list entries, existing validated module reuse, and security-policy table mapping. - 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 source for CAVP algorithm validation records cited in certificate-mapping evidence. - Quote: "validation-search" ## Related Topic Guides - [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 Applicability Test](/artifacts/global/fips-140-3/applicability-test.md): 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. - [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/algorithm-certificate-mapping