---
title: "FIPS crypto transition and deprecation tracker"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker"
author: "Sorena AI"
description: "Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS algorithm transition"
  - "FIPS algorithm deprecation"
  - "CAVP certificate evidence"
  - "CMVP module validation"
  - "FIPS 186-5 transition"
  - "TLS KDF extended master secret"
  - "Triple-DES limits"
  - "FIPS algorithms"
  - "CAVP evidence"
  - "CMVP validation"
  - "cryptographic transition"
  - "algorithm deprecation"
---
**[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 crypto transition and deprecation tracker

Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.

*Artifact Guide* *GLOBAL* *FIPS cryptographic algorithms*

## FIPS crypto algorithm transition tracker

Track algorithm status, CAVP certificate evidence, CMVP module impact, Security Policy wording, and procurement consequences when NIST guidance changes.

Use this as implementation guidance for evidence reviews and change control, not for legal interpretation or a substitute for current CMVP notices.

Use this tracker when a product, procurement review, validation package, or customer assurance answer depends on whether a FIPS algorithm, parameter set, protocol KDF, or module claim is still acceptable. The central discipline is separation: algorithm approval, CAVP algorithm validation, CMVP module validation, and approved-mode use are related, but they are not the same claim.

## Track the claim before tracking the date

Start each entry by naming the exact claim under review. A transition may affect a FIPS publication, a CAVP algorithm certificate, a cryptographic module Security Policy, a protocol mode, a procurement requirement, or a customer-facing statement. Treat those as separate rows so an approved primitive is not accidentally described as a validated product.

FIPS 140-3 requires conforming cryptographic modules to employ Approved security functions, including algorithms specified in a FIPS, adopted by a FIPS, or specified in the SP 800-140 series. That makes the tracker useful only when it connects the algorithm decision to a module boundary, approved-mode service, operating environment, and evidence pack.

- Record the affected algorithm or method, such as a signature algorithm, hash function, KDF, DRBG option, Triple-DES use, or post-quantum parameter set.
- State whether the row is about algorithm approval, CAVP testing, CMVP validation, Security Policy disclosure, procurement acceptability, or operational use.
- Attach the module certificate, Security Policy version, CAVP certificate number, implementation name, operating environment, and product release that rely on the claim.
- Do not use a transition row to create a new deadline unless the date appears in the grounded NIST source or current CMVP notice being cited.

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 approved security functions and the cryptographic module boundary where FIPS 140-3 claims are made.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Use this public search when the tracker needs algorithm certificate evidence rather than broad statements about approval.

## Use concrete transition rows, not generic status labels

A useful transition tracker names the source, the old allowance, the new requirement, the affected validation path, and the evidence owner. FIPS 186-5 is a clear example: it superseded FIPS 186-4, allowed a one-year transition period after publication, and said the implementation schedule for cryptographic modules undergoing CMVP validation would be posted by NIST under CMVP notices.

The same pattern appears in CMVP implementation guidance. For the TLS 1.2 KDF, guidance distinguishes already-validated modules from new validations or revalidations that extend the module sunset date, and requires the Security Policy to identify which TLS 1.2 KDF versions the module supports. That is a module evidence issue as much as an algorithm issue.

- For FIPS 186-5 transition rows, identify whether the module or practice still depends on FIPS 186-4 tests, FIPS 186-5 tests, or mathematically equivalent evidence recognized by current CMVP guidance.
- For TLS KDF rows, track whether RFC 5246 or RFC 7627 extended master secret behavior is supported, tested, and stated in the Security Policy.
- For hash and DRBG rows, record whether the concern is the underlying FIPS hash family, the DRBG mechanism, or the specific CMVP transition guidance for new validations and revalidations.
- For Triple-DES rows, record whether the use is encryption, wrapping, decryption, legacy compatibility, or an approved-mode service with module-enforced limits.

Sources for this answer:

- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Grounds the FIPS 186-4 to FIPS 186-5 transition example and the warning that module validation schedules are handled through CMVP notices.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Grounding data for the CMVP implementation guidance points to this public CAVP search; use it to verify algorithm certificate evidence when transition rows depend on testing status.

## Separate algorithm status from module validation status

An algorithm can be specified in a FIPS publication while the implementation still needs CAVP evidence and the enclosing cryptographic module still needs CMVP validation for the claimed boundary. FIPS 180-4 says only algorithm implementations validated by NIST are considered as complying with that standard, while FIPS 202 says SHA-3 functions may be implemented in software, firmware, hardware, or combinations and points to validation by CAVP.

For visitor-facing procurement and audit use, the safest wording is precise: cite the FIPS publication for the algorithm family, the CAVP record for the tested implementation, and the CMVP certificate or Security Policy for the validated module and approved-mode service.

- Use FIPS 180-4 and FIPS 202 to identify the hash or XOF family, not to claim that a product or protocol is validated.
- Use CAVP records to evidence tested algorithm implementations, including the algorithm, mode, revision, vendor, implementation, and certificate status.
- Use the CMVP validated module record and Security Policy to evidence module boundary, approved services, non-approved services, operational environment, and sunset or historical status.
- If procurement language asks for FIPS validated products, do not satisfy it with only a FIPS algorithm citation or a CAVP certificate.

Sources for this answer:

- [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Supports the rule that hash algorithm implementations need validation evidence for compliance with the Secure Hash Standard.
- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Supports SHA-3 and SHAKE tracking, including the distinction between approved SHA-3 hashes and SHAKE XOF uses.

## Evidence fields every tracker row should keep

The tracker should be useful after the original reviewer leaves. Each row should preserve enough evidence for a later engineer, buyer, assessor, or auditor to reconstruct why the algorithm stayed, changed, moved to legacy-only use, or was removed.

CMVP transition guidance often turns on facts that are easy to lose: whether a submission is new, whether a revalidation extends a module sunset date, whether a version is CAVP tested, whether the Security Policy states the supported version, and whether the module itself enforces limits rather than relying only on policy.

- Source: NIST publication or CMVP guidance section, source URL, quoted phrase, date stated by the source, and review date for your internal copy of the row.
- Scope: algorithm, mode, parameter set, protocol use, module certificate, Security Policy section, operating environment, product release, supplier component, and customer claim.
- Decision: keep, replace, restrict to verification/decryption, remove from approved-mode service, update Security Policy, require new CAVP evidence, or request vendor clarification.
- Trigger: new validation, revalidation that extends sunset date, new operating environment, cryptographic library change, hardware acceleration change, protocol change, supplier change, or procurement clause change.
- Proof: CAVP certificate, CMVP certificate, Security Policy excerpt, design review, configuration evidence, test output, exception approval, and owner sign-off.

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 keeping module-level evidence tied to the FIPS 140-3 validation boundary and approved security functions.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Supports the certificate-evidence field for tested algorithm implementations.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize FIPS transition tracking

Use this tracker to assign owners, request certificate evidence, review module boundaries, and close procurement questions without blurring algorithm and module validation claims.

- [Open Assessment Autopilot for FIPS evidence](/solutions/assessment.md): Convert transition rows into accountable tasks, certificate requests, review owners, and evidence checkpoints.
- [Research FIPS source questions](/solutions/research-copilot.md): Use cited NIST material to resolve algorithm status, validation evidence, and procurement wording before implementation.
- [Talk through FIPS transition implementation](/contact.md): Review module boundaries, CAVP evidence, vendor answers, and next compliance actions with Sorena.

## Procurement and change-control triggers

Procurement teams should treat transition rows as contract evidence, not as a one-time spreadsheet. FIPS 140-3 says agencies should develop plans for products compliant with FIPS 140-3 and notes that the CMVP historical list should not be used for procurement decisions. That means procurement evidence should include current module status and the source behind any exception or legacy allowance.

Engineering change control should reopen a row whenever the cryptographic implementation, library, protocol, hardware path, operational environment, Security Policy wording, or module certificate status changes. The tracker should say whether the change requires only an internal evidence update, a vendor clarification, new CAVP evidence, CMVP revalidation analysis, or replacement of the algorithm.

- Ask vendors for the CMVP certificate, Security Policy, CAVP certificate references, algorithm and mode list, operating environment coverage, and sunset or historical status.
- Reject responses that say only "FIPS compliant" without naming whether the claim is algorithm approval, CAVP validation, or CMVP module validation.
- Add a procurement hold when a module depends on historical-list evidence, unsupported algorithm status, missing Security Policy disclosure, or an untested protocol/KDF version.
- Require a change review when a product enables or disables algorithms, adds post-quantum algorithms, changes TLS/KDF behavior, changes DRBG settings, or moves cryptography between libraries or processors.

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) - Grounds procurement caution around FIPS 140-3 compliant products and the warning not to use the CMVP historical list for procurement decisions.
- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Supports change-control tracking where signature implementations move from FIPS 186-4 dependencies to FIPS 186-5 claims.

## Reviewer checklist for deprecation decisions

Use this checklist before publishing a customer statement, procurement answer, or internal exception. The goal is to make the row defensible without requiring a future reviewer to infer which source, certificate, or module boundary mattered.

- Does the row identify the exact algorithm, mode, parameter set, protocol use, implementation, and module boundary?
- Does the evidence distinguish FIPS publication status, CAVP certificate evidence, CMVP module validation, and approved-mode use?
- Does every transition date or withdrawal status come from a cited NIST source, rather than memory or a copied spreadsheet?
- Does the Security Policy state the supported version or limit when CMVP guidance requires disclosure or module enforcement?
- Does the procurement answer avoid broad "FIPS compliant" wording unless it names the certificate, boundary, standard, and use case behind the claim?
- Is there a next action for the owner: retain, replace, restrict, retest, revalidate, ask the vendor, or remove the claim?

Sources for this answer:

- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Supports careful wording for SHA-3 and SHAKE entries so XOF approval is not overstated as ordinary hash-function use.
- [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Supports source-linked review of SHA-1 and SHA-2 family hash claims and their validation evidence.

## 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 module-level FIPS 140-3 requirements, approved security functions, procurement caution, and CMVP validation framing.
  - Quote: "Approved security functions include"
- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary source for the FIPS 186-4 to FIPS 186-5 transition example and signature-standard implementation schedule language.
  - Quote: "FIPS 186-4 remains in effect for a period of one year"
- [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary source for SHA-1 and SHA-2 family hash algorithms and validation framing.
  - Quote: "Only algorithm implementations that are validated by NIST"
- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary source for SHA-3 hash functions, SHAKE XOFs, and CAVP validation framing.
  - Quote: "SHAKE128 and SHAKE256 are approved XOFs"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source for verifying algorithm certificate evidence referenced by transition and procurement rows.
  - 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 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 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/transition-and-deprecation-tracker