Artifact GuideGLOBALFIPS-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.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

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.

Section 1

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

Supports the distinction between a cryptographic module, its security level, its services, and approved key-management techniques.

CMVP Implementation Guidance for FIPS 140-3

Explains that CAVP tests approved security functions while CMVP validates cryptographic modules and their documented boundaries.

Section 2

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

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

Supports ML-KEM mapping as a key-encapsulation mechanism with encapsulation keys, decapsulation keys, ciphertexts, and shared secret keys.

Recommended next step

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.

Assessment workflow

Open Assessment Autopilot for FIPS evidence

Convert FIPS key-management mapping into owners, evidence requests, module records, and review checkpoints.

Explore next step

Research workflow

Research FIPS source questions

Use cited NIST material to resolve SSP establishment, algorithm validation, module boundary, and key-use questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS key management mapping

Review module scope, algorithm evidence, SSP methods, and unsupported validation claims with Sorena.

Explore next step

Section 3

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

Grounds the limits of CAVP evidence, operational-environment matching, bound and embedded module documentation, and approved-service indicators.

NIST CAVP validation search

Public search endpoint for looking up algorithm validation records referenced in a key-management evidence map.

Section 4

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

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

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

Supports the ML-KEM key-class mapping, including encapsulation key, decapsulation key, ciphertext, and shared secret key handling.

Section 5

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

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

Supports the evidence checklist for algorithm certificates, module Security Policy statements, approved services, and SSP establishment documentation.

Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3

csrc.nist.gov

Referenced sections

Supports the evidence checklist for algorithm certificates, module Security Policy statements, approved services, and SSP establishment documentation.