Hadamard Get the app

Is RSA Deprecated in 2030? NIST IR 8547’s Deadlines Explained

Is RSA Deprecated in 2030? NIST IR 8547's Deadlines Explained — Hadamard

No, RSA does not stop working in 2030. NIST IR 8547, still a draft, proposes that RSA at 112-bit security, such as RSA-2048, be deprecated after 2030. It also proposes that every quantum-vulnerable public-key algorithm, including RSA, ECDSA and ECDH at any key size, be disallowed after 2035.

So the honest answer to “is RSA deprecated in 2030” is: partly, and only on paper so far. This article covers what the NIST IR 8547 RSA deprecation in 2030 actually proposes and which algorithms are affected. It also covers the earlier deadlines that may reach you first and what to do now.

What NIST IR 8547 is, and why it’s still a draft

NIST IR 8547, titled “Transition to Post-Quantum Cryptography Standards,” was released as an initial public draft on NIST’s CSRC site on November 12, 2024. It sets out how US federal systems should move from today’s public-key cryptography to the post-quantum algorithms NIST has standardized.

The concern is that a large, fault-tolerant quantum computer running Shor’s algorithm could break RSA and elliptic-curve cryptography. Nobody can say when such a machine will exist. Recent hardware results, such as those discussed in our piece on magic state cultivation and Google’s Willow chip, show steady engineering progress, though not a working code-breaker.

As of mid-October 2026, trackers such as Quantum Sentinel’s IR 8547 explainer still describe the document as a draft. That means the dates are proposals that could change in a final version. Check the CSRC page directly before treating any date as settled.

Deprecated vs. disallowed: the 2030 and 2035 dates explained

The two key words come from NIST’s transition vocabulary, the same terms used in SP 800-131A. Encryption Consulting’s overview of IR 8547 and SP 800-131A explains how they connect.

  • Deprecated: the algorithm may still be used, but the user accepts some security risk. It is a formal warning to plan your exit.
  • Disallowed: the algorithm is no longer approved for that purpose in systems that follow NIST guidance.

The draft does not treat all key sizes the same way. Only algorithms at 112-bit security get the 2030 deprecation step. Algorithms at 128 bits or more skip it and go straight to disallowed after 2035, according to Quantum Sentinel’s summary and PQ Audit’s IR 8547 timeline.

Example algorithm and parameter Security strength After 2030 After 2035
RSA-2048, 2048-bit finite-field DH 112 bits Deprecated Disallowed
RSA-3072, ECDSA/ECDH P-256, Ed25519 128 bits No change Disallowed
ECDSA/ECDH P-384 192 bits No change Disallowed

A larger key buys you time until 2035, not beyond it. Increasing RSA from 2048 to 3072 bits avoids the 2030 deprecation step but does nothing about the 2035 cutoff.

Which quantum-vulnerable algorithms are affected?

The scope is every public-key algorithm whose security relies on factoring or discrete logarithms. That means PostQuantum.com’s analysis of the draft and PQ Audit both list the same five families:

  • RSA (signatures and key transport)
  • ECDSA
  • EdDSA, including Ed25519 and Ed448
  • ECDH
  • Finite-field Diffie-Hellman

Symmetric algorithms and hash functions are a different case. Grover’s algorithm weakens them much less than Shor’s algorithm weakens public-key schemes. We cover that in detail in Can Quantum Computers Break SHA-256?

The replacements: ML-KEM, ML-DSA, SLH-DSA, and what’s still coming

On August 13, 2024, NIST published three final post-quantum standards, as recorded by PQ Audit’s standards tracker:

  • ML-KEM (FIPS 203): a lattice-based key-encapsulation mechanism that replaces RSA key transport, ECDH and DH for establishing shared keys.
  • ML-DSA (FIPS 204): a lattice-based digital signature scheme and the general-purpose replacement for RSA, ECDSA and EdDSA signatures.
  • SLH-DSA (FIPS 205): a stateless hash-based signature scheme. It is slower and produces larger signatures, but its security rests only on hash functions.

FN-DSA (FIPS 206)

FN-DSA, based on FALCON, is not final yet. According to Encryption Consulting, NIST submitted the draft for approval on August 28, 2025, and a final version is expected in late 2026 or early 2027. Its main appeal is size. The same source puts its signatures at roughly 4–6 times smaller than ML-DSA’s, which are about 3.3 KB. That matters for certificates and other bandwidth-constrained protocols.

HQC (FIPS 207)

In March 2025, NIST selected HQC as its fifth post-quantum algorithm. HQC is a code-based backup to ML-KEM, so a future weakness in lattices would not leave federal systems without a standardized KEM. NIST presented the FIPS 207 HQC-KEM draft at its 6th PQC Standardization Conference in September 2025. A secondary report from around August 2026 says NIST is leaning toward seed-only private keys. As of September 2026, the draft standard was still pending.

