---
title: "FIPS KDF and MAC coverage for validated modules"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage"
author: "Sorena AI"
description: "Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS 140-3 KDF coverage"
  - "FIPS MAC coverage"
  - "HMAC truncation"
  - "CAVP KDF validation"
  - "CMVP service indicator"
  - "FIPS 140-3"
  - "KDF coverage"
  - "HMAC"
  - "CAVP"
  - "CMVP"
---
**[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 KDF and MAC coverage for validated modules

Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.

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

## FIPS KDF and MAC coverage for validated modules

Use this page to separate approved KDF and MAC algorithm coverage from FIPS 140-3 module validation, service indicators, self-tests, and security policy evidence.

Grounded in NIST FIPS 140-3, CMVP implementation guidance, CAVP validation expectations, and FIPS 202 HMAC/SHA-3 guidance.

KDF and MAC coverage should be documented at the module service level, not as a broad claim that a library is FIPS-compliant. The useful evidence is a map of each key-derivation or message-authentication service to its approved use case, CAVP or CVL evidence, cryptographic algorithm self-test requirement, service indicator, and Security Policy wording.

## Define which KDF or MAC service is being claimed

Start by naming the exact service: HMAC, truncated HMAC, KBKDF under SP 800-108, PBKDF under SP 800-132, KDA under SP 800-56C, a protocol KDF such as TLS, or a key-wrapping construction that combines encryption with HMAC, CMAC, or KMAC.

FIPS 140-3 requires conforming cryptographic modules to employ approved security functions. CMVP implementation guidance then makes the evidence more granular: approved security services need indicators, and the module Security Policy must list approved and non-approved services with the details needed to interpret those indicators.

- Record the service name, callable API or operation, algorithm family, mode, underlying hash or auxiliary function, and whether the service is approved, allowed, non-approved but allowed, or not available in approved mode.
- For KDFs, distinguish SP 800-108 derivation from a pre-shared key, SP 800-56C KDA used in key establishment, SP 800-132 password-based derivation for storage applications, and protocol KDFs listed as CVL components.
- For MACs, distinguish full-length HMAC from truncated HMAC and record the hash family, tag length, HMAC key strength, and whether CAVP testing covers the truncated form.
- Tie every public or procurement statement to the module boundary and tested operational environment; an algorithm certificate is not the same thing as a validated cryptographic module.

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) - Defines approved security functions for conforming cryptographic modules and distinguishes module validation from general algorithm approval.
- [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 service indicators, approved security services, Security Policy listings, KDF self-tests, truncated HMAC, and KDF-specific CMVP guidance.

## Map each KDF to the right approved-use lane

The most common KDF error is treating all key derivation as one bucket. CMVP guidance separates key derivation from a pre-shared key, key derivation during approved key establishment, password-based derivation for storage, and protocol-specific KDF components.

SP 800-108 KDFs are approved for deriving new keys from existing keying material when the key derivation key has been generated, entered, or established by a method approved or allowed in approved mode. They are not for directly generating asymmetric keys. SP 800-56C KDA belongs to key-establishment schemes, and CMVP guidance also identifies a no-iteration, no-counter one-step KDF variation with CAVP testing under KDA OneStepNoCounter.

- KBKDF: document the SP 800-108 option, PRF, key derivation key source, derived-key use, and CAVP certificate coverage.
- KDA: document whether the module implements one-step, two-step, or OneStepNoCounter SP 800-56C behavior, the auxiliary function, length limits, and key-establishment scenario.
- PBKDF: document that SP 800-132 password-based derivation is used only for storage applications, with Security Policy justification for password/passphrase length and iteration-count choices.
- TLS KDF: record whether the implementation supports RFC 5246 or RFC 7627 extended master secret behavior; CMVP guidance says untested TLS 1.2 KDF versions must not be used in approved mode.

Sources for this answer:

- [CMVP Implementation Guidance for SP 800-108 KDFs](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - IG D.M states how SP 800-108 KDFs fit when deriving new keys from existing keying material in approved mode.
- [NIST SP 800-53 Rev. 5 key establishment discussion](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - SC-12 points implementers to SP 800-56A, SP 800-56B, and SP 800-56C for key-establishment schemes and key-derivation methods.

## Document MAC coverage without overclaiming HMAC approval

HMAC coverage needs more than naming the hash. CMVP guidance requires a CAST for implemented HMAC using at least one implemented SHA-1, SHA-2, or SHA-3 algorithm, and it gives separate rules for truncated HMAC use in approved mode.

For truncated HMAC, the page evidence should show the leftmost tag length, CAVP validation of the applicable truncated HMAC, Security Policy disclosure, and key-strength limits. CMVP guidance allows approved truncated HMAC forms when the output is truncated to at least 32 leftmost bits, while also noting that truncations below 64 bits are discouraged by SP 800-107rev1.

- Capture the HMAC variant, hash family, tag length, key generation method, key strength, and whether the same implementation is also embedded inside a KDF, DRBG, protocol, or key-wrap service.
- For HMAC-SHA-3, include the FIPS 202 input block size used by the HMAC specification and avoid describing SHAKE128 or SHAKE256 as approved hash functions.
- When HMAC, CMAC, or KMAC is used with encryption for key wrapping, show that the entire wrapped message is authenticated and that the relevant algorithms have CAVP certificate evidence.
- Do not imply that a MAC used inside one approved service automatically makes every service that calls the same primitive approved.

Sources for this answer:

- [CMVP Implementation Guidance on truncated HMAC](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - IG C.D gives the approved-mode conditions for truncated HMAC, including CAVP validation and Security Policy disclosure.
- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Provides SHA-3 HMAC context and states that SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are approved hash functions.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize KDF and MAC coverage

Use this FIPS KDF and MAC coverage map to collect service-level evidence, certificate references, self-test notes, and Security Policy language before making approved-mode claims.

- [Open Assessment Autopilot for FIPS evidence](/solutions/assessment.md): Convert KDF and MAC coverage into scoped evidence requests, owner assignments, and review gates.
- [Research FIPS source questions](/solutions/research-copilot.md): Use cited NIST and CMVP source material to resolve KDF, MAC, CAVP, and service-indicator questions before implementation.
- [Talk through FIPS algorithm coverage](/contact.md): Review module scope, certificate evidence, approved-mode wording, and the next validation evidence actions with Sorena.

## Build the evidence table reviewers will expect

A reviewer should be able to trace each claimed KDF or MAC service from the Security Policy to the CAVP or CVL evidence and back to the shipped module configuration. The evidence table should not just say approved; it should explain the approved manner of use.

For FIPS 140-3, CMVP guidance on algorithm certificate binding is especially important. The CAVP certificate has to match the name and version of the validated algorithm implementation and the tested operational environment, and the embedded implementation must not be modified when integrated into the module under test.

- Columns to include: service, algorithm or component, standard or IG lane, approved-use condition, operational environment, CAVP or CVL certificate number, CAST requirement, service indicator, Security Policy section, and exception notes.
- For software modules, compare operating system, platform, processor, and hypervisor details where relevant before reusing CAVP evidence.
- For each KDF or MAC service, record whether the CAST is direct, covered by a higher-level algorithm self-test, or specifically required by IG 10.3.A notes for KDFs and TLS KDF modes.
- For services that can be used in approved and non-approved ways depending on caller input, document the approved-use rules in the Security Policy and expose an unambiguous service indicator.

Sources for this answer:

- [CMVP Implementation Guidance on algorithm certificate binding](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - IG 2.3.A describes how algorithm validation certificates bind to module configuration and operational environment during FIPS 140-3 testing.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search entry point for checking CAVP algorithm validation records before citing certificate evidence.

## Avoid common KDF and MAC coverage gaps

Most coverage gaps are caused by collapsing separate CMVP concepts into one compliance sentence. Keep algorithm validation, module validation, approved-mode service use, Security Policy wording, and operational-environment binding separate.

Use the checklist below as a release or audit gate before publishing FIPS KDF or MAC claims, responding to procurement questions, or preparing module evidence.

- Do not cite a CAVP certificate unless the algorithm implementation, version, and tested operational environment match the module configuration being claimed.
- Do not describe SP 800-108 as a general asymmetric-key generator; CMVP guidance limits it to deriving new keys from existing keying material.
- Do not use a TLS 1.2 KDF version in approved mode when that version is not CAVP tested for the module.
- Do not treat an HMAC truncation as approved unless the truncated form is CAVP validated, disclosed in the Security Policy, and uses an HMAC key with acceptable strength.
- Do not rely on a Security Policy paragraph alone as the service indicator; CMVP guidance says the module must provide an externally accessible, unambiguous indication.

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 the gap checks for service indicators, SP 800-108 KDF limits, TLS KDF testing, CAST expectations, and truncated HMAC disclosure.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS 140-3 source for approved security function requirements within conforming cryptographic modules.

## Primary sources

- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary standard for approved security functions and FIPS 140-3 module validation context.
  - Quote: "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) - Grounding for service indicators, CAVP certificate binding, KDF CASTs, SP 800-108 use, TLS KDF transition guidance, and truncated HMAC conditions.
  - Quote: "Implementation Guidance for FIPS PUB 140-3"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public search page for validating CAVP algorithm certificate evidence cited in module documentation.
  - Quote: "validation-search"
- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Source for SHA-3 approved hash functions, HMAC input block sizes, and KDF-related XOF cautions.
  - Quote: "SHA3-224, SHA3-256, SHA3-384, and SHA3-512"
- [NIST SP 800-53 Rev. 5 security and privacy controls](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - SC-12 context for key establishment and key management references to SP 800-56A, SP 800-56B, SP 800-56C, CMVP, and CAVP.
  - Quote: "key derivation methods"

## 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 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/kdf-and-mac-coverage