---
title: "FIPS Key Management Mapping for Algorithms and SSP Evidence"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/key-management-mapping"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/key-management-mapping"
author: "Sorena AI"
description: "Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 140-3 key management"
  - "SSP establishment"
  - "CAVP certificates"
  - "CMVP security policy"
  - "approved algorithms"
  - "FIPS 140-3"
  - "key management"
  - "CAVP 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 Key Management Mapping for Algorithms and SSP Evidence

Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.

*Artifact Guide* *GLOBAL* *FIPS-approved cryptographic algorithm requirements*

## FIPS key management mapping

Map each key-management use case to the approved algorithm, SSP establishment method, module boundary, and evidence record that can actually support the claim.

Grounded in NIST FIPS 140-3, CMVP implementation guidance, CAVP validation boundaries, FIPS 186-5, and FIPS 203.

Use this page when a product, module, or service needs a defensible map from key-management behavior to FIPS evidence. The map separates algorithm validation from module validation, distinguishes key agreement, key transport, key encapsulation, key derivation, key generation, and key entry, and keeps unsupported compliance or procurement claims out of release evidence.

## Start with the cryptographic boundary and key-management service

FIPS 140-3 applies to cryptographic modules, not to a product name in isolation. The key-management map should therefore start with the module boundary, tested operational environment, security level, service name, and the sensitive security parameters handled by that service.

For each service, record whether the behavior is key generation, key agreement, key transport, key encapsulation, key derivation, key entry, key output, storage protection, or zeroization. A single protocol or API can contain several of these behaviors, so the evidence should be service-level rather than marketing-level.

