FIPS crypto algorithm transition tracker

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.

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.

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.

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, 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.

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.