Quick answer: NIST IR 8547 is the initial public draft (published November 12, 2024) of NIST’s proposed timeline for retiring quantum-vulnerable public-key algorithms such as RSA, ECDSA, ECDH, and finite-field Diffie-Hellman. It proposes deprecating them after 2030 and disallowing them entirely after 2035. As of mid-2026 it remains a draft, not a finalized standard, but federal direction, including OMB M-26-15, already treats its dates as the working planning baseline. For PKI, code signing, TLS, VPN, IAM, and HSM owners, that means inventory and migration work needs to start now, not in 2029.
Two dates get repeated constantly in post-quantum planning decks: 2030 and 2035. Fewer people can say precisely what happens on those dates, to which algorithms, or what “deprecated” is supposed to mean operationally versus “disallowed.” NIST IR 8547 is the document those dates actually come from, and it is more specific, and more conditional, than the slide-deck version suggests.
This guide translates IR 8547’s algorithm-by-algorithm timeline into concrete actions for the teams who own PKI, code signing, TLS and VPN infrastructure, identity and access management, and HSMs.
Key Takeaways
- NIST IR 8547 is an initial public draft released November 12, 2024, and it had not been finalized as of mid-2026, so its dates should be treated as the working baseline, not a locked mandate.
- The core proposal: quantum-vulnerable public-key algorithms providing 112-bit security (RSA-2048, ECC P-256, and similar) are deprecated after 2030 and disallowed after 2035.
- “Deprecated” means discouraged but still technically permitted with restrictions; “disallowed” means no longer approved for use in NIST-conformant systems at all.
- Federal policy is already moving faster than the draft’s own uncertainty suggests. OMB M-26-15 directs agencies to align migration plans with IR 8547 and sets 2035 as the full-migration date.
- 2035 looks distant, but PKI, HSM, and embedded-system replacement cycles routinely take years, which makes 2030, not 2035, the date that actually constrains most migration plans.
What NIST IR 8547 Actually Says
NIST IR 8547, “Transition to Post-Quantum Cryptography Standards,” is an Internal Report, not a Federal Information Processing Standard. It describes NIST’s expected approach for retiring quantum-vulnerable digital signature algorithms and key-establishment schemes and replacing them with FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). NIST released the initial public draft on November 12, 2024, and comments received on that draft are meant to feed a revised transition plan and additional algorithm- and application-specific guidance.
The proposed timeline works on two thresholds tied to a security-strength floor:
| Status | Proposed timing | What it means in practice |
|---|---|---|
| Deprecated | After 2030 | Use is discouraged; the algorithm should not be selected for new systems, and existing use should have a documented migration plan |
| Disallowed | After 2035 | The algorithm is no longer approved for use in NIST-conformant systems under any circumstance |
The algorithms in scope are the classical public-key primitives that a cryptographically relevant quantum computer could break using Shor’s algorithm: RSA (encryption and signatures), ECDSA, ECDH, and finite-field Diffie-Hellman. Symmetric algorithms like AES-256, and hash functions at sufficient output length, are not part of this transition; NIST considers them adequately quantum-resistant already, subject only to Grover’s algorithm, which AES-256 already accommodates.
The accuracy point worth stressing: IR 8547 is guidance, not a binding standard, and it remained an initial public draft through mid-2026. That status matters for how an organization should talk about these dates internally. They are the most credible planning baseline available, but presenting them as a locked legal mandate overstates what the document currently is.
Why a Draft Document Is Already Driving Federal Action
A document’s draft status has not stopped it from becoming the reference point other federal policy builds on. OMB guidance directs agencies to align their own migration plans with IR 8547 and treats 2035 as the target date for full migration of remaining systems, consistent with the draft’s proposed disallowance timeline. National Security Memorandum 10 independently set 2035 as the target for federal systems to be quantum-resistant, giving IR 8547’s proposed disallowance date the backing of a separate presidential directive rather than leaving it as NIST’s opinion alone.
The practical result: an organization that waits for IR 8547 to reach final status before starting migration work is optimizing for the wrong risk. The dates are already functioning as compliance and procurement reference points in federal contracting and audit conversations, regardless of the document’s formal status.
What the Timeline Means for Each System Owner
IR 8547 sets the algorithm-level deadline. What it does not do is tell a PKI lead or a network engineer what to do on Monday morning. That translation depends on where the algorithm actually runs.
| System owner | Where the deadline bites | Priority action before 2030 |
|---|---|---|
| PKI and certificate authority teams | Root and issuing CA signature algorithms, certificate templates | Sequence CA hierarchy migration to ML-DSA root-first; validate downstream applications can consume PQC or hybrid certificates |
| Code signing owners | Long-lived signatures on firmware and software that must stay verifiable for years past 2030 | Move signing pipelines to ML-DSA, prioritizing artifacts with the longest verification lifespan |
| TLS and network teams | Key exchange in TLS handshakes, VPN tunnels, load balancers | Pilot hybrid key exchange such as X25519MLKEM768 and measure handshake size, latency, and middlebox behavior |
| IAM and identity teams | Certificate-based authentication, smart cards, federation signing keys | Inventory authentication flows that depend on RSA or ECDSA signatures and plan credential reissuance |
| HSM and key management teams | Firmware support for PQC signing and key generation operations | Confirm current HSM firmware supports ML-KEM and ML-DSA, and budget for refresh where it does not |
| Application owners | Hardcoded algorithm references, TLS libraries, embedded cryptography | Audit code and configuration for hardcoded RSA or ECDSA references that will not update automatically with a library patch |
The common thread across every row is that none of these actions can start responsibly without knowing where RSA, ECDSA, ECDH, and Diffie-Hellman are actually deployed today. Most organizations cannot answer that question with confidence, which is why a cryptographic inventory, not algorithm selection, is the realistic first milestone on any IR 8547-aligned roadmap.
Why 2030, Not 2035, Is the Real Constraint
Nine years feels like a long runway until it is measured against replacement cycles that were never designed with a 2030 checkpoint in mind. Embedded systems, industrial control equipment, and long-lived hardware security modules can have procurement and certification cycles that stretch several years on their own, before any migration work begins. HSM firmware updates require validation and change control. PKI root ceremonies are deliberately infrequent, high-ceremony events, not something to schedule reactively. An organization that starts inventory work in 2029 has effectively no realistic path to a deprecated-algorithm-free environment by 2030, regardless of budget.
The organizations treating this correctly are working backward from 2030 as the meaningful constraint, using 2035 as the outer boundary for anything that could not reasonably be finished sooner, rather than the other way around.
How Encryption Consulting Can Help
Every action item in the table above depends on answering one question first: where do RSA, ECDSA, ECDH, and Diffie-Hellman actually run inside your environment today. CBOM Secure builds and continuously maintains that inventory, scanning certificates, keys, libraries, and protocols across on-prem, cloud, and hybrid systems, and mapping each finding to a business owner and criticality rating. It is the deliverable that turns IR 8547’s 2030 and 2035 dates from an abstract deadline into a prioritized, owner-assigned worklist.
From that inventory, our PQC Advisory Services build the phased roadmap itself: sequencing PKI root-first migration, HSM firmware readiness, and hybrid rollout against the 2030 deprecation date rather than the more distant 2035 disallowance date, so the plan reflects the constraint that actually binds most organizations.
Once the roadmap is set, CertSecure Manager executes the certificate-side migration, orchestrating a root-first move to ML-DSA across Microsoft AD CS, other enterprise CA platforms, and public CAs, with hybrid and composite certificate formats supported for the transition window.
Turning Dates Into a Plan
NIST IR 8547’s 2030 and 2035 dates are proposed, not finalized, but they are already functioning as the working baseline that federal policy, procurement language, and audit expectations are built around. The organizations best positioned for 2030 are treating deprecation, not disallowance, as the real deadline, and treating cryptographic inventory, not algorithm selection, as the first milestone. The document describes an algorithm transition. The work that gets an organization through it is PKI sequencing, HSM readiness, and knowing exactly where classical cryptography lives today.
Frequently Asked Questions
Is NIST IR 8547 a final standard?
No. It is an initial public draft released November 12, 2024, and it had not been finalized as of mid-2026. It is guidance describing NIST’s expected transition approach, not a binding Federal Information Processing Standard.
What is the difference between “deprecated” and “disallowed”?
Deprecated means use is discouraged and should not appear in new systems, though existing use may continue with a documented migration plan. Disallowed means the algorithm is no longer approved for use at all under NIST-conformant guidance.
Which algorithms does NIST IR 8547 cover?
Quantum-vulnerable public-key algorithms: RSA, ECDSA, ECDH, and finite-field Diffie-Hellman. Symmetric algorithms such as AES-256 and sufficiently long hash functions are not in scope, since they are already considered adequately resistant to quantum attack.
If the draft is not final, why should we start migrating now?
Because other federal policy, including OMB direction and National Security Memorandum 10, already treats IR 8547’s proposed dates as the working baseline for migration planning, and because PKI, HSM, and embedded-system replacement cycles routinely take years. Waiting for the draft to finalize risks running out of runway before 2030.
What should be the first step toward IR 8547 compliance?
Build an accurate cryptographic inventory of where RSA, ECDSA, ECDH, and Diffie-Hellman are actually used, mapped to system owner and data sensitivity. Every subsequent migration decision depends on that inventory being correct.
