---
title: "FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules"
canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow"
source_url: "https://www.sorena.io/artifacts/global/fips-140-3/algorithm-certificate-mapping-workflow"
author: "Sorena AI"
description: "Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 140-3"
  - "CAVP certificate mapping"
  - "CMVP validation"
  - "algorithm validation certificates"
  - "CAVP certificates"
  - "CMVP"
  - "cryptographic module validation"
  - "security policy evidence"
---
**[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: step-by-step workflow for mapping algorithm certificates to CMVP modules

Map CAVP algorithm certificates to a FIPS 140-3 module by matching implementation identity, operational environment, module services, and security policy evidence.

*Artifact Guide* *GLOBAL* *FIPS 140-3*

## FIPS 140-3 Algorithm Certificate Mapping Workflow

A workflow for deciding whether a CAVP algorithm certificate can support a FIPS 140-3 module claim.

Use it to align certificate numbers, implementation versions, operational environments, services, and Security Policy evidence before a CMVP submission or procurement review.

This workflow is for product security, validation, and procurement teams that need to connect CAVP algorithm validation certificates to a FIPS 140-3 cryptographic module. The page focuses on what the CMVP guidance actually asks teams to compare: the validated algorithm implementation, the tested operational environment, whether the implementation changed during integration, and how the module Security Policy and test evidence identify the algorithms used by each service.

## Start with the certificate-to-module fit check

Do not begin with a generic list of algorithms. Begin with one candidate CAVP certificate and one module service that plans to rely on it. CMVP Implementation Guidance 2.3.A says the algorithm validation certificate identifies the validated implementation name, version, and tested operational environment; the module certificate identifies the validated module name, version, and tested operational environment.

The first decision is therefore narrow: can this exact algorithm implementation, in this exact module build and environment, support the FIPS 140-3 claim? If the implementation was modified after CAVP testing, or if the module operational environment is not identical to or fully inclusive of the CAVP-tested environment, treat the mapping as unresolved until the lab confirms the path.

- Record the CAVP certificate number, algorithm name, implementation name, implementation version, and tested operational environment.
- Record the module name, module version, module type, claimed operational environment, and the service that will call the algorithm.
- Confirm whether the algorithm implementation was integrated unchanged into the module under test.
- Compare the CAVP-tested environment with the module environment before using the certificate in customer, procurement, or validation evidence.

Sources for this answer:

- [CMVP Implementation Guidance, section 2.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the certificate-mapping test: CAVP certificates identify the algorithm implementation and tested operational environment, and the module environment must match or include that tested environment.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Establishes that FIPS 140-3 applies to cryptographic modules and requires approved security functions for modules claiming conformance.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for checking CAVP algorithm certificates before adding them to a module evidence map.

## Build the mapping row for each service

A useful mapping row connects a module service to the algorithm evidence behind it. For each service, list the callable function or service name, the approved algorithm used, the CAVP certificate that supports that implementation, and the service indicator or Security Policy text that tells an operator when the approved algorithm is being used in an approved manner.

Keep protocol and component validation logic separate from raw algorithm certificates. CMVP guidance includes cases where CVL components, KDFs, key agreement pieces, entropy certificates, or protocol claims have their own documentation conditions. The mapping should show those limits instead of implying that a CAVP certificate validates an entire protocol or product.

- Use one row per module service, not one row per marketing feature.
- Separate approved algorithms, allowed algorithms, CVL components, entropy entries, and non-approved algorithms with no security claimed.
- Add any protocol, parameter, security-strength, key-size, or usage caveat that limits how the algorithm certificate can be used.
- Point each row to the Security Policy table or paragraph where the same claim is documented.

Sources for this answer:

- [CMVP Implementation Guidance, section 2.4.C](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports mapping algorithms to services because each service must indicate when it uses an approved algorithm, security function, or process in an approved manner.
- [CMVP Implementation Guidance, section 2.4.B](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports keeping CVL components and their usage restrictions distinct from broader module or protocol claims.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Provides the FIPS 140-3 basis for focusing on cryptographic module specification, interfaces, roles, services, authentication, self-tests, and lifecycle assurance.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize the certificate mapping workflow

Use this workflow to turn CAVP certificate lookups into service-level evidence rows that product, security, validation, and procurement reviewers can inspect.

- [Open Assessment Autopilot for FIPS 140-3](/solutions/assessment.md): Convert algorithm certificate mapping into owner-assigned evidence requests and review checkpoints.
- [Research FIPS 140-3 source questions](/solutions/research-copilot.md): Use cited NIST and CMVP source material to resolve certificate, environment, and service-indicator questions.
- [Talk through FIPS 140-3 certificate mapping](/contact.md): Review module scope, certificate evidence, operational environments, and unresolved validation questions with Sorena.

## Operational environment matching rules

For software modules, the mapping has to name the operating system, platform, and processor used for the module claim. If a hypervisor was part of the tested environment, include it. Do not generalize a certificate from one operating system to another, from a 32-bit processor to a 64-bit claim, or from one hardware implementation to another without grounded validation support.

The workflow should make environment mismatches visible early. A row that says only "AES certificate available" is not enough; the reviewer needs to know whether the CAVP certificate environment matches the module environment and whether the implementation was retested where required.

- Compare processor bit size, operating system, platform, and hypervisor details where they are part of the tested environment.
- For FPGA or hardware implementations, verify whether the validated hardware implementation is being reused unchanged or whether new hardware validation is needed.
- When CAVP testing was not performed directly by the CST lab, keep the vendor-supplied environment evidence and the lab verification record with the row.
- Do not carry a certificate into a new operational environment by assumption; document the lab-confirmed rationale or retest path.

Sources for this answer:

- [CMVP Implementation Guidance, section 2.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the operational-environment comparison rules for software, firmware, and hardware algorithm implementations embedded in a FIPS 140-3 module.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains that a cryptographic module may be hardware, software, firmware, or a combination, which is why the environment evidence differs by module type.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use the public CAVP search result as the starting point for certificate identity and environment evidence.

## Mapping table template

Use a compact row structure so reviewers can see whether the certificate supports the module claim without reading the whole Security Policy.

Row fields: module service; approved algorithm or component; CAVP certificate number; implementation name and version; CAVP-tested operational environment; module operational environment; Security Policy location; service indicator; caveat or usage restriction; change trigger.

Example decision outcomes: mapped with no change; mapped with caveat; cannot map because the implementation changed; cannot map because the operational environment does not match; hold for CST lab or CMVP guidance.

- Keep each row traceable to the same service and algorithm wording used in the Security Policy.
- Use "not claimed" when an algorithm exists in code but is not used to support an approved service.
- Use "no security claimed" only where the CMVP guidance supports that treatment for a non-approved algorithm in the approved mode.
- Keep unresolved rows out of public compliance claims until the lab has accepted the mapping or retesting path.

Sources for this answer:

- [CMVP Implementation Guidance, section 2.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports row-level fields for implementation identity, certificate identity, and tested operational environment.
- [CMVP Implementation Guidance, section 2.4.A](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 treatment of non-approved algorithms, including when no security is claimed and when certificate listing is not appropriate.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports keeping the mapping tied to approved security functions rather than broad product-level compliance statements.

## Change triggers that reopen the mapping

Treat the mapping as release evidence, not a one-time spreadsheet. Recheck rows when a cryptographic library changes, an algorithm implementation is patched, compiler or build flags affect the implementation, the processor or operating system changes, a hypervisor is added, a hardware implementation moves to a new device, or a service starts using a different algorithm path.

For modules relying on bound or embedded modules, keep the dependency visible. The IUT documentation and Security Policy need clear separation between the module under test and the embedded or bound validated module, including certificate number, version, service, algorithm, sensitive security parameter, self-test, and zeroisation distinctions where applicable.

- Trigger review when the module boundary, binary, algorithm implementation, operational environment, or service table changes.
- Trigger review when a bound or embedded validated module changes certificate number, version, approved status, or service exposure.
- Trigger review when PAA or PAI behavior is introduced, removed, or moved to a different processor path.
- Keep the change record with the mapping row so future reviewers can see why retesting was or was not required.

Sources for this answer:

- [CMVP Implementation Guidance, section 1.A and 2.3.A](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Grounds the need to track bound or embedded module evidence separately and to preserve implementation and environment fit for algorithm certificate mapping.
- [CMVP Implementation Guidance, section 2.3.C](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 for processor algorithm accelerators and processor algorithm implementations that affect algorithm execution paths.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Explains that conformance alone does not prove a particular module is secure, so operators still need release and residual-risk review.

## Common mapping mistakes

Most failures in this workflow come from over-reading an algorithm certificate. A CAVP certificate is evidence for a tested algorithm implementation in a tested environment; it is not a blanket validation of the whole module, product, protocol, cloud deployment, or future release.

The cleanest public claim is specific: name the module certificate or validation status separately from the algorithm certificate evidence, and do not state that a service is approved unless the service table, indicator, Security Policy, and certificate mapping support the claim.

- Do not map a CAVP certificate to a module after changing the algorithm implementation unless the change has a grounded validation path.
- Do not use a certificate tested on one operating system, processor bit size, platform, or hardware implementation as evidence for a different environment without lab-supported justification.
- Do not imply that CAVP testing validates an entire protocol when the guidance only supports tested algorithm or component claims.
- Do not hide non-approved algorithms in narrative text; identify whether they are outside the approved service, allowed with no security claimed, or disallowed for the approved mode.

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 main mapping risks: implementation changes, operational-environment mismatch, service indicators, non-approved functions, and protocol/component caveats.
- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Supports avoiding blanket security claims by noting that operators remain responsible for sufficiency and residual risk.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use public certificate lookup as evidence input, not as a substitute for module-level CMVP validation evidence.

## Primary sources

- [NIST FIPS 140-3](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary standard for FIPS 140-3 module scope, approved security functions, security levels, and operator responsibility for module sufficiency.
  - 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 grounding for algorithm certificate binding, operational-environment matching, approved service indicators, non-approved function treatment, and bound or embedded module documentation.
  - Quote: "Binding of Cryptographic Algorithm Validation Certificates"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public NIST search interface for finding CAVP algorithm validation certificates used as inputs to the mapping workflow.
  - Quote: "validation-search"

## Related Topic Guides

- [FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary](/artifacts/global/fips-140-3/algorithm-certificate-mapping.md): Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.
- [FIPS 140-3 Algorithm Certificates FAQ](/artifacts/global/fips-140-3/faq/algorithm-certificates.md): How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.
- [FIPS 140-3 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.
- [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-workflow