Hash-based designs are also being used outside federal IT. Hadamard, which publishes this blog, builds BB84, an Ethereum Layer 2 rollup without ECDSA. Its accounts are one-time addresses based on hash commitments rather than elliptic-curve keys, so they rely on hash-function security rather than the discrete-log problem IR 8547 targets. The BB84 developer docs describe the design.

Earlier deadlines that may hit you first

For many vendors, 2035 is not the first date that matters. Several procurement and validation deadlines arrive sooner.

CNSA 2.0: January 1, 2027

For National Security Systems, the NSA’s Commercial National Security Algorithm Suite 2.0 sets a nearer deadline. Under CNSSP 15, new NSS acquisitions must support CNSA 2.0 from January 1, 2027, according to PQScore and AKM Secure. The suite does the following:

  • replaces RSA, DH and ECC with ML-KEM-1024 and ML-DSA-87
  • keeps AES-256 and SHA-384
  • adds SHA-512

Note that CNSA 2.0 requires the highest parameter sets. Products built only around ML-KEM-768 or ML-DSA-65 may not qualify for NSS contracts. Confirm the exact requirements against the NSA’s own CNSA 2.0 advisory and FAQ.

The FIPS 140-2 sunset

According to PostQuantum.com, all remaining FIPS 140-2 certificates were moved to “Historical” status on September 21, 2026. Modules with only a 140-2 certificate can therefore no longer be procured for new federal systems. If your product depends on a cryptographic module, check its status in NIST’s Cryptographic Module Validation Program listings.

Federal executive policy

A law-firm overview from Buchanan Ingersoll & Rooney and PostQuantum.com report that a June 2026 executive order and an accompanying OMB memorandum affect how agencies should read the IR 8547 timeline. We have not been able to confirm the order’s text, number or requirements against the Federal Register or OMB, so we don’t summarize them here. If you sell to federal agencies, read the primary documents rather than secondary summaries.

Harvest now, decrypt later: why 2035 is closer than it looks

The deadlines describe when algorithms become non-compliant, not when data becomes unsafe. An attacker who records encrypted traffic today can store it and decrypt it once a capable quantum computer exists. This is the “harvest now, decrypt later” threat.

It mostly affects key exchange and encryption, not signatures. A forged signature only matters while the system still trusts the old key. Decrypted data, by contrast, stays exposed for as long as it remains sensitive. If your data must stay confidential for ten years or more, it is already past the point where RSA or ECDH key exchange is a comfortable choice. That is why most migration guidance puts ML-KEM ahead of ML-DSA.

Physics-based alternatives such as quantum key distribution come up in this debate as well. Our article on QKD via Starlink satellites covers that approach. For most software systems, though, the realistic path is the NIST algorithms above.

A practical post-quantum migration checklist

  1. Inventory your cryptography. List every place you use RSA, ECDSA, EdDSA, ECDH or DH. Include TLS, SSH, code signing, JWTs, VPNs, HSMs, firmware updates and third-party SDKs.
  2. Rank by data lifetime. Migrate key exchange first wherever data must stay confidential beyond the early 2030s.
  3. Retire 112-bit parameters. Plan to replace RSA-2048 and 2048-bit DH before 2030, but don’t treat RSA-3072 as a long-term fix.
  4. Adopt ML-KEM for key establishment. Use hybrid modes during the transition if your protocols support them.
  5. Plan signature migration. Choose ML-DSA by default, SLH-DSA where conservative hash-based assumptions matter, and keep watching FN-DSA if signature size is a constraint.
  6. Check your federal exposure. If you sell to NSS customers, map products to CNSA 2.0’s January 2027 requirement and its parameter sets. Confirm that your crypto modules have FIPS 140-3 validation.
  7. Build crypto agility. Keep algorithm choices configurable so that changes in the final IR 8547, FIPS 206 or FIPS 207 don’t force a rewrite.

FAQ

Will RSA-2048 stop working in 2030, or is it just no longer recommended?

It will keep working technically. Under the IR 8547 draft, RSA-2048 becomes deprecated after 2030, meaning its use carries accepted risk. It becomes disallowed for systems following NIST guidance after 2035.

Is NIST IR 8547 final, and is it legally binding for private companies?

As of mid-October 2026, it is still described as a draft. NIST guidance mainly governs US federal systems. Private companies are affected indirectly, through federal contracts, FIPS validation requirements and industry rules that reference NIST.

Does the 2030 deadline apply to ECDSA and Ed25519, or only to RSA?

The 2030 step applies only to 112-bit-strength algorithms. ECDSA P-256 and Ed25519 provide about 128 bits of security, so they have no 2030 step but are disallowed after 2035 along with all other quantum-vulnerable algorithms.

What should I switch to: ML-KEM, ML-DSA, SLH-DSA, or a hybrid like X25519+ML-KEM?

Use ML-KEM for key exchange, often combined with X25519 as a hybrid so security holds if either component does. Use ML-DSA as the general signature replacement and SLH-DSA where you want hash-only assumptions. NSS vendors should use the CNSA 2.0 parameter sets, ML-KEM-1024 and ML-DSA-87.

Sources