NIST IR 8547: The Transition Timeline and What It Means for Your Team

Most organisations in the middle of a post-quantum migration programme have read about the NIST FIPS standards, FIPS 203, 204, 205, and 206, published in August and October 2024. Fewer have read NIST Interagency Report 8547. That is a gap, because IR 8547 answers the question the FIPS standards do not: when must the old algorithms stop.

This article is for the CISO, security architect, or compliance lead who needs to understand what IR 8547 specifically requires, who is bound by it, and what an organisation should be doing now. The FIPS standards tell you what to migrate to. IR 8547 tells you when. For the algorithm selection decisions themselves, which FIPS standard to use for which use case, see the FIPS 203/204/205 implementation decision map.

What NIST IR 8547 Actually Is, and Why It Is Different from the FIPS Standards

NIST IR 8547, "Transitioning the Use of Cryptographic Algorithms and Key Lengths," was published in final form in November 2024. It formally supersedes NIST SP 800-131A Rev. 2 (2019), which had been the primary NIST guidance document on algorithm transition timelines for the previous five years.

The FIPS 203/204/205/206 standards define what the new algorithms are, how they work, and what their parameter sets mean. IR 8547 does something different: it establishes when specific classical algorithms must stop being used in federal systems, and it introduces a two-category structure that security teams must understand precisely.

Deprecated carries a precise NIST meaning. Per NIST SP 800-131A (which IR 8547 inherits by reference): "Deprecated means that the algorithm and key length/strength may be used, but there is some security risk. The data owner must examine this risk potential and decide whether to continue using the algorithm." The status flags accumulating risk and shifts the burden of justification onto the data owner. It does not, by itself, prohibit continued use in any specific category of system.

Disallowed means the algorithm must not be used in any system, existing or new, after the stated date. Disallowance is the retirement endpoint, not the starting gun.

Conflating these two categories is the most common planning error in IR 8547 implementation. An organisation that reads "2030" and treats it as the total retirement date is planning for one gate instead of two.

The Deprecation Schedule: What Goes Away When

Under IR 8547, the following algorithms become deprecated after 2030: RSA (all key sizes), elliptic-curve Diffie-Hellman (ECDH), elliptic-curve digital signature algorithm (ECDSA), digital signature algorithm (DSA), and finite-field Diffie-Hellman (FFDH). From that date the data owner must document the risk justification for continued use of any of these algorithms. After 2035, the same algorithms become disallowed in all systems, including legacy deployments — the data owner no longer has the option to accept the risk.

Two details matter here and are frequently misunderstood.

First, SHA-1 is already disallowed, not deprecated, disallowed. SHA-2 (SHA-256, SHA-384, SHA-512) is not deprecated in IR 8547. Grover's algorithm reduces SHA-256's effective security from 256 bits to approximately 128 bits, which remains computationally infeasible to attack at any quantum hardware scale currently projected. SHA-512 is the conservative forward choice; SHA-256 is not an immediate liability. SHA-1 is gone.

Second, upgrading RSA key sizes is not a migration path. A common planning error is the assumption that moving from RSA-2048 to RSA-4096 buys additional time. IR 8547 depreciates all RSA key sizes by the same date. Shor's algorithm breaks integer factorisation regardless of key length, a longer RSA key increases the quantum hardware requirement modestly but does not change the timeline. The migration path is ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) for signatures. For the use-case-to-algorithm mapping, the FIPS decision map is the reference document.

Who Is Bound by IR 8547 and How Directly

US federal agencies and federal contractors are directly subject to IR 8547 through the hierarchy of NIST publications under the Federal Information Security Management Act (FISMA). For those organisations, IR 8547 is not advisory guidance, it is the operational standard.

Private-sector organisations without federal contracts are not legally bound, but the practical scope is wider than the formal scope. FedRAMP-authorised cloud services must demonstrate alignment to NIST cryptographic baselines, which will incorporate IR 8547 timelines. CMMC 2.0 scoped defence suppliers are required to align to NIST SP 800-171, and NIST SP 800-171 Rev. 3 draws on the same cryptographic guidance hierarchy. PCI DSS v4.0 references "strong cryptography" as defined by approved standards, and IR 8547 will become the operational definition for that term as the deprecation dates approach. Regulated financial services, healthcare, and technology organisations that reference NIST baselines in their own policies will find IR 8547 timelines embedded in their compliance obligations before a regulator specifically requires it.

UK and EU organisations are not legally bound by a US federal document. That said, the practical alignment is substantive. NCSC UK published its own PQC migration timeline guidance in March 2025, and its Phase 3 complete migration target is set at 2035, matching the IR 8547 disallowed date. EU organisations subject to NIS2 Article 21 risk management obligations are not bound by IR 8547 but will find that ENISA technical guidance increasingly references NIST PQC standards as the baseline for cryptographic resilience. The IR 8547 timeline is a useful planning anchor for UK and EU organisations even where it carries no formal authority.

What the 2030 Date Actually Means, and What It Does Not

