NIST IR 8547: A Roadmap for Transitioning to Post‑Quantum Cryptography

14 Nov 2024 – In November 2024, the U.S. National Institute of Standards and Technology (NIST) released NIST Internal Report 8547 (Initial Public Draft), titled “Transition to Post-Quantum Cryptography Standards.” This document serves as a strategic roadmap for phasing out today’s quantum-vulnerable cryptography (like RSA and ECC) and migrating to post-quantum cryptographic (PQC) standards.

The draft lays out timelines, new standards, and guidance to ensure that organizations – from government agencies to industry – can securely transition before large quantum computers arrive. It aligns with federal directives such as National Security Memorandum 10, which targets 2035 as the deadline for mitigating quantum risks across Federal systems. In practical terms, NIST IR 8547 proposes that by 2035 all standard-approved uses of legacy public-key algorithms (RSA/ECC) should be retired or replaced with quantum-resistant solutions.

Deprecating RSA and ECC – Timeline to 2035

A centerpiece of IR 8547 is its transition timeline for classical algorithms. NIST makes it clear that widely used public-key schemes like RSA (finite-field cryptography) and ECC (elliptic-curve cryptography) have a ticking clock due to quantum threats. Following U.S. government policy, the year 2035 is set as a firm deadline to “remove quantum-vulnerable algorithms” from cryptographic standards. In fact, NIST plans to start phasing them out even sooner: common algorithms that provide ~112 bits of security (for example, RSA-2048 or ECC P-256) are slated to be “deprecated” by 2030, meaning they should no longer be used for new systems after that point. By 2035, any remaining use of RSA/ECC (even at higher strengths like 3072-bit RSA or P-384) will be disallowed in NIST standards. This accelerated schedule updates earlier NIST plans that had 2031 as a phase-out for weaker keys – reflecting the newfound urgency of the quantum threat.

Notably, IR 8547 emphasizes that high-risk systems should transition even earlier than 2035. For example, systems protecting sensitive or long-lived data are expected to adopt post-quantum solutions as soon as practical (potentially well before the cutoff) to minimize exposure. The overall goal is “widespread PQC adoption by 2035” across both federal and industry cryptography. After that point, today’s public-key algorithms would no longer be approved for use in FIPS and NIST guidelines. In short, the clock is now running for CISOs to inventory where they rely on RSA/ECC and budget the migration to quantum-safe alternatives in the next decade.

New Post-Quantum Standards (ML-KEM, ML-DSA, SLH-DSA)

Fortunately, NIST isn’t just sounding an alarm – it is also providing the replacement tools. In August 2024, NIST published the first three post-quantum cryptography standards as FIPS (Federal Information Processing Standards), which IR 8547 references as the foundation of the transition. These include:

• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) – a lattice-based key establishment method derived from the CRYSTALS-Kyber algorithm. This is the post-quantum analogue of Diffie-Hellman/RSA key exchange, used to establish shared secret keys securely. At present, ML-KEM (Kyber) is the only NIST-approved public-key scheme for key establishment that is quantum-resistant, though NIST plans to add one or more alternatives from ongoing PQC standardization rounds.
• FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA) – a lattice-based digital signature standard based on the CRYSTALS-Dilithium scheme. This is a primary post-quantum signature for authenticating identities, code, and digital documents. (NIST uses “module-lattice” as a term reflecting the mathematical structure of these lattice schemes.)
• FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) – a stateless hash-based signature standard (e.g. derived from SPHINCS+) also published in 2024. Hash-based signatures are larger and slower, but offer security based on hash functions alone, making them a robust alternative for certain niche or backup use cases.

NIST expects that ML-KEM, ML-DSA, and SLH-DSA will form the core for most post-quantum deployments, and “they can and should be put into use now.” In other words, the standards are ready – organizations do not need to wait for 2030 or 2035 to begin adoption. By starting to implement these in products and infrastructure soon, enterprises can gain experience with PQC and avoid a last-minute scramble.

Hybrid Cryptography as a Bridge

One notable aspect of the transition outlined in IR 8547 is support for hybrid cryptographic solutions. A hybrid approach means using a combination of a classical algorithm and a post-quantum algorithm together, in such a way that the system remains secure unless both algorithms are broken. For example, a TLS handshake could transmit two key-establishment pieces – one via ECDH (classical) and one via Kyber (post-quantum) – and use the combination of both secrets as the session key. Likewise, a digital signature could be implemented as two parallel signatures (e.g. RSA + Dilithium) on the same message, requiring both to verify.

NIST acknowledges that hybrids may be an important interim strategy in the early phase of migration. They can provide defense-in-depth (“belt-and-suspenders” security) and help ease compatibility concerns. The draft notes that hybrid solutions are typically acceptable if at least one component algorithm is NIST-approved. In fact, NIST states it will accommodate hybrid modes in its validation programs (FIPS 140-3 cryptographic module validations) as long as the composite is put together properly with approved algorithms. This is a green light for vendors to implement PQC alongside existing algorithms without fear of falling out of compliance during the transition period.

That said, the report also cautions that hybrids add complexity, cost, and could only be temporary; the end goal remains to switch fully to PQC-only cryptography once confidence in those algorithms solidifies. An open question (raised by stakeholders) is how long hybrid schemes will remain acceptable – for example, if a classical algorithm is disallowed after 2035, does that also forbid using it as part of a hybrid? This is an area where NIST may clarify policy in the final version, ensuring that organizations know when they must remove the “training wheels” of legacy crypto entirely.

Why This Matters Now: The “Harvest Now, Decrypt Later” Threat

For many security leaders, 2035 might seem far off – but NIST IR 8547 drives home that action is needed now due to a threat known as “harvest now, decrypt later.” This refers to adversaries collecting encrypted data today (when it’s protected by RSA/ECC), with the intent to decrypt it in the future once a cryptographically relevant quantum computer exists. In other words, any sensitive information with a shelf life of more than a few years is at risk: an attacker can store your encrypted VPN traffic, confidential emails, or intellectual property now and break the encryption retroactively when quantum capabilities arrive.

Because of this, NIST urges organizations to start deploying PQC or hybrid solutions for confidentiality as soon as practical. The report explicitly notes that for encryption and key exchange, we must account for the harvest-now-decrypt-later scenario when setting migration timelines. Every year that passes using legacy algorithms for protecting long-term data is a year adversaries could be silently stockpiling your secrets. Implementing quantum-resistant key establishment (like ML-KEM) into protocols such as TLS, IPsec, and secure messaging can ensure that even if data is captured, it won’t be decryptable later.

Another reason to act now is the lead time required for a smooth migration. Rolling out new cryptography enterprise-wide can take many years – from upgrading libraries and hardware, to getting new certificates and keys issued, to testing compatibility. Certain environments (e.g. embedded systems or critical infrastructure) have long procurement and update cycles, so 2035 is not as distant as it appears. NIST’s timeline and the IR 8547 draft are essentially giving a long-range heads-up to avoid a panic closer to the deadline.

Finally, this matters for national and economic security. The 2035 deadline isn’t arbitrary; it reflects a policy judgment that by the mid-2030s, quantum attacks could realistically be a threat to even well-protected data. For organizations, moving to PQC proactively can also be a market differentiator, demonstrating future-proof security to clients and regulators. In summary, IR 8547 signals that the era of quantum-safe cryptography has begun, and forward-looking security teams should start aligning their roadmaps accordingly.

Key Use Cases: Code Signing, TLS, and Authentication

NIST IR 8547 discusses various use cases to help prioritize PQC migration efforts. Three notable ones for CISOs are code signing, secure communication (TLS/VPN), and authentication systems. Each faces different quantum risks and practical challenges:

