NIST IR 8547 Is Final: RSA and ECC Now Have an Expiry Date 

For two years, a lot of quantum-readiness plans leaned on one comfortable assumption: move to RSA-3072 or P-256, and you have until 2035. As of October 27, 2026, that assumption is gone. 

That is the day NIST published the final NIST IR 8547, Transition to Post-Quantum Cryptography Standards. It is the document that turns the 2024 post-quantum standards into a schedule. It names every quantum-vulnerable algorithm NIST approves today, points to its replacement, and puts a date on its retirement. Most of those dates land in 2030. 

Key takeaways 

• NIST IR 8547 deprecates every quantum-vulnerable signature and key-establishment algorithm after 2030 and disallows them after 2035. That now includes RSA-3072, P-256 and Ed25519, which the 2024 draft had left alone until 2035. 

• ML-KEM (FIPS 203) replaces classical key establishment, with ML-KEM-768 as the recommended default. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) replace classical signatures. 

• Under Executive Order 14412, federal high-value assets and high-impact systems need post-quantum key establishment by December 31, 2030, and post-quantum signatures by December 31, 2031. 

• Key establishment goes first because of harvest-now, decrypt-later attacks. Hybrid classical plus post-quantum deployments are allowed along the way. 

• The deadlines are written for federal agencies, but procurement will carry them to every vendor, contractor and partner that sells to them. 

What NIST actually published 

NIST released the final NIST IR 8547, Transition to Post-Quantum Cryptography Standards on October 27, 2026, almost two years after the November 2024 draft. FIPS 203, 204 and 205 told you which algorithms to use. IR 8547 tells you when to stop using the old ones. 

The report covers the public-key algorithms a cryptographically relevant quantum computer (CRQC) could break, the post-quantum standards that replace them, and the dates on which each vulnerable algorithm moves from approved to deprecated, and then to disallowed. 

It is also tied directly to policy. The report supports Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, signed on June 22, 2026, and OMB Memorandum M-26-15, which tells federal agencies how to carry out the order. 

The line most teams will end up quoting is this one: NIST “will instead deprecate all quantum-vulnerable digital signature algorithms after 2030 and disallow their use under NIST standards and guidelines after 2035.” 

What’s being retired, and what replaces it 

The short version: every public-key algorithm NIST currently approves for digital signatures or key establishment is quantum-vulnerable, and every one of them now has an end date. 

Quantum-vulnerable algorithm	Current NIST standard	Used for	Post-quantum replacement
RSA (112-bit strength and above)	FIPS 186-5	Digital signatures	ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
ECDSA (112-bit and above)	FIPS 186-5	Digital signatures	ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
EdDSA (128-bit and above)	FIPS 186-5	Digital signatures	ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
Finite-field and elliptic-curve Diffie-Hellman and MQV	SP 800-56A	Key establishment	ML-KEM (FIPS 203)
RSA key establishment	SP 800-56B	Key establishment	ML-KEM (FIPS 203)

A few details in the report will change real migration plans. 

NIST has picked a default parameter set. The report says it plainly: “NIST recommends using ML-KEM-768 as the default parameter set.” If your architects have been going back and forth between parameter sets, that settles it for most systems. National Security Systems under CNSA 2.0 still need ML-KEM-1024. 

More algorithms are on the way. FN-DSA, based on FALCON, is being standardized as another signature option, and HQC has been chosen as a backup key encapsulation mechanism (KEM), with its own standard in development. 

Code and firmware signing already has an answer. The stateful hash-based schemes LMS and XMSS (SP 800-208) are approved today for exactly that job. 

Your symmetric cryptography is mostly fine. NIST says it “does not expect to need to transition away from” AES, SHA-2 or SHA-3, and AES-128, AES-192 and AES-256 all stay approved. The exceptions are a handful of 112-bit symmetric standards, which are disallowed in 2030, and SHA-1, which is disallowed in FIPS-validated modules after 2030. 

The biggest surprise is in the 128-bit and higher tiers. The 2024 draft let RSA-3072, P-256, P-384 and Ed25519 skip the deprecation step and run until 2035. The final report doesn’t. They are deprecated after 2030, the same as RSA-2048. If your roadmap treated RSA-3072 as a bridge to 2035, that bridge is gone. 

The dates to put in your plan 

2035 is still the finish line, the goal set by National Security Memorandum 10 (NSM-10) in 2022. What changed this year is how early the most sensitive federal systems have to get there, and how quickly the requirements start moving into contracts. 

Date	What happens	Source
December 19, 2026	FAR Council due to propose a rule requiring covered federal contractors to comply with PQC-incorporating FIPS by December 31, 2030	EO 14412
March 19, 2027	CISA, with NIST, due to publish minimum elements for a Cryptographic Bill of Materials (CBOM)	EO 14412
January 2, 2030	Federal agencies must support TLS 1.3 or a successor version	OMB M-26-15
December 31, 2030	Federal high-value assets and high-impact systems must use post-quantum key establishment	EO 14412, OMB M-26-15
After 2030	All quantum-vulnerable signature and key-establishment algorithms become deprecated	NIST IR 8547
December 31, 2031	Federal high-value assets and high-impact systems must use post-quantum digital signatures	EO 14412, OMB M-26-15
After 2035	Quantum-vulnerable algorithms are disallowed under NIST standards and guidelines; remaining federal systems complete migration	NIST IR 8547, NSM-10

National Security Systems sit outside OMB M-26-15 and follow NSA’s CNSA 2.0 instead. For everyone else, treat 2030 as the real date. It is when classical public-key cryptography stops being the safe default, and it is the same year the proposed contractor requirement takes effect. 

Deprecated isn’t the same as disallowed 

The two words sound close, but they set very different limits on what you can keep running. NIST IR 8547 uses the definitions from NIST SP 800-131A: 

Status	NIST definition	What it means in practice
Deprecated	“The algorithm and key length may be used, but the user must accept some security risk.”	Still permitted after 2030, but the data owner has to assess and own the risk
Disallowed	“The algorithm or key length is no longer allowed for applying cryptographic protection.”	Cannot be used to encrypt, sign, or establish keys in systems that follow NIST standards after 2035
Legacy use	“The algorithm or key length may be used only to process already protected information.”	Decrypting old data or verifying old signatures, not protecting anything new

Deprecated doesn’t mean safe. It means the risk is now yours. Between 2030 and 2035, anyone still using RSA or ECC to protect new data is making a choice they will have to defend to auditors, customers and federal buyers. 

Start with the data that has to stay secret the longest 

NIST IR 8547 wants key establishment migrated first, and the reason is harvest now, decrypt later (HNDL). Someone can record your encrypted traffic today, park it in storage, and wait for a quantum computer that can break the key exchange. If that data still matters on that day, it is already exposed. 

Signatures work differently. A signature can only be forged once a CRQC exists, so a signature system you migrate before then is fine. With key establishment, the clock started the moment the traffic was captured. 

That is why NIST says it “expects to prioritize the migration to quantum-resistant key-establishment schemes,” and why the federal key-establishment deadline (2030) comes a year before the signature deadline (2031). In practice, put these at the front of the queue: 

• Data that has to stay confidential for a decade or more, such as health and financial records, intellectual property, government and defense information, and long-term contracts. 

• The channels that carry it, starting with TLS, VPNs, and any key exchange that crosses a network you don’t control. 

• Systems protecting data expected to remain sensitive in 2030. OMB M-26-15 tells agencies they should include these when they set migration priorities. 

For all of them, the target is ML-KEM (FIPS 203), using ML-KEM-768 unless you have a specific reason not to. 

Hybrid: a safety net with a price tag 

NIST says it “intends to accommodate the use of hybrid techniques in its cryptographic standards.” A hybrid pairs a classical algorithm with a post-quantum one, so you stay protected as long as either one holds. Think of it as insurance against a flaw nobody has found yet in the new algorithms. 

For key establishment, hybrids are allowed through the composite key-derivation technique in SP 800-56C, and they can be FIPS 140-validated as long as at least one input comes from an approved scheme such as ML-KEM. X25519MLKEM768, now widely deployed in TLS, is the obvious example. For signatures, NIST accepts dual signatures when at least one component is approved, but cautions that their security properties need careful analysis. Either way, NIST describes hybrids as typically temporary, and IR 8547 doesn’t yet say when you would move to post-quantum only. 

The price is size and complexity. An X25519 public key is 32 bytes. An ML-KEM-768 encapsulation key is 1,184 bytes and its ciphertext is 1,088 bytes, and a hybrid handshake carries both. An ML-DSA-65 signature is 3,309 bytes, against about 64 bytes for ECDSA P-256. In NIST’s own words, hybrids “add complexity to implementations and architectures.” Expect bigger handshakes and certificate chains, more processing, and surprises in older middleboxes, HSMs and constrained devices that were built around classical key sizes. 

Most of your cryptography belongs to someone else 

Look at where your keys actually live: HSMs, certificate authorities, VPN gateways, identity providers, cloud key management, and the firmware inside network and IoT devices. Most of it came from a vendor. NIST is blunt about what that means: “it is a high priority for vendors to initiate the integration of PQC support immediately,” because hardware takes years to design and ship. 

The report and the executive order push the transition beyond your own systems in three ways. 

1. Hardware and firmware: Hardware modules need upgrades or redesigns to support PQC. Devices that will still be in service after a CRQC appears, and cannot update their own verification code, should require quantum-resistant signatures on software and firmware updates now. 

2. Federal contracts: EO 14412 directs the FAR Council to propose a rule requiring covered contractors to comply with PQC-incorporating FIPS by December 31, 2030. Who counts as a “covered contractor” will be settled in that rulemaking. 

3. Visibility: CISA and NIST are due to publish minimum elements for a Cryptographic Bill of Materials (CBOM) by March 19, 2027, and M-26-15 asks agencies for automated cryptographic inventories that feed a central CBOM. Expect federal buyers to ask their suppliers for the same thing. 

If you sell to the U.S. government, or to companies that do, these dates are your dates. Very few vendors will keep one cryptographic baseline for federal customers and a different one for everyone else. 

Our take: how we’d spend the next 12 months 

