FIPS crypto algorithm transition tracker

The cryptographic owner starts each entry by naming the exact claim under review. Engineering identifies affected implementations and releases; assurance identifies the controlling NIST or CMVP source and certificate effect; procurement identifies contract and supplier consequences; the accountable decision owner approves retention, restriction, replacement, or an exception. 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.

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.

Use these entries as starting points, then attach the affected implementation, module, product release, owner, and evidence. They summarize current NIST publication status; they do not decide whether a separate agency rule, contract, protocol profile, or risk decision imposes an earlier change.

Keep proposed transitions in a separate planning view. NIST SP 800-131A Rev. 3 and NIST IR 8547 are Initial Public Drafts. Their proposed retirement and post-quantum dates can guide sequencing, but the final publications or another controlling source must establish the operative requirement.

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.

Status words are incomplete without the operation and source. FIPS 186-5 no longer approves DSA for signature generation, but permits DSA to verify signatures generated before the standard's implementation date. The cited CMVP implementation guidance then gives program-specific treatment for new module submissions, including legacy signature verification. These are narrower statements than saying that every use of DSA is simply approved or banned.

Current SP 800-140C supplemental information treats three-key Triple-DES as approved only for legacy decryption, unwrapping, or CMAC verification as of January 1, 2024; it separately treats SKIPJACK as approved for decryption only. These are CMVP approved-function treatments, not a universal legal mandate for every system.

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.

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, source publication status, proposed guidance becomes final, or module certificate status changes. The tracker should say whether the change requires only a non-public evidence update, a vendor clarification, new CAVP evidence, CMVP revalidation analysis, restriction to legacy verification or decryption, an owned exception, or replacement of the algorithm.

Review this checklist before publishing a customer statement, procurement answer, or internal exception. The row should identify the source, certificate, and module boundary without forcing a later reviewer to infer them.