• Code Signing & Firmware Updates: Code signing involves digitally signing software (executables, firmware, patches) so that devices can verify the code’s integrity and origin before running it. The report highlights that many devices – from IoT gadgets to industrial controllers – cannot have their verification software easily updated after deployment. If those devices are expected to be in use into the 2030s, they must be equipped up-front to accept post-quantum signatures on software updates. Otherwise, a malicious actor with a quantum computer in the future could forge a classical signature (like an ECDSA or RSA signature) and push rogue firmware that the device would mistakenly trust. To avoid “bricked” devices or insecure updates, NIST advises planning for quantum-resistant code signing formats (e.g. Dilithium or hash-based signatures) for longevity. Projects deploying new hardware today should strongly consider making them PQC-ready for software verification.
• TLS/VPN and Encrypted Communications: Network security protocols such as TLS (HTTPS), SSH, and VPNs rely on asymmetric cryptography for key exchange and sometimes for authentication. Modern protocols often use ephemeral Diffie-Hellman (ECC) for key establishment, providing forward secrecy – but quantum blows a hole in forward secrecy. If an eavesdropper records an encrypted session now, a future quantum computer could break the ECDH key exchange and decrypt the session retroactively. This is the quintessential harvest-now-decrypt-later scenario. Therefore, TLS handshakes and other encryption key exchanges are high-priority for PQC upgrade. Incorporating a post-quantum KEM (like ML-KEM/Kyber) into the handshake ensures that the negotiated session keys can’t be derived later by an adversary. In practice, hybrid handshakes (classical + PQC) are likely to be deployed in the next few years to protect confidentiality without sacrificing interoperability. (By contrast, the authentication portion of such protocols – e.g. the server’s certificate signature – uses long-term keys, but breaking those via quantum only matters once an attacker actually has a quantum computer in hand. Thus, NIST suggests that key establishment should be upgraded first, and signature-based authentication can follow a bit behind.)
• User and Machine Authentication: Authentication systems include things like passwordless logins, digital identity verification, and machine credentials, often implemented with public-key certificates or signature schemes (RSA, ECDSA, etc.) For these use cases, the good news is there’s no retrospective exposure – an authentication event that happened in 2025 can’t be “undone” later just because a quantum computer appears in 2035. If the system was secure at the moment of authentication, the access was properly controlled. This means the urgency to replace authentication algorithms is slightly less than for encryption. In fact, IR 8547 notes that systems can continue using classical authentication algorithms until a quantum computer is actually available that can break them, at which point they must be disabled. However, migrating authentication mechanisms (e.g. switching out an organization’s RSA-based PKI for Dilithium-based credentials) is still a massive effort. It may involve updating client devices, servers, and cryptographic hardware (smart cards, HSMs) to support the new signatures. Given the lead time, organizations are encouraged to start laying the groundwork – for example, ensuring vendor roadmaps for MFA tokens or VPN appliances include PQC support. By the time a viable quantum computer exists, you don’t want to be caught with an infrastructure that cannot authenticate users or devices because all the algorithms have been broken.

In all these scenarios, a common thread is “crypto agility.” NIST IR 8547 essentially advocates for building cryptographic agility so that new algorithms (like PQC) can be dropped in with minimal disruption. Whether it’s being able to handle larger signature sizes in code signing, or negotiating new cipher suites in TLS, preparation is key. Organizations should identify which applications deal with long-lived sensitive data or have long device lifespans and prioritize those for early PQC adoption, while also planning for eventual swap-out of authentication and PKI components. The document even references use cases like secure email (S/MIME) – where both encryption and digital signatures are used – as needing a two-pronged transition, with encryption algorithms upgraded on a faster timeline.

Initial Feedback

Being an initial public draft, my first thoughts that I plan to formalize in a formal feedback include a strong support for the roadmap, but also a few opportunities for improvement:

• Clarify the status of hybrid schemes after 2035: How long “hybrid” (classical+PQC) approaches will remain acceptable? Can hybrids be used beyond 2035 as an exception?
• Build flexibility into the timeline based on risk and use-case: A one-size-fits-all 2035 deadline might be too rigid. Different systems have different risk profiles and constraints.
• Provide more granular migration prioritization guidance: It would be useful to provide some practical guidance on prioritizing what to migrate first.