Reading NIST's crypto deprecation timeline
Three different bodies currently publish migration timelines for cryptography: NIST, NSA, and Germany's BSI. They do not agree on dates, scope, or even vocabulary, and mixing them up is how teams end up planning around guidance that does not apply to their system. This is a guide to what each document actually says, where people commonly misread it, and how to turn any of them into an actual migration plan.
Deprecated and disallowed are not the same word
NIST uses both terms in SP 800-131A, and they mean specific, different things:
- Deprecated means an algorithm or key length is still permitted, but its use is discouraged, and new systems should not be designed around it. You can keep running it while you plan a replacement.
- Disallowed means the algorithm may no longer be used to apply cryptographic protection, period, for new data or existing data. Continuing to use it is a compliance finding, not a risk to manage on your own timeline.
A document that says RSA-2048 is acceptable through 2030, then deprecated, is telling you to start planning now and finish before some later point. A document that says 3DES is disallowed is telling you it should already be gone. Reading past that distinction is the single most common misreading of these timelines.
What SP 800-131A Revision 3 actually changed
SP 800-131A Revision 3 is a draft published in October 2024, and it has not been finalized, so its dates should be read as proposed rather than locked. The changes worth tracking:
- 3DES is disallowed as of 2024. If anything in your estate still negotiates 3DES, that is not a future problem, it is a current one.
- SHA-1 is disallowed for signature generation. SHA-1 can still appear in some non-signature contexts, certain HMAC uses among them, but generating a new signature with it is out.
- RSA-2048, 112-bit security, is acceptable through 2030, then moves to deprecated. This is the detail that trips people up: Revision 3 does not assign RSA-2048 a fixed disallow year. The commonly cited claim that RSA-2048 is disallowed by 2035 is stale guidance carried over from Revision 2, and it does not appear in the current draft. If a slide deck or policy document still has that 2035 date in it, correct it: the draft sets a deprecation point in 2030 and stops there, without a hard disallow date after it.
Because Revision 3 is still a draft, do not treat any specific date in it as contractually final. Do treat the direction as settled: NIST is not walking back the RSA-2048 deprecation, it is simply declining to commit to a disallow year ahead of the broader PQC transition.
CNSA 2.0: a narrower, harder mandate
NSA's Commercial National Security Algorithm Suite 2.0 is a different document for a different audience, National Security Systems rather than the general federal enterprise, and it is also more specific than NIST's guidance in two important ways. First, it does not give you a choice of parameter set: CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87, the top security category of each, not the smaller ML-KEM-768 or ML-DSA-65 that most TLS deployments default to today. Second, for firmware and software signing it specifies LMS or XMSS, single-tree hash-based schemes, and it notably does not include SLH-DSA at all. SLH-DSA is a NIST standard, but it is not part of the CNSA 2.0 suite, per the December 2024 FAQ, version 2.1.
The milestones carry real dates:
| Date | Requirement |
|---|---|
| January 1, 2027 | New National Security Systems acquisitions must be CNSA 2.0 compliant. |
| December 31, 2030 | Equipment that cannot support CNSA 2.0 is phased out. |
| December 31, 2031 | CNSA 2.0 is mandated for use across National Security Systems. |
| 2035 | All National Security Systems are expected to be quantum-resistant. |
Older guidance cited a set of per-category 2033 deadlines for individual algorithm classes. Those have been superseded by the milestones above. If you are planning against a 2033 date for CNSA 2.0, check whether it is left over from an earlier version of the FAQ before you build a schedule around it.
BSI's numbers look different because the method is different
Germany's BSI expresses classical algorithm strength in TR-02102-1, version 2026-01, using minimum key and modulus sizes rather than NIST's security-category language: RSA and Diffie-Hellman keys of at least 3000 bits, elliptic curves of at least 250 bits, and a general target of at least 120-bit security. These are not directly comparable to "RSA-2048 is acceptable," because a 120-bit target paired with a 3000-bit minimum is a stricter bar than NIST's 112-bit treatment of RSA-2048. BSI also puts a specific expiration on classical key agreement: it is recommended only until the end of 2031, after which post-quantum key exchange is expected to have taken over, a nearer deadline than either the current NIST draft or the CNSA 2.0 schedule.
The point is not that one body is right and the others are wrong. They are answering different questions for different regulatory contexts: a US federal enterprise under NIST, a US national-security system under CNSA 2.0, and a German or EU-aligned system under BSI. Applying CNSA 2.0's ML-KEM-1024 requirement to a system that only has to satisfy NIST SP 800-131A is over-engineering. Applying NIST's more permissive RSA deprecation window to a system that BSI governs under its 2031 key-agreement cutoff is under-engineering.
Turning a timeline into a migration plan
Whichever document governs your system, the planning steps are the same:
- Inventory first. You cannot plan a cutover for an algorithm you do not know you are using. Crypto inventories consistently turn up 3DES, SHA-1, and RSA-1024 in places nobody remembers configuring.
- Separate "disallowed now" from "deprecated, plan ahead." 3DES and SHA-1 for signing go on an immediate remediation list. RSA-2048 goes on a planning list with a 2030 (NIST) or 2031 (BSI) horizon, not an emergency list.
- Match the algorithm to the deadline that actually governs it. A National Security System plans to CNSA 2.0's 2027, 2030, and 2031 milestones. A general enterprise system plans to whichever finalized version of SP 800-131A applies once Revision 3 stops being a draft.
- Budget for the size and performance delta before the deadline arrives, not during it. The algorithm comparison guide at
/deprecation.htmlon this site maps each deprecated or disallowed algorithm to its recommended replacement, and the step-by-step guide at/pqc-migration.htmlwalks through sequencing a migration, inventory, hybrid rollout, cutover, decommission, so the switch does not become a last-quarter scramble.
The common failure mode across all three frameworks is the same: teams wait for a document to be finalized before starting any inventory work, then discover the deprecation window and the implementation work land in the same quarter. Reading the distinction between deprecated and disallowed correctly, and matching the right timeline to the right system, is what turns a scramble into a schedule.