RSA-2048 after 2030: what the NIST IR 8547 draft proposes

NIST IR 8547 is an initial public draft, published on 2024-11-12 and still a draft as of 2026-09. It proposes deprecating quantum-vulnerable public-key algorithms at a 112-bit security strength, RSA-2048 being the standard example, after 2030, and disallowing all quantum-vulnerable public-key algorithms after 2035. Those two dates are proposals in a draft, not finalized NIST requirements, even though they are frequently quoted as if they were already in force.

What NIST IR 8547 is

NIST IR 8547 was issued as an initial public draft on 2024-11-12 (csrc.nist.gov/pubs/ir/8547/ipd). An initial public draft is the first version released for public comment. It can be revised, reorganised, or have its dates adjusted before any final version appears. As of 2026-09, no final version has been published.

It should be read together with NIST SP 800-131A Rev. 3, which is also an initial public draft (2024-10-21, csrc.nist.gov/pubs/sp/800/131/a/r3/ipd). SP 800-131A is the publication that carries algorithm transition rules for US federal use, and those rules propagate into what validated cryptographic modules are allowed to do, which is why vendors and auditors track both documents closely. Both are drafts. Neither is a law, and neither is binding on a private company by itself.

Deprecated and disallowed are terms of art

In the NIST transition vocabulary, the two words are not synonyms. Deprecated means an algorithm remains approved but its use is discouraged and carries acknowledged risk. Disallowed means it is no longer approved for the use described. The draft proposes the first state after 2030 and the second after 2035, and it defines the terms it uses: read the draft itself before quoting a definition in an internal policy.

Why the 112-bit line lands on RSA-2048

The draft reasons in security strengths rather than in key sizes, and RSA-2048 is the example it gives for the 112-bit level. The practical consequence is that a transition framed this way reaches well beyond RSA. ECDSA, EdDSA, ECDH, finite-field Diffie-Hellman and DSA are all broken by Shor's algorithm on a large enough quantum computer, whatever the key size. DSA is already no longer approved for signature generation under FIPS 186-5, which allows verification of legacy signatures only.

A larger RSA key is not a migration

Moving from RSA-2048 to a larger modulus raises the classical security strength, and that is the reason BSI TR-02102-1 asks for RSA of at least 3000 bits. It does nothing against Shor's algorithm. The quantum answer is a different family of algorithms: ML-KEM (key encapsulation mechanism, standardized in FIPS 203 on 2024-08-13) for key establishment, and ML-DSA or SLH-DSA for signatures. See the ML-KEM page for the standardized parameter sets and the TLS groups that carry them.

Order of work matters here. Harvest now, decrypt later (HNDL) means an adversary records encrypted traffic today and decrypts it later: recorded sessions are protected only by the key exchange. That is why hybrid key exchange comes first, and why certificates and signatures can migrate afterwards. A fleet still signing with RSA-2048 certificates but negotiating a hybrid ML-KEM group is in a better position than the reverse.

How the draft compares with BSI, the EU and others

The 2030 to 2035 window is not unique to NIST, but the legal weight of each document differs sharply. The table below keeps each source in its own category. The full dated list, with primary sources for every milestone, is in our reference article on post-quantum migration deadlines.

Two points are worth stating plainly. First, the only firmly dated obligations in that table apply to US federal agencies; BSI TR-02102-1 is a technical guideline (the document itself), and the EU roadmap is coordinated guidance addressed to Member States. ANSSI states that its PQC recommendations are not yet regulatory obligations outside its regulated scope (product qualification and certain regulated operators), where hybridation is mandatory; it aims to require PQC for products entering qualification from 2027 and considers that after 2030 buying products without PQC will not be reasonable, which is a recommendation. Second, every one of these texts converges on the same two first steps, inventory and hybrid key exchange, which is why the fate of the draft does not change what to do now.

What to do while the draft is still a draft

This article is information, not legal advice. The sequence below is ordinary engineering work, and it is the same whether the final version of NIST IR 8547 keeps, moves or softens its proposed dates.

1. Know where RSA-2048 is. Inventory keys, certificates and TLS configurations, with key size, signature algorithm, owner and expiry. PCI DSS v4.0.1 requirement 12.3.3 requires cipher suites and protocols in use to be documented and reviewed at least every 12 months, including a documented strategy for anticipated changes in cryptographic vulnerabilities; it has been mandatory since 2025-03-31.
2. Write the agility clause, not the algorithm. DORA RTS, Commission Delegated Regulation (EU) 2024/1774, Art. 6, literally requires an encryption and cryptographic controls policy including provisions for updating or changing cryptographic technology based on developments in cryptanalysis, and Art. 7 requires key management across the lifecycle plus a register of certificates for ICT assets supporting critical or important functions. See the DORA page for the exact scope. Our interpretation, not a literal requirement: a policy that names a review trigger (publication of a final NIST transition document, for example) is an easier way to satisfy Art. 6 than a policy that names RSA-2048 and a date.
3. Turn on hybrid key exchange where sessions are recorded. Public-facing TLS and VPN termination first, since that is what HNDL targets.
4. Cap certificate lifetimes consciously. An RSA-2048 certificate issued today should not be intended to remain valid beyond the window your sector cares about.

Read-only checks first. These commands report what is actually deployed rather than what the documentation claims:

openssl x509 -in server.crt -noout -subject -enddate
openssl x509 -in server.crt -noout -text | grep -E "Public-Key|Signature Algorithm"
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null

The ML-KEM TLS groups require OpenSSL 3.5 or later, so an older client will reject the group name rather than the server. When you move to configuration changes, keep a classical fallback (list X25519 after X25519MLKEM768) and test in staging before production.

Next step: measure, then plan

Before quoting a draft date in a board paper, check the facts on your own perimeter: whether your servers already negotiate a hybrid ML-KEM group, which TLS versions they accept, and what key sizes and signature algorithms sit in the certificate chain. You can scan your domain with PQC Status for free, then use the result as the first line of the inventory described above. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation.