Regulation

NIST sets 2030 and 2035 dates to retire RSA and ECC

By Yaali. November 2, 2026, 7 min read, Regulation, Resilience, Identity.

NIST's final IR 8547 deprecates RSA, ECDSA and ECDH at every key size after 2030. What changed from the draft, the federal deadlines, and where to start.

On October 27, 2026, NIST published the final version of NIST IR 8547, Transition to Post-Quantum Cryptography Standards. It sets the schedule for retiring the public-key algorithms almost every system uses today: RSA, ECDSA, EdDSA and the Diffie-Hellman family. All of them become deprecated after 2030 and disallowed under NIST standards after 2035, whatever the key size. The report names the replacements, ML-KEM for key establishment and ML-DSA or SLH-DSA for signatures, and recommends ML-KEM-768 as the default.

The binding deadlines apply to US federal agencies, but they reach further. Anyone who sells software, hardware or cloud services to government will be asked for dates. Cryptographic modules validated under FIPS 140, the US standard many regulated firms also follow, are held to the same NIST algorithm rules. If you finished a quantum readiness plan against the 2024 draft, the main change below will probably move some of your dates forward.

What changed from the draft

The initial public draft, released on November 12, 2024, split the old algorithms by strength. Parameter sets with 112 bits of security, such as RSA-2048 and the P-224 curve, were deprecated after 2030. Anything at 128 bits or more, such as RSA-3072, P-256 and Ed25519, stayed acceptable until it was disallowed after 2035.

The final report removes the split. ECDSA and RSA signatures at 112 bits or more, EdDSA at 128 bits or more, and finite field DH, elliptic curve DH, MQV and RSA key establishment at 112 bits or more are all deprecated after 2030 and disallowed after 2035. Deprecated means the algorithm may still be used, but the data owner must examine the risk and decide whether to keep it. Disallowed means it is no longer allowed for the stated purpose. A third status, legacy use, lets you keep decrypting old data or verifying old signatures.

Several other items are new or firmer than in the draft:

• ML-KEM-768 is named as the default parameter set, "a large security margin at a reasonable performance cost".
• HQC is selected as an alternative to ML-KEM, with a standard still being written. NIST has no current plans to pick more KEMs (key encapsulation mechanisms, the public-key method that sets up a shared secret).
• A FIPS for a signature algorithm derived from FALCON is in development.
• TLS is named an early priority, and hybrid key exchange guidance for TLS will come in the next revision of SP 800-52.

How the federal deadlines stack

National Security Memorandum 10 set 2035 as the target for finishing the federal migration, and that target stays. Executive Order 14412, signed on June 22, 2026, and OMB Memorandum M-26-15, issued on June 24, pull the most sensitive systems forward.

Under M-26-15, high value assets and high impact systems (those with at least one FIPS 199 security objective rated "high") must use post-quantum key establishment by December 31, 2030 and post-quantum signatures by December 31, 2031. Systems holding data expected to remain mission-sensitive in 2030 get the same priority. Separately, agencies must support TLS 1.3 by January 2, 2030, under Executive Order 14306 and M-26-15. The report says the 2030 to 2035 window is for lower-risk and legacy systems and does not relax these dates.

Key establishment comes first because of "harvest now, decrypt later": an attacker records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. A session key agreed with ECDH cannot be protected after the fact. Signatures face no such retroactive risk, since a forged signature only matters once forging is possible, but NIST still calls them urgent because certificate authorities, smart cards and HSMs (hardware security modules) take years to replace.

NIST says it does not expect to move away from AES or SHA-2 and SHA-3 for this migration, because any approved symmetric primitive with at least 128 bits of classical security meets security category 1. The few 112-bit symmetric standards are disallowed in 2030, and SHA-1 is disallowed in FIPS-validated modules after 2030.

Hybrids are allowed, with conditions

Most early deployments combine a classical exchange with ML-KEM, so the session stays safe if either one holds. Under SP 800-56C, the classical shared secret Z and a second secret T are concatenated and fed to an approved key derivation function. NIST will update SP 800-56C so Z may come from FIPS 203 (ML-KEM) and the order may be reversed, and the result can pass FIPS 140 validation as long as one input comes from an approved scheme, even if the other is disallowed.

For signatures, dual signatures (two signatures on the same message, both of which must verify) are accepted if at least one component algorithm is NIST-approved. NIST expects hybrids to be temporary, followed by a second move to post-quantum only.

What to do

1. Rebuild your inventory around the new dates. If your plan assumed RSA-3072, P-256 or Ed25519 were fine until 2035, change it: they are deprecated after 2030 too. For each system, record the algorithm and key size in TLS certificates (openssl x509 -noout -text shows the "Public Key Algorithm" line), VPN and IKE (Internet Key Exchange) profiles, SSH host keys, code signing keys and HSM key stores.
2. Turn on hybrid key exchange where data must stay secret for years. OpenSSL 3.5, released in April 2025 as a long-term support version, already offers X25519MLKEM768 as a default TLS key share. With an OpenSSL 3.5 client, openssl s_client -connect host:443 -tls1_3 -groups X25519MLKEM768 shows whether a server will negotiate it.
3. Ask vendors for dates, in writing. For HSMs, VPN gateways, identity providers, PKI software and cloud key management, ask when ML-KEM or hybrid key exchange will be on by default and when ML-DSA or SLH-DSA signatures will be supported, and whether the module has a FIPS 140 validation that covers them.
4. Protect long-lived signing keys early. NIST singles out devices whose signature check cannot be updated after manufacture: if they will still run after a quantum computer arrives, they must require quantum-resistant signatures on their code from the start. SP 800-208 stateful hash-based schemes (LMS and XMSS) fit firmware and secure boot signing, provided you can track signature state strictly.
5. Plan certificates and identity last but start now. User and machine authentication can stay classical until a quantum computer exists, yet NIST notes that PIV smart cards, readers and PKI follow multi-year replacement cycles. Put the replacement dates on the hardware refresh plan.
6. List what cannot move. NIST and M-26-15 both say systems that cannot support post-quantum cryptography should be prioritised for replacement or decommissioning.

There is no log to search for harvested traffic, because passive capture leaves nothing on your side. What you can measure is exposure: which external services still agree keys with classical ECDH only, and how long the data on those links stays sensitive. Mosca's theorem, which the report cites, puts it as a sum: if the years the data must stay secret plus the years your migration takes exceed the time until a quantum computer exists, the migration should already be under way.

Make the algorithm a setting

NIST notes that past cryptographic transitions took 10 to 20 years; the federal deadlines leave about four for the most sensitive systems. The same work comes back when HQC or a FALCON-based standard arrives and when hybrids are retired, so each time you touch a system for this migration, check whether the algorithm choice lives in one setting or is hardcoded in many places.

Our compliance and audit readiness team can map your systems against the IR 8547 and M-26-15 dates, and our safeguarding and hardening work covers TLS, VPN and key management configuration. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: NIST IR 8547 (final, October 2026), NIST IR 8547 initial public draft (November 2024), NIST CSRC, IR 8547, Help Net Security, The Quantum Insider, Quantum Computing Report, PostQuantum.com, Cloud Security Alliance research note, Federal Register, Executive Order 14412, Phoronix, OpenSSL 3.5 release.