NIST Algorithm Deprecation Timeline: When RSA, ECC, and SHA-1 Are Officially Retired

NIST IR 8547 is not a threat assessment document. It is a schedule. Published as an initial public draft in November 2024, with a public comment period that closed in February 2025, it specifies when specific cryptographic algorithms must stop being used in US federal systems and what replaces them. [ASSUMED, NIST IR 8547 remains at initial public draft stage as of article authoring; verify whether NIST has published a second draft or final version before the June 2026 publication date. If a revised version exists, update all timeline claims accordingly. The deprecation dates in this article reflect the November 2024 IPD; a revised draft may change specific dates.]

Practitioners planning compliance programmes, procurement specifications, or vendor questionnaires do not need more background on why RSA is quantum-vulnerable. They need the specific dates, the specific algorithm names, and the specific policy implications. That is what this article provides.

The Deprecation Calendar

NIST IR 8547 organises algorithm status into four categories: Acceptable (currently in use), Deprecated (acceptable for existing use until a specified date, no longer acceptable for new deployments), Disallowed (no longer acceptable for any use), and Legacy Use (no new applications; existing use under defined conditions). The distinction between deprecated and disallowed matters for compliance planning: a deprecated algorithm is still permitted in existing systems until the disallowance date, but cannot be specified for new deployments.

Table note: All dates from NIST IR 8547 November 2024 initial public draft. Update if a revised draft or final version is published before your use. These dates apply to US federal systems; other jurisdictions have separate guidance that may differ on specific dates.

SHA-1: Already Over

SHA-1 has been disallowed for digital signature generation in US federal systems since 2014 under NIST SP 800-131A. Major browser certificate stores removed SHA-1 trust from 2017 onwards. TLS 1.3 does not support SHA-1. NIST SP 800-131A Rev 3 (October 2024) supersedes Rev 2 and maintains SHA-1's deprecated-to-disallowed status.

The residual issue is legacy systems that still use SHA-1 for checksums, MACs, or non-signature HMAC constructions. For practitioners encountering SHA-1 in a 2026 security review, this is a legacy debt question with a clear remediation path, not a forward planning question. SHA-256 is the minimum replacement for all non-signature uses; SHA-384 or SHA-512 for highest-assurance contexts.

RSA and ECC: The 2030 and 2035 Horizon

The 2030 and 2035 dates are the operational planning horizon for most organisations. Understanding the difference matters: "deprecated after 2030" means RSA and ECDH are no longer acceptable for new deployments on US federal systems from 2030 onwards, but existing deployed systems have until 2035 to complete migration. A system using RSA-4096 for TLS key exchange in 2026 is using an algorithm that will be deprecated for new federal deployments in four years and disallowed entirely in nine.

RSA-4096 is not meaningfully safer than RSA-2048 against Shor's algorithm. The scaling is polynomial, not exponential: breaking RSA-4096 requires approximately eight times more quantum resources than breaking RSA-2048 under Gidney and Ekerå's (2021) analysis. That overhead is within the capacity of any fault-tolerant quantum computer capable of breaking RSA-2048. Both are on the same deprecation schedule because both are broken by the same algorithmic attack.