- Identify the module or embedded/bound module by name, version, CMVP certificate status, and operational environment before reusing evidence.
- List every SSP handled by the service: private keys, secret keys, public security parameters, authentication data, seeds, shared secrets, and derived keying material.
- Tie each service to the approved algorithms or approved SSP generation and establishment methods it actually invokes.
- Keep protocol claims separate from algorithm and scheme claims because CMVP guidance treats protocols differently from tested cryptographic algorithms and schemes.

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 distinction between a cryptographic module, its security level, its services, and approved key-management techniques.
- [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 approved security functions while CMVP validates cryptographic modules and their documented boundaries.

## Map each SSP establishment method to the right FIPS evidence

CMVP guidance groups SSP establishment into distinct methods. The mapping should not collapse them into a generic key-management control because each method has different certificate entries, self-test expectations, security-policy statements, and caveats.

Use separate rows for key agreement, key transport, key encapsulation, key derivation, key generation, key entry, and pre-loaded keys. The row should name the standard or implementation-guidance path, the CAVP algorithm entry when applicable, and whether the module certificate or Security Policy needs a specific annotation.

- Key agreement: map SP 800-56A, SP 800-56B, KAS-SSC, KDA, and optional key-confirmation components without treating a shared-secret primitive as a full scheme.
- Key transport: map RSA-based KTS and symmetric key wrapping separately, including the wrapping algorithm, authentication coverage, and CAVP certificate numbers.
- Key encapsulation: map ML-KEM or other KEM support as automated SSP establishment, including parameter set, key checking, and decapsulation-key protection.
- Key derivation: distinguish protocol KDFs, SP 800-56C KDA, SP 800-108 derivation from existing keying material, and SP 800-132 password-based derivation for storage applications only.
- Manual or electronic SSP entry/output: map the boundary crossing, protection method, and whether the Security Policy explains the operator responsibilities.

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 SSP establishment taxonomy and the key agreement, key transport, key encapsulation, and key derivation evidence paths.
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports ML-KEM mapping as a key-encapsulation mechanism with encapsulation keys, decapsulation keys, ciphertexts, and shared secret keys.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize FIPS key management mapping

Use this map to connect key-management behavior to module boundaries, algorithm certificates, SSP methods, and reviewable evidence without overstating validation scope.

- [Open Assessment Autopilot for FIPS evidence](/solutions/assessment.md): Convert FIPS key-management mapping into owners, evidence requests, module records, and review checkpoints.
- [Research FIPS source questions](/solutions/research-copilot.md): Use cited NIST material to resolve SSP establishment, algorithm validation, module boundary, and key-use questions before implementation.
- [Talk through FIPS key management mapping](/contact.md): Review module scope, algorithm evidence, SSP methods, and unsupported validation claims with Sorena.

## Do not overstate algorithm certificates

A CAVP certificate supports a tested algorithm implementation in a tested operational environment. It does not, by itself, prove that the finished product, service, protocol, or deployment is a validated FIPS 140-3 module.

When a validated algorithm is integrated into a module, the map should verify whether the implementation was modified and whether the operational environment matches the one used for algorithm testing. If the algorithm is used through a bound or embedded validated module, the Security Policy and validation report should identify the external validated module and mark the reused services, algorithms, SSPs, self-tests, and zeroization mechanisms clearly.

- Record CAVP certificate number, algorithm name, implementation version, tested operational environment, and whether hardware acceleration or PAA/PAI paths are involved.
- For bound or embedded modules, record the existing validated module name, version, CMVP certificate number, active status at submission, and the subset of functionality used.
- For protocol claims, state which cryptographic algorithms or KDFs were tested and avoid implying that the full protocol was tested by CAVP or CMVP unless source evidence says so.
- For approved-service indicators, verify that the algorithm has the needed certificate and self-tests before representing a service as approved.

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 limits of CAVP evidence, operational-environment matching, bound and embedded module documentation, and approved-service indicators.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search endpoint for looking up algorithm validation records referenced in a key-management evidence map.

## Use strength and key-purpose rules as map columns

The most useful key-management map shows whether the establishment method is at least as strong as the keying material it establishes or protects. CMVP guidance reproduces comparable-strength rows from SP 800-57 and explains that weaker establishment methods can require certificate and Security Policy caveats.

Key-purpose separation also belongs in the map. FIPS 186-5 states that a key pair used for digital signature generation and verification under that standard must not be used for another purpose such as key establishment. This prevents a common evidence error: treating one public/private key pair as reusable across unrelated signing and establishment services.

- Add columns for target security strength, established key strength, establishment-method strength, and any caveat needed when they do not match.
- Mark signing keys, decapsulation keys, key-wrapping keys, key-derivation keys, authentication secrets, and stored keys as separate key classes.
- Record whether private keys, per-message secret numbers, seeds, shared secrets, and derived keys require private handling or destruction after use.
- For ML-KEM, record parameter set, encapsulation-key checking, decapsulation-key checking, ciphertext checking, and private handling for the decapsulation key and shared secret key.

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 strength comparison for SSP establishment and caveat handling when establishment strength is lower than established key strength.
- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Supports the key-purpose rule that signature key pairs under FIPS 186-5 are not reused for key establishment.
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports the ML-KEM key-class mapping, including encapsulation key, decapsulation key, ciphertext, and shared secret key handling.

## Evidence checklist for a FIPS key-management map

Use the checklist as an evidence gate before publishing a FIPS claim, responding to an auditor, or relying on a supplier statement. The output should be a traceable table, not a general assurance paragraph.

The checklist is intentionally limited to evidence that can be tied to NIST FIPS and CMVP/CAVP sources. Procurement requirements, customer controls, and internal policies can reference the map, but they should remain separate from the source-linked FIPS claim.

- Scope: module name, version, boundary, operational environment, security level, certificate status, and services covered.
- SSP inventory: private keys, secret keys, public security parameters, authentication data, seeds, shared secrets, derived keys, and stored keys.
- Method map: key generation, agreement, transport, encapsulation, derivation, entry/output, storage protection, and zeroization rows.
- Algorithm evidence: CAVP certificate number, algorithm or component name, tested operational environment, implementation version, and self-test coverage.
- Module evidence: CMVP certificate, Security Policy excerpts, approved-service indicators, caveats, bound or embedded module references, and change-impact notes.
- Exception record: unsupported algorithm reuse, mismatched strength, untested protocol claims, non-approved security functions, or missing operational-environment 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) - Supports using module validation evidence rather than product-wide claims as the foundation for FIPS key-management mapping.
- [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 evidence checklist for algorithm certificates, module Security Policy statements, approved services, and SSP establishment documentation.

## Primary sources

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS source for cryptographic module scope, approved security functions, key-management techniques, and CMVP validation context.
  - Quote: "cryptographic key management techniques"
- [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 for CAVP/CMVP boundaries, SSP establishment methods, key agreement, key transport, key encapsulation, KDF treatment, and Security Policy evidence.
  - Quote: "SSP establishment is the process"
- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary source for signature key-pair handling, private-key protection, and the prohibition on reusing signature key pairs for other purposes.
  - Quote: "shall not be used for any other purpose"
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary source for ML-KEM key encapsulation, key classes, parameter sets, and input-checking considerations in key-establishment maps.
  - Quote: "decapsulation key shall remain private"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public validation-search endpoint for checking algorithm certificate records before citing CAVP evidence.
  - Quote: "validation-search"

## 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 approved mode procurement: certificates, boundaries, and evidence](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.
- [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 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/key-management-mapping