The 2030 deprecation date applies to the algorithm itself, not to a specific category of system. From 2030, continued use of RSA, ECDSA, ECDH, DSA, or FFDH (in any system, new or existing) requires the data owner to examine the risk and document a justification. New deployments — new TLS certificates, new code signing certificates, new HSM key generation for long-lived keys, new RSA or ECDSA JWT signing — carry the heaviest justification burden because the migration cost to a quantum-safe alternative is lowest at design time.

What 2030 does not mean: it is not a migration completion date and it is not an absolute prohibition. It is the date from which deprecated algorithms enter the risk-acceptance zone, with continued use permitted on a documented basis. Full retirement is the 2035 disallowed date — at which point the risk-acceptance option is removed.

For security teams that have not yet begun a cryptographic inventory, the operational implication is uncomfortable. Between now and 2030 is approximately four years of programme execution time. NIST NCCoE SP 1800-38B, the primary migration methodology reference, describes cryptographic inventory, assessment, and migration for complex enterprises, and the methodology consistently finds that the inventory phase alone runs six to twelve months in a complex estate [INFERRED — extrapolated from NCCoE SP 1800-38B methodology scope and practitioner reporting; no formal benchmark published by NIST]. For organisations with PKI root hierarchies, operational technology networks, HSMs, and custom cryptographic integrations, four years of lead time is not generous. It is the minimum.

The Document Gap: IR 8547 and SP 800-57 Read Together

IR 8547 governs the retirement of public-key algorithms: RSA, ECDH, ECDSA, DSA, FFDH. It does not govern key sizes for symmetric algorithms and hash functions, which remain governed by NIST SP 800-57 Part 1. A team that focuses only on IR 8547 may upgrade its TLS configuration from RSA to ML-KEM while leaving AES-128 in place on a storage system where AES-256 is the correct response to Grover's algorithm.

The practical implication: AES-128 is not in immediate danger. Grover's algorithm halves effective key security, reducing AES-128 to approximately 64 bits of effective quantum security. Consensus in the cryptographic community is that this remains computationally infeasible at any quantum hardware scale currently projected for the 2030s. AES-256 is the conservative forward choice, and SP 800-57 recommends it for new deployments. But the urgency is different from the public-key algorithm retirement problem: an organisation that migrates to ML-KEM on TLS but keeps AES-128 on storage encryption is not in immediate breach of anything. The NIST SP 800-57 transition to AES-256 is a good practice upgrade, not a crisis fix.

Reading both documents together ensures the migration programme covers the full cryptographic surface, public-key algorithms under IR 8547, symmetric key sizes under SP 800-57.

The Compliance Exposure Window

The period between 2030 and 2035 creates a compliance exposure window that risk and audit functions should understand now. An organisation continuing to run RSA-2048 on production systems between 2030 and 2035 is operating within the permitted window for legacy systems, the algorithm is deprecated, not yet disallowed. That is technically compliant under IR 8547.

What changes is how auditors, insurers, and procurement teams treat that situation. Following the pattern of previous NIST cryptographic guidance transitions, the period immediately following a deprecation date is when risk committees begin treating legacy algorithm use as a finding rather than a scheduled remediation item. Cyber insurers writing policies for the 2030 to 2032 period will have underwriting questions about RSA-2048 in production systems. Procurement teams at large enterprises will begin including PQC migration status in supplier security questionnaires. An organisation that can show a documented migration plan, an active programme, and demonstrable progress will be in a materially different position to one with no evidence of having engaged with the IR 8547 timeline at all.

The Action Framework: What to Do by When

Now (2026). Complete a cryptographic inventory, a CBOM identifying every system using RSA, ECDSA, ECDH, DSA, or finite-field DH. Classify each system by whether it is existing or new, the confidentiality lifetime of data it handles, and its migration complexity (embedded, mainframe, off-the-shelf, cloud-native). The NIST NCCoE SP 1800-38B methodology is the reference for this work. The systems with the longest data confidentiality lifetimes and the greatest migration complexity are the ones that determine whether subsequent phase targets are achievable.

2026 to 2027. Cease issuing new RSA or ECDSA certificates for high-priority flows. Begin hybrid TLS deployment, ML-KEM combined with X25519, on externally facing services. The mechanism is IETF RFC 9496, X-Wing Hybrid KEM. Update procurement language to require FIPS 203/204/205/206 capable products. For the broader migration calendar across this period, see the PQC migration timeline.

2028 to 2030. Retire RSA and ECDSA from new system designs where the migration path is established. Complete certificate lifecycle rotation for externally exposed infrastructure. Submit vendor PQC roadmap requests for HSM, PKI, and network appliance platforms. By 2030, every continued use of a deprecated algorithm should have a documented risk justification on file — that is the operational reading of the SP 800-131A definition, and it is what auditors will ask for in 2031.

2031 to 2035. Address legacy and hard-to-migrate systems, operational technology, embedded devices, mainframe cryptographic services. Target the 2035 disallowed date as the hard retirement milestone. For organisations that discover their hardest-to-migrate systems in Phase 1, this window is the time available to complete them. Starting the legacy migration only after the easier systems are done is the correct sequencing; starting it only after 2030 is not.

The CBOM is the prerequisite to everything else. Organisations that have not yet started it are not behind schedule in a recoverable way, they are behind schedule in a way that will constrain their options in each subsequent phase.