Lesson 1.6 — The Deprecation Clock

The standards are finalized. The replacements are named. Now the question is: when do the old algorithms stop being acceptable, and what does that timeline mean in practice for different sectors and organizations? This lesson covers the NIST deprecation schedule, sector-specific deadlines, and the concept of crypto-agility, the design principle that makes future migrations less painful.

Glossary term #18

Deprecation

The process of officially declaring a cryptographic algorithm no longer acceptable for new use, followed eventually by disallowing it entirely. NIST SP 800-131A Rev 3 defines the RSA and ECC deprecation timeline. Deprecated means: do not use for new systems, begin planning migration for existing systems. Disallowed means: must not be used in any new or existing system, compliance violations result.

The key practical implication: when NIST depreciates an algorithm, it does not immediately break existing systems. It means that systems using that algorithm are now operating on borrowed time, compliance violations become possible for regulated sectors, and new system procurement must use replacement algorithms. When an algorithm is disallowed, there is no grace period, existing use is non-compliant.

2024

Now

NIST finalizes FIPS 203, 204, 205, starting gun fires

August 13, 2024: ML-KEM, ML-DSA, SLH-DSA become final standards. Vendors can ship. Governments can mandate. Compliance frameworks can reference. Migration planning is no longer optional for regulated sectors.

FIPS 203FIPS 204FIPS 205Planning required

2026

~2 years

Early adoption deadline — US Federal agencies and NSS

NSA CNSA 2.0 mandates ML-KEM and ML-DSA for new National Security Systems by 2026. Federal civilian agencies under OMB/CISA guidance expected to have migration plans published and key exchange migration underway. First government procurement contracts requiring PQC compliance begin appearing.

NSA CNSA 2.0Federal civilianNew systems only

2030

~6 years

RSA and ECC formally deprecated: SP 800-131A Rev 3

NIST officially deprecates RSA-2048, RSA-3072, ECDH, and ECDSA for key establishment and signatures. From this date, new systems must not use these algorithms. Existing systems have a grace window but are on notice. For regulated sectors, compliance frameworks will begin requiring documented migration plans with completion dates.

RSA deprecatedECC deprecatedNew system compliance required

2035

~11 years

RSA and ECC disallowed — hard cutoff

All use of RSA and ECDSA for digital signatures and key exchange is disallowed under NIST guidelines. Organizations still using these algorithms in regulated environments face compliance violations. Legacy systems that cannot be migrated must be decommissioned or isolated. This is not a soft deadline, it is the end of the transition window.

RSA disallowedECC disallowedHard compliance cutoff

Eleven years from now sounds like a long time. It is not, not for large organizations with complex PKI infrastructure, thousands of certificates, hardware-bound keys in HSMs and IoT devices, and vendor dependencies. Enterprise PKI migrations historically take 3–7 years from planning to completion. For a migration that needs to be finished by 2035, planning that begins in 2026 or 2027 is already late.

Sector

Key deadline

Urgency

Governing requirement

US Federal / National Security Systems

2026 (new systems)

Critical

NSA CNSA 2.0, OMB M-23-02, CISA guidance

Financial services (US)

2028–2030

Critical

FFIEC guidance, OCC/Fed/FDIC crypto risk frameworks

Healthcare (US)

2030 + HIPAA update

High

HIPAA Security Rule update expected; HNDL risk to PHI is critical

EU regulated sectors

2027–2030

High

NIS2 Directive, ENISA PQC guidance, eIDAS 2.0

Defense contractors (US)

2025–2026

Critical

CMMC 2.0, DFARS cybersecurity requirements, NSA mandates

Public internet / CA/Browser Forum

TBD — active discussion

High

CA/B Forum ballot process — expected 2026–2028 requirements

SMBs (general)

Vendor-driven

Plan now

No direct mandate yet, but cloud provider, CA, and software vendor migrations will force the transition regardless

The SMB row deserves particular attention. Even without a direct regulatory mandate, SMBs will be migrated by their infrastructure, their cloud provider will update TLS, their CA will stop issuing RSA certificates, their operating system will deprecate RSA in its trust store. The difference between a managed migration and a forced one is whether you understood it was coming.

Every organization that is facing a difficult, expensive PQC migration today has something in common: their systems were built assuming that the cryptographic algorithms underneath them were permanent. Algorithms were hardcoded. Key types were fixed. Protocol versions were tied to specific cipher suites. When the algorithm needs to change, the system needs to be rebuilt rather than reconfigured.

Glossary term #7 (reinforced)

Crypto-agility

The ability of a system to easily swap cryptographic algorithms without requiring a full rebuild. A crypto-agile system supports multiple algorithm configurations, can be updated via configuration rather than code changes, and has abstracted its cryptographic operations from its business logic. Essential for sustainable PQC migration, and for every future algorithm transition that will follow it.

The deprecation clock gives you three actionable data points. First: which algorithms in your environment are on the deprecation list (RSA and ECC, all of them). Second: which deadline applies to your sector. Third: how long your migration will actually take given your inventory, vendor dependencies, and organizational constraints.

The Mosca inequality from Lesson 0.3 applies here directly. If your migration timeline (Y) plus your data's confidentiality requirement (X) exceeds the quantum arrival estimate (Z), you are already behind regardless of where the deprecation clock sits. The deprecation timeline is the regulatory floor. Your HNDL exposure may make the real deadline earlier.

The planning reality

Enterprise PKI migrations take 3–7 years from planning to completion. The 2035 hard cutoff is 11 years away. That leaves 4–8 years of margin, which sounds comfortable until you factor in: CBOM discovery (6–18 months), CA hierarchy migration (12–24 months), vendor dependency resolution (variable, often 12–36 months), hardware replacement cycles (HSMs, IoT devices), and the organizational change management required at each step. Organizations that begin planning in 2027 or 2028 will be cutting it close for the 2035 hard cutoff.

National roadmaps: the deprecation schedule in policy The NIST deprecation dates are the global technical baseline. Several national governments have now published their own implementation roadmaps with specific milestone dates. The Canadian Centre for Cyber Security published ITSM.40.001 in June 2025, requiring Government of Canada departments to submit PQC migration plans by April 2026 and complete high-priority system migration by end of 2031: four years ahead of the NIST 2035 hard cutoff. The EU's NIS2 directive and DORA regulation create parallel obligations for European regulated entities. These national roadmaps translate the NIST technical timeline into compliance obligations with specific deadlines, annual reporting requirements, and financial penalties. Lesson 2.6 covers the sector-specific implications in detail.