The Two Dates in NIST IR 8547 That Govern Your Migration Plan

Two Dates, Not One

In November 2024, the U.S. National Institute of Standards and Technology (NIST) released the initial public draft of Internal Report 8547, Transition to Post-Quantum Cryptography Standards. Most coverage reduced it to a single number, 2035. The draft sets two, and the earlier one is already shaping decisions organizations are making this year. Public-key algorithms at roughly 112 bits of security strength, RSA-2048 and ECDSA over the P-256 curve among them, are deprecated after 2030. Every quantum-vulnerable public-key algorithm, at any key size, is disallowed after 2035.

Deprecated and disallowed are terms of art. NIST defines them in SP 800-131A, and they impose different obligations. Deprecated status means the algorithm is disallowed for applying cryptographic protection in new systems and allowed only for legacy use, such as verifying signatures made earlier or reading data already encrypted, and then only alongside a documented migration plan. A disallowed algorithm is no longer approved for applying cryptographic protection at all, though NIST sometimes permits continued use for processing data that was already protected. For a compliance team, that is the difference between a phase-out you can schedule and a control gap you can’t.

What IR 8547 Actually Binds

IR 8547 describes what NIST intends to do to its own standards and guidelines, and it aligns with National Security Memorandum 10, which set 2035 as the target for mitigating quantum risk across federal systems. Its force arrives indirectly, through three channels. Federal Information Processing Standard (FIPS) 140-3 module validation recognizes only approved algorithms. Federal procurement rules point at NIST guidance. And sector regulators treat NIST publications as the reference for what current practice means.

None of those channels waits for 2035 to start moving. The comment period on the draft closed in January 2025, and the dates in it are already turning up in vendor questionnaires and audit scopes.

The Replacement Set

NIST published the first three post-quantum standards in August 2024. Each one replaces a specific job that RSA and elliptic-curve cryptography do today.

• FIPS 203, ML-KEM. A key-encapsulation mechanism, meaning a method for two parties to agree on a shared secret over an open channel. This replaces RSA key transport and elliptic-curve Diffie-Hellman in TLS, the protocol behind HTTPS, and in IPsec and SSH.
• FIPS 204, ML-DSA. A digital signature algorithm, and the general-purpose replacement for RSA and ECDSA signatures in certificates, code signing and document signing.
• FIPS 205, SLH-DSA. A second signature algorithm built only on hash functions. Signatures are larger and slower, but the security rests on assumptions the field has studied for decades, and that makes it the conservative choice wherever signature size is not the binding constraint.

NIST has said a fourth signature scheme, FN-DSA, will follow, and in March 2025 it selected HQC as a second key-encapsulation mechanism to be standardized on its own timeline. Neither is available for deployment today, and neither is a reason to wait. The three published standards already cover the cases most organizations face.

Why Key Establishment Goes First

The draft treats confidentiality and authentication differently, and the asymmetry gives you a defensible order of work.

Encrypted traffic captured today can be decrypted later. An adversary records a TLS session in 2026, stores the ciphertext, and breaks the key exchange once a capable quantum computer exists. The plaintext is then as valuable as its confidentiality requirement says it is. This is harvest now, decrypt later, and it means the real deadline for key establishment is set by how long your data has to stay secret, not by the calendar in the draft.

Authentication does not work that way. A login that succeeded in 2026 cannot be forged retroactively in 2035. Signatures on short-lived certificates, session authentication and most machine credentials only need to be quantum-resistant by the time such a machine exists, and IR 8547 allows classical signature algorithms to continue in authentication use until that point.

One category breaks the pattern. Code signing on equipment that cannot be updated in the field is a 2026 procurement problem, not a 2035 operations problem. A programmable controller shipped this year with an ECDSA-only verification routine in read-only memory, still running in 2040, will accept any firmware image a quantum-capable attacker chooses to sign. Nothing done in 2038 repairs it. Devices with ten- and fifteen-year service lives need post-quantum verification designed in at manufacture, and that requirement belongs in the specification you write now.

Hybrid Deployment and the Open Question

A hybrid construction runs a classical and a post-quantum algorithm together, so the result holds unless both are broken. In TLS, that means one key exchange over an elliptic curve and one over ML-KEM, with both secrets combined into the session key. NIST accommodates the pattern in FIPS 140-3 validation, provided the composite is assembled correctly from approved components.

For most organizations, hybrid is the practical first move. It hedges against an implementation flaw in a young algorithm, and it preserves interoperability with counterparties who have not migrated. It also doubles what you have to track. Every hybrid deployment is two algorithms in the inventory, two sets of key material and two retirement dates.

The draft leaves one question open, raised directly by commenters. If RSA and elliptic-curve cryptography are disallowed after 2035, does a hybrid containing one of them remain acceptable? Until NIST answers, document hybrid deployments as explicitly transitional, with a target date for removing the classical half.

What a Reviewer Will Ask For

Technical understanding of ML-KEM is rarely the gap. The paperwork that turns a technical plan into an auditable one usually is. Four artifacts do most of the work.

1. A cryptographic inventory recording algorithm, key length, purpose, system owner and the confidentiality lifetime of the data involved. Congress required federal agencies to maintain one under the Quantum Computing Cybersecurity Preparedness Act of 2022, and the Office of Management and Budget set the reporting mechanics in memorandum M-23-02. Regulated industries are converging on the same expectation.
2. A written prioritization rationale. The test is simple to state. If the confidentiality lifetime of the data, plus the time your organization needs to migrate, runs past the arrival of a capable quantum computer, that system is already late. Every input is an estimate. The reasoning is still auditable.
3. Retirement dates that precede NIST’s. A plan that removes 112-bit key establishment during 2030 has misread the draft. Deprecation is the point at which the algorithm should already be gone from new systems.
4. Procurement language with teeth. Anything bought this year and kept for a decade should commit the supplier to ML-KEM and ML-DSA support on a stated schedule, and to the crypto-agility needed to change algorithms again later. A roadmap promising post-quantum support before 2035 is answering the wrong date. Hold suppliers to 2030.

Building the Team That Runs It

The transition is a governance exercise before it is an engineering one. The algorithms are published, the dates are set, and the difficult part is the inventory, the prioritization and the vendor management wrapped around them. Those are the skills our post-quantum certification programs are built to develop, and they are the reason we treat IR 8547 as a planning document rather than a news item.

You can review the certification programs at Quantum Academy. For structured migration methodology, see pqcframework.org. For deeper technical treatment of the standards themselves, PostQuantum.com covers each of the FIPS publications in detail.