The RSA and ECC deprecation applies to key establishment (ECDH, DH, RSA key transport) and to digital signatures (ECDSA, RSA-PSS, RSA PKCS#1 v1.5). Finite-field Diffie-Hellman, used in older TLS 1.2 configurations and some SSH server setups, is also deprecated on the same schedule. Migrating from RSA to ECDH does not resolve the quantum vulnerability; both are broken by Shor's algorithm.

AES and SHA-2/SHA-3: Not in Scope

AES-256 and the SHA-2 and SHA-3 families are not on NIST IR 8547's deprecation schedule. Grover's algorithm provides a quadratic speedup for symmetric search problems but does not break them. AES-256 provides approximately 128 bits of effective quantum security, which is acceptable for the foreseeable future. AES-128 provides approximately 64 bits of effective quantum security, which remains above NIST's 80-bit security floor for most applications but is below the 112-bit minimum recommended for long-term high-value data.

The practical recommendation for new deployments: use AES-256 where the choice is yours. AES-128 is not deprecated and is not being retired; the guidance is simply that AES-256 is the more durable choice when there is no performance constraint requiring AES-128.

The quantum vulnerability in most enterprise systems sits entirely at the asymmetric layer. The TLS session encryption uses AES. The key exchange that delivers the AES session key uses RSA or ECDH. Shor's algorithm breaks the key exchange and recovers the AES session key; the AES encryption of the session content itself is not broken. Replacing RSA key exchange with ML-KEM closes the quantum attack path. Replacing AES with something else does not address any currently identified quantum threat.

The Four New Standards

NIST published four post-quantum cryptographic standards in August 2024, completing an eight-year evaluation process. The correct designations are the FIPS identifiers; procurement documents and compliance records should not use the submission algorithm names (CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+, FALCON) when referring to the published standards.

ML-KEM (FIPS 203) is the designated replacement for RSA and ECDH in key establishment contexts: TLS handshakes, IKEv2/IPsec key exchange, key transport, and key wrapping. Three parameter sets: ML-KEM-512 (128-bit classical security equivalent), ML-KEM-768 (192-bit, general recommendation), ML-KEM-1024 (256-bit, required for US National Security Systems under CNSA 2.0). General internet deployments use ML-KEM-768.

ML-DSA (FIPS 204) is the primary designated replacement for ECDSA and RSA signatures. ML-DSA-65 generates a signature of 3,309 bytes (public key 1,952 bytes, private key 4,032 bytes) at NIST security category 3. ML-DSA-87 generates a 4,627-byte signature at security category 5, required for US National Security Systems. For details on implementation decision-making across use cases, see the FIPS 203, 204, and 205 implementation decision map.

SLH-DSA (FIPS 205) is a stateless hash-based signature scheme. Its security rests entirely on the properties of the underlying hash function, providing cryptographic diversity from the lattice-based assumptions that underpin ML-KEM and ML-DSA. SLH-DSA signatures are larger (SLH-DSA-SHAKE-128s: 7,856 bytes; SLH-DSA-SHAKE-256f: 49,856 bytes) but their security assumptions are independent. Use SLH-DSA where algorithm diversity from ML-DSA is desirable: root CA trust anchors, long-lived audit records, firmware signing chains where re-signing is impractical.

FN-DSA (FIPS 206) addresses constrained environments requiring compact signatures. FN-DSA-512 generates a 666-byte signature (public key 897 bytes). FN-DSA's signing implementation requires discrete Gaussian sampling, which is more complex to implement securely than ML-DSA. NIST recommends ML-DSA as the primary signature standard for most applications; FN-DSA for cases where signature size is the primary operational constraint.

XMSS and LMS, standardised in NIST SP 800-208 (October 2020), remain appropriate for stateful signing contexts: firmware updates, software distribution systems where the signer can maintain state across signing operations. They predate the 2024 FIPS standards and are not being deprecated. SLH-DSA is the stateless post-quantum alternative; XMSS and LMS are retained for specific stateful use cases where their signing efficiency advantage is material.

The Mosca Calculation

The deprecation schedule is a US federal planning tool. The Mosca inequality is a practitioner tool for any organisation with data retention requirements.

The calculation is three numbers. First: the credible lower bound for Q-Day, based on the academic consensus at Webber et al. (AVS Quantum Science, 2022), placing approximately 2033 as the earliest plausible date for a CRQC capable of breaking RSA-2048. Second: the retention period for the organisation's most sensitive long-duration data. Third: the time needed to complete a full PQC migration, typically three to five years for a large enterprise.

If the sum of retention period and migration time exceeds the years until Q-Day, migration should already have begun. For a large financial institution holding ten-year actuarial records with a five-year migration timeline: 5 + 10 = 15 years needed, 7 years until the credible lower bound. The migration clock started in 2023 under that calculation. Organisations that have not started are not late by months. They are late by years on the data protection dimension.

The analysis of full transition timelines and their interaction with HNDL risk is covered in detail in the NIST IR 8547 transition timeline insight.

What the Deprecation Dates Mean for Compliance

NIST IR 8547 applies directly to US federal agencies and contractors working on federal systems. It is the primary instrument binding US government computing on the migration timeline. Non-US organisations, including EU entities under DORA and NIS2, UK entities under FCA, PRA, and NCSC guidance, Australian entities under the ASD's Strategies to Mitigate Cyber Security Incidents, are not directly subject to NIST IR 8547. But no comparable deprecation schedule with equivalent specificity and authority yet exists from EU or UK regulators. The NIST dates are the closest available global technical reference point.

BSI TR-02102-1 (Germany's cryptographic recommendations, 2024 edition) includes ML-KEM and ML-DSA as suitable algorithms, broadly aligned with the NIST timeline. [VERIFIED, BSI TR-02102-1 2024 edition; verify page numbers and specific algorithm references before relying on specific claims.] ANSSI (France) has published PQC transition guidance broadly aligned with the NIST/NSA framework. [INFERRED, ANSSI alignment with NIST/NSA PQC direction follows from published ANSSI migration guidance; verify specific ANSSI document title, publication date, and algorithm recommendations against current ssi.gouv.fr content before publication.] The NCSC's UK PQC guidance tracks the NIST and NSA position closely.

US National Security System contractors are on a more aggressive schedule than NIST IR 8547's civilian federal timeline. NSA's CNSA 2.0 advisory (September 2022) specifies preference dates of 2025-2026 for most NSS application categories, with required dates of 2030-2033. NSS contractors should plan against CNSA 2.0 timelines, not NIST IR 8547.

For FIPS 140-3 validated cryptographic modules: the CMVP approved algorithm list will update as NIST IR 8547 moves to final and RSA/ECC are formally deprecated. Organisations that require FIPS 140-3 validated modules should track the CMVP modules-in-process list for ML-KEM and ML-DSA validations. As of mid-2026, some initial implementations have entered the CMVP validation queue. [INFERRED, CMVP ML-KEM and ML-DSA validation queue status follows from the NIST CMVP modules-in-process list; verify current validation status at csrc.nist.gov/projects/cryptographic-module-validation-program before publication.]

The Hybrid Window

Between now and the 2030 deprecation date, the recommended approach for TLS and IKEv2 is hybrid key establishment: combining a classical algorithm with ML-KEM in a single handshake. The IETF standard for TLS is X25519+ML-KEM-768 (draft-ietf-tls-ecdhe-mlkem; verify current version and RFC publication status before publication — this draft may have been published as a final RFC by June 2026). [INFERRED, draft-ietf-tls-ecdhe-mlkem progression to RFC follows from IETF TLS working group timeline; verify at datatracker.ietf.org before publication.] Chrome 124+ and Firefox 132+ support this hybrid at the browser level; OpenSSL 3.3+ and BoringSSL support it at the library level. [INFERRED, browser version support figures follow from published browser release notes; verify current version numbers before publication as browser minor versions change frequently.]

Hybrid deployment protects new TLS sessions from HNDL from the point of deployment forward; captured traffic requires an attack on ML-KEM, not just on ECDHE. It does not retroactively protect already-captured traffic. It does not protect systems that do not use TLS. The hybrid strategy is the correct bridge for internet-facing communications; it is not a complete migration programme.

ETSI TS 103 744 (Quantum-Safe Hybrid Key Exchanges) provides the European technical standard for hybrid key exchange in non-TLS contexts, relevant for EU entities building DORA-compliant TLS infrastructure and for eIDAS trust infrastructure operators working under ETSI TS 119 312.