NIST IR 8547 Explained: The PQC Migration Timeline

By Mina Yin, Marketing & PR Lead, CHELPIS

Key Takeaways

• NIST published NIST IR 8547 on October 27, 2026, setting the official timeline for moving from RSA and ECC to post-quantum cryptography (PQC).

• All quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed under NIST standards after 2035.

• U.S. federal high value assets and high impact systems must adopt PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031.

• These requirements reach companies worldwide that sell into the U.S. through procurement and supply chains, and the EU and UK have set similar 2030 to 2035 timelines.

• Replacement standards: ML-KEM (FIPS 203, with ML-KEM-768 as the recommended default) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures.

• Symmetric algorithms with 128 or more bits of security, such as AES, SHA-2 and SHA-3, largely do not need to migrate.
  

Post-Quantum Migration Is Now a Countdown

On October 27, 2026, the U.S. National Institute of Standards and Technology (NIST) published NIST IR 8547, Transition to Post-Quantum Cryptography Standards. The report is the official road map for moving from quantum-vulnerable algorithms such as RSA and ECC to post-quantum cryptography (PQC). It sets the retirement schedule and names the replacement standards.

The urgency comes from "harvest now, decrypt later" (HNDL): adversaries can capture encrypted data today and decrypt it once quantum computers mature. NIST notes that past cryptographic transitions have taken 10 to 20 years. For the most sensitive U.S. federal systems, the key-establishment deadline is the end of 2030, about four years away.

2030 Is the Real Deadline

National Security Memorandum 10 (NSM-10), issued in 2022, set the goal of mitigating as much quantum risk as feasible by 2035. In June 2026, Executive Order 14412 sharply accelerated that timeline. Federal high value assets and high impact systems must now adopt PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. OMB Memorandum M-26-15 turns these requirements into a phased plan, from inventory and pilots through full migration. The newly published NIST IR 8547 provides the technical framework behind these timelines.

The impact extends well beyond federal agencies. EO 14412 directs the FAR Council to propose rules requiring federal contractors to comply with NIST's FIPS standards, and OMB directs agencies to make PQC readiness and cryptographic agility part of their vendor requirements. For companies whose products or services are part of the U.S. government supply chain, PQC is no longer a long-term concern. It is becoming a near-term compliance requirement.

PQC migration timeline · 2026–2035

The dashed line marks December 31, 2030: the key-establishment deadline for high-sensitivity systems, and the point after which NIST deprecates classical public-key algorithms.

Date	Milestone	Applies to
By January 2, 2030	Support TLS 1.3	U.S. federal agencies
By December 31, 2030	Complete PQC key-establishment migration	Federal high value assets, high impact systems
After 2030	Classical public-key algorithms deprecated	NIST standards
By December 31, 2031	Complete PQC digital-signature migration	Federal high value assets, high impact systems
After 2035	Classical public-key algorithms disallowed	NIST standards

Why This Matters Beyond the United States

U.S. rules formally apply to federal agencies, but any company that sells into the U.S. market will feel them through the supply chain, whether it is based in Southeast Asia, Europe or elsewhere.

• Selling to the U.S. government or its contractors: EO 14412 requires federal contractors to follow NIST FIPS standards, and OMB requires agencies to write PQC readiness into procurement conditions. Upstream suppliers of servers, network equipment, chips and software can expect to be asked for a PQC support roadmap.
  

• Selling into U.S. defense and national security: Under the NSA's CNSA 2.0 FAQ, all new acquisitions for national security systems must be CNSA 2.0 compliant from January 1, 2027, and equipment and services that cannot support CNSA 2.0 must be phased out by December 31, 2030.
  

• Selling to large U.S. enterprises: U.S. technology and financial companies often use NIST standards as a procurement baseline, so the deprecation of RSA and ECC after 2030 and their disallowance after 2035 are likely to work their way into contract specifications.
  

• Hardware has less time than it seems: Chips and devices take years to go from design to shipment, and their service lives extend past 2030 and 2035, so products starting development today should build in PQC.

Regulators in other regions are moving on a similar timeline. The EU's Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, adopted in June 2025, asks Member States to start the transition by the end of 2026 and move high-risk use cases to PQC no later than the end of 2030. The UK's NCSC expects organizations to complete discovery by 2028, finish high-priority migration by 2031 and complete migration by 2035. Whether a company exports to the U.S. or serves customers at home, it faces the same clock.

Five Key Points in NIST IR 8547

1. Every quantum-vulnerable public-key algorithm is deprecated after 2030 and disallowed after 2035

Key size buys no extra time: RSA-3072 and P-384 follow the same schedule as smaller keys.

Use	Algorithms being retired	After 2030	After 2035	Replacement standards
Digital signatures	ECDSA, EdDSA, RSA (FIPS 186)	Deprecated	Disallowed	ML-DSA (FIPS 204), SLH-DSA (FIPS 205), LMS/XMSS (SP 800-208)
Key establishment	DH, ECDH, MQV (SP 800-56A), RSA (SP 800-56B)	Deprecated	Disallowed	ML-KEM (FIPS 203), with HQC to follow

"Deprecated" means the algorithm may still be used, but the data owner accepts the risk. "Disallowed" means it may no longer be used under NIST standards.

2. ML-KEM-768 is the recommended default

NIST recommends ML-KEM-768 as the default parameter set, balancing security margin and performance. HQC has been selected as a backup to ML-KEM and is being standardized, as is a signature algorithm derived from FALCON.

3. Key establishment first, but signatures cannot wait

"Harvest now, decrypt later" (HNDL) threatens confidentiality, so key establishment in TLS, VPNs and encrypted email is the most urgent. Signatures face a different threat: "trust now, forge later" (TNFL). Certificates, code signatures and long-term signed records trusted today could be forged once a quantum computer breaks their algorithms, letting attackers push malicious firmware or fake transactions. Signatures also depend on PKI, certificates and hardware, involve many parties and take longer to migrate, so they need an early start too. Devices whose signature-verification code cannot be updated after manufacture should require quantum-resistant code signing from the design stage. To that end, the CHELPIS CPQC library is designed for TLS, secure boot and secure OTA firmware updates, and PQ-IC brings PQC into IC firmware and general-purpose chips.

4. Hybrid schemes can be FIPS 140 validated

A hybrid key-establishment scheme that combines classical and PQC algorithms can be FIPS 140 validated as long as one input comes from an approved scheme. A dual signature needs only one component to be NIST-approved. NIST cautions that hybrids add complexity and cost, and are usually a step toward a later PQC-only transition. In practice, X25519MLKEM768 in TLS 1.3 is today's most common hybrid key exchange; the CHELPIS PQRP post-quantum reverse proxy uses it and stays backward compatible with clients that have not upgraded.

5. Symmetric cryptography largely stays

Symmetric algorithms with 128 or more bits of security, such as AES-128, SHA-256 and stronger, SHA-3 and Ascon, are believed to meet at least PQC security category 1. Symmetric algorithms at the 112-bit level are disallowed in 2030, and SHA-1 leaves FIPS-validated modules after 2030.

What Organizations Should Do Now

NIST and OMB point to the same starting point: know what cryptography you use, then prioritize by risk.

Five steps to PQC migration · from inventory to a continuous cycle

1. Inventory your cryptography. Find every use of RSA, ECC and DH across systems, products and suppliers, including libraries, HSMs, certificates and cloud services. EO 14412 also directs CISA and NIST to publish minimum elements for a cryptographic bill of materials (CBOM). Manual inventories often take months; automated tools such as CHELPIS PQScan scan TLS/SSH services on internal and external networks, domains, packet captures, source code and files in one pass and help produce the CBOM.
   

2. Prioritize by data lifetime. Handle data that must stay confidential for years first, and move its key establishment to ML-KEM. Rank findings by exposure, data sensitivity and retention period to set the order of work; data that must be kept for years can also go into fragmented, distributed encrypted storage such as PQStorage.
   

3. Start with TLS. Federal agencies must support TLS 1.3 by January 2, 2030, and TLS 1.3 with hybrid ML-KEM key exchange is the most practical near-term path. Legacy systems whose code cannot change can be protected from outside with a PQC channel: the PQRP reverse proxy for web and APIs, or PQTunnel, built on zero-trust architecture, for any TCP/IP traffic.
   

4. Plan hardware and PKI early. HSMs, TPMs, smart cards and certificate systems take years to develop and replace, and NIST urges vendors to begin PQC integration immediately. Key management has to move too, for example by using ProEKM to manage the key lifecycle across HSMs, including post-quantum HSMs that support ML-KEM and ML-DSA. For unmanned vehicles and chips, PQ-UxV and PQ-IC build PQC in from the design stage.
   

5. Build cryptographic agility. Design systems to swap algorithms quickly, to adopt follow-on standards such as HQC and FALCON, and to move from hybrid modes to PQC-only later. CPQC, for example, is packaged as an OpenSSL 3.x provider: applications keep their existing interfaces and switch between classical, hybrid and PQC-only modes through configuration. After migration, rescan with PQScan to confirm weak algorithms have been removed.

You do not have to work through these five steps alone. CHELPIS offers PQC migration advisory services: our consultants work alongside your team from inventory and risk ranking through migration and verification, helping you plan the route that fits your systems and regulatory requirements.

Post-quantum migration is not finished by buying one product: as long as any step in a process still uses RSA or ECC, the quantum weakness remains. CHELPIS was the first company in Taiwan to earn NIST CAVP validation for PQC, is among the first worldwide validated for all three of FIPS 203, 204 and 205 (certificates #A7024, #A8021 and #A8023), and is the only Asian member of MITRE's Post-Quantum Cryptography Coalition (PQCC). From inventory and planning to migration and verification, we bring a complete toolchain and expert advisors to the journey. To find out how close your systems are to PQC readiness, write to us at contact@chelpis.com.

---

FAQ

What is NIST IR 8547?

A report NIST published in October 2026 that lists quantum-vulnerable cryptographic standards, the post-quantum standards that replace them, and the retirement timeline.

When will RSA and ECC be retired?

Under NIST standards, RSA, ECC and other quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed after 2035, regardless of key size.

What is the difference between "deprecated" and "disallowed"?

Deprecated means the algorithm may still be used, but the data owner accepts the risk. Disallowed means it may no longer be used under NIST standards.

What are "harvest now, decrypt later" and "trust now, forge later"?

Harvest now, decrypt later (HNDL) means attackers capture encrypted data today and decrypt it once quantum computers mature. Trust now, forge later (TNFL) means signatures and certificates trusted today could be forged by quantum computers in the future.

Does this affect companies outside the United States?

Yes. NIST IR 8547 directly governs U.S. federal systems, but EO 14412 requires federal contractors to follow NIST FIPS standards and OMB makes PQC readiness a procurement condition, so suppliers in Southeast Asia, Europe and elsewhere that sell to the U.S. government, defense sector or large enterprises are affected indirectly. The EU and UK have also set their own PQC timelines running from 2026 to 2035.

Where should an organization start?

Start with a cryptographic inventory: find every use of RSA, ECC and DH, build a cryptographic bill of materials (CBOM), then set the migration order by data lifetime and risk.