The final IR 8547 takes away the last good excuse to wait. The algorithms are standardized, the deprecation date is fixed, and the federal buyers who set the pace for this market have hard deadlines. If we were running your program, the next year would look like this. 

1. Build an inventory you would trust in an audit: You can’t migrate what you can’t find. Cover keys, certificates, protocols, libraries and the code that calls them, and keep it as a CBOM so it matches what CISA and federal buyers will ask for. 

2. Rank systems by how long their data stays sensitive, not by how big they are: A small system guarding 20-year secrets outranks a large one handling data that goes stale in two years. 

3. Drop the “RSA-3072 as a bridge” plan: Under the final report, RSA-3072 and P-256 are deprecated after 2030 like everything else. Bigger classical keys don’t buy time anymore. 

4. Turn on hybrid key establishment where it is ready: Hybrid TLS with ML-KEM already ships in major browsers, libraries and CDNs. Start with external-facing services and watch what breaks. 

5. Ask vendors for dates, not intentions: Get written PQC roadmaps from your HSM, PKI, VPN, identity and cloud KMS providers, and put PQC readiness and crypto-agility requirements into new contracts. 

6. Build for the next change, too: NIST says it will keep monitoring the schedule and adjust it, and FN-DSA and HQC are still on the way. Anything that hard-codes algorithms or key sizes will hurt twice. 

How Encryption Consulting can help 

The hard parts of this transition are usually the first two: finding all of your cryptography, and turning that list into a migration plan that actually gets funded. That is where Encryption Consulting comes in. 

CBOM Secure finds the cryptography for you. Its 20+ production sensors cover cloud platforms, HSMs, KMIP servers, TLS endpoints, directory services, databases, file systems, source code and binaries. It flags quantum-vulnerable keys, certificates and cipher suites, generates audit artifacts in CycloneDX 1.6 and 1.7, and aligns natively with NIST IR 8547, CNSA 2.0 and CMMC 2.0. 

PQC Advisory Services turns that inventory into a program. The work runs from discovery and risk assessment through strategy, roadmap design, proof-of-concept testing, implementation planning and crypto-agility enablement, and you come out with a documented inventory, a prioritized roadmap and a governance framework. 

PKI-as-a-Service lets you start issuing post-quantum certificates without rebuilding your own CA. It can issue hybrid and composite certificates that pair ML-DSA with RSA or ECDSA, backed by FIPS 140-3 Level 3 HSMs. 

For more background, read our Education Center guide to NIST IR 8547 and SP 800-131A algorithm transitions, our guide to the new federal quantum action plan, the PQC 12-month playbook, and CISO’s Guide to PQC Migration Governance. For the standards themselves, see our Education Center article on PQC’s standardization. 

Not sure where you stand? Take our Quantum Readiness Assessment, or talk to our PQC experts about a migration plan built around the 2030 and 2035 dates. 

Conclusion 

NIST IR 8547 turns post-quantum migration from a standards question into a scheduling question. Every quantum-vulnerable signature and key-establishment algorithm is deprecated after 2030 and disallowed after 2035. The most sensitive federal systems have to move by 2030 and 2031. Procurement will carry those requirements to vendors and contractors, and from them to the companies they sell to. 

The teams that get through this smoothly will be the ones that already know where their cryptography lives. So start there. Build the inventory, move long-lived data to ML-KEM first, and hold your suppliers to the same dates you are being held to. 

Frequently asked questions 

What is NIST IR 8547? 

NIST IR 8547, Transition to Post-Quantum Cryptography Standards, is NIST’s roadmap for moving from quantum-vulnerable public-key algorithms to post-quantum standards. The final version was published on October 27, 2026. It lists which algorithms are quantum-vulnerable, names their replacements, and sets dates for deprecating them after 2030 and disallowing them after 2035. 

Is RSA deprecated by NIST? 

Yes, on a schedule. Under the final NIST IR 8547, RSA, ECDSA, and EdDSA signatures and RSA, Diffie-Hellman, and MQV key establishment are deprecated after 2030 at every approved security strength, including RSA-3072 and P-256. They are disallowed after 2035. Deprecated algorithms may still be used, but the user must accept some security risk. 

What replaces RSA and ECC? 

For key establishment, the replacement is ML-KEM (FIPS 203), with ML-KEM-768 recommended as the default parameter set. For digital signatures, the replacements are ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), with FN-DSA and the backup KEM HQC still being standardized. AES and SHA-2 and SHA-3 remain approved. 

What are the Executive Order 14412 deadlines? 

Executive Order 14412, signed on June 22, 2026, requires federal high-value assets and high-impact systems to use post-quantum key establishment by December 31, 2030, and post-quantum digital signatures by December 31, 2031. The broader federal target remains 2035. National Security Systems follow NSA’s CNSA 2.0 requirements instead. 

Do these deadlines apply to private companies? 

Not directly. NIST IR 8547 and EO 14412 govern federal systems. However, EO 14412 directs a FAR rule requiring covered federal contractors to comply with PQC-incorporating FIPS by December 31, 2030, and vendors are unlikely to keep separate cryptographic baselines for federal and commercial customers. Most organizations should plan as if the dates apply to them.