up:: The Mandates MOC
NIST IR 8547
NIST IR 8547, “Transition to Post-Quantum Cryptography Standards,” is NIST’s technical roadmap for moving federal systems off quantum-vulnerable cryptography, and it carries the deprecation and disallowance schedule that names 2030 and 2035 as the dates classical RSA, ECDSA, and ECDH have to be gone. It’s the companion document to the first post-quantum FIPS standards (FIPS 203, FIPS 204, FIPS 205), and it answers the question those standards leave open: now that the replacements exist, which algorithms do I retire, and by when? As of this writing it’s an Initial Public Draft, so treat the specific years as NIST’s stated intent rather than settled law.
The short version:
- IR 8547 is NIST’s PQC transition guidance, the document that turns “migrate to post-quantum” into named algorithms with named deadline years.
- It’s an Initial Public Draft released November 12, 2024, with the comment period closed January 10, 2025 and a final version still expected. The dates below come from that draft and could shift in the final.
- Two years carry the weight: 2030, when 112-bit-strength public-key algorithms (RSA-2048, ECC P-256) become deprecated, and 2035, when all classical RSA, ECC, and Diffie-Hellman signature and key-establishment schemes become disallowed regardless of key size.
- It binds federal agencies, their contractors, and FIPS-validated vendors directly. Everyone else inherits it through sector regulators, procurement requirements, and vendor contracts.
- Its practical instruction is to migrate key establishment before signatures, because key exchange is the half exposed to harvest-now-decrypt-later.
Think of IR 8547 as the expiration-date label on your cryptographic pantry. The FIPS standards stocked the new shelf with what’s safe to eat. IR 8547 is the label that tells you which of the old cans are on notice, which come off the shelf entirely, and the year each one turns. A label like that is boring right up until it becomes the reason a budget gets approved.
What is NIST IR 8547?
NIST IR 8547 is an Internal Report from NIST’s Computer Security Division that describes NIST’s expected approach to transitioning from quantum-vulnerable algorithms to post-quantum digital signatures and key-establishment schemes. It identifies the quantum-vulnerable standards in use today and maps each one to the quantum-resistant standard that replaces it, then attaches a transition schedule.
Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024; authors Dustin Moody, Ray Perlner, Andrew Regenscheid, Angela Robinson, David Cooper.
A few things about its standing are worth being precise on, because they change how you cite it:
- It’s a draft. The current version is an Initial Public Draft, published November 12, 2024, with public comment closed January 10, 2025 and a final version expected. Quote its timeline as NIST’s stated intent, not as a finalized federal rule.
- It’s guidance, and it points at rules. An Internal Report gives guidance rather than issuing a mandate on its own. Its force comes from what it references: the FIPS standards (FIPS 203, FIPS 204, FIPS 205) are mandatory for federal agencies under FISMA, and the 2035 target it uses comes from National Security Memorandum 10 (NSM-10). IR 8547 is the technical layer those obligations sit on.
- Its reach runs past the federal government. Federal agencies and FISMA-covered systems follow it as a compliance obligation. Because national and sector regulators, insurers, and procurement programs align to NIST, its deprecation years become the de facto industry clock even for organizations that never touch a federal contract.
What’s the deprecation and disallowance timeline?
IR 8547 sorts every algorithm into one of three states, then attaches a year to the ones on their way out. The vocabulary is precise and worth keeping straight, because “deprecated” and “disallowed” are not the same instruction:
| Status | What it means for you |
|---|---|
| Acceptable | Approved for use under the associated guidance. |
| Deprecated | Still permitted, but the use now carries security risk that the data owner has to formally accept. This is the “you may, but you’re on the clock” state. |
| Disallowed | Prohibited for the stated purpose, with no exceptions. |
| Legacy use | Permitted only to process already-protected data, such as decrypting old ciphertext or verifying an old signature. |
Here’s the schedule, transcribed from the draft. This is the table a migration program anchors its phases to:
| Algorithm category | Status | Deprecated after | Disallowed after |
|---|---|---|---|
| RSA signatures/key transport, 112-bit security (e.g. RSA-2048) | Deprecated then disallowed | 2030 | 2035 |
| RSA signatures/key transport, ≥128-bit security | Acceptable until disallowance | none | 2035 |
| ECDSA, 112-bit security | Deprecated then disallowed | 2030 | 2035 |
| ECDSA, ≥128-bit security | Acceptable until disallowance | none | 2035 |
| EdDSA, ≥128-bit security | Acceptable until disallowance | none | 2035 |
| Finite-field DH/MQV, 112-bit security | Deprecated then disallowed | 2030 | 2035 |
| Finite-field DH/MQV, ≥128-bit security | Acceptable until disallowance | none | 2035 |
| Elliptic-curve DH/MQV, 112-bit security | Deprecated then disallowed | 2030 | 2035 |
| Elliptic-curve DH/MQV, ≥128-bit security | Acceptable until disallowance | none | 2035 |
| 112-bit symmetric primitives (e.g. SHA-224, 3-key TDEA) | Disallowed | none | 2030 |
| AES-128 / AES-192 / AES-256 | Acceptable | none | none |
| SHA-256 / SHA-384 / SHA-512 / SHA-3 family | Acceptable | none | none |
| ML-KEM (FIPS 203) | Acceptable | none | none |
| ML-DSA (FIPS 204) | Acceptable | none | none |
| SLH-DSA (FIPS 205) | Acceptable | none | none |
| LMS / XMSS / HSS / XMSSMT (stateful hash-based, SP 800-208) | Acceptable (narrow use) | none | none |
Source: NIST IR 8547 ipd, §4 and Tables 2 and 4.
Two details in that table trip people up, so they’re worth stating plainly:
- The 2030/2035 split is deliberate. An earlier NIST schedule (SP 800-57 Part 1) would have disallowed 112-bit public-key outright around 2031. IR 8547 softens that to deprecation, so organizations can keep 112-bit RSA and ECC running while they migrate, with the data owner accepting the risk. The drop-dead date for all classical signature and key-establishment schemes, at any key size, is 2035. The ≥128-bit schemes skip the deprecation step entirely and go straight from acceptable to disallowed in 2035.
- The 2030 symmetric line is a different animal. A small set of 112-bit symmetric primitives (SHA-224 collision strength, 3-key TDEA) are disallowed in 2030, not deprecated, and they’re not part of the deferred public-key schedule. Move off them as part of the same migration.
Which algorithms are affected, and what replaces them?
IR 8547 pairs each quantum-vulnerable algorithm with the post-quantum standard that takes its place. The mapping is the practical core of the document:
| What’s being retired | What replaces it |
|---|---|
| ECDH, DH, RSA key transport (key establishment) | ML-KEM (FIPS 203), the primary key-establishment standard |
| RSA signatures, ECDSA (digital signatures) | ML-DSA (FIPS 204) as the general-purpose signature; SLH-DSA (SLH-DSA) as the conservative hash-based option for long-lived signing like root CA and firmware keys |
The symmetric and hash side is far calmer, and IR 8547 says so. AES-128, AES-192, and AES-256 all stay acceptable, and NIST does not expect to move off AES as part of the PQC transition. The SHA-2 and SHA-3 families at 256-bit output and above stay acceptable too. The exception worth catching is that SHA-224 and SHA3-224 have collision strength below the lowest post-quantum category, so anything using them in certificate chains or code-signing manifests should move to SHA-256 or higher as part of the same cleanup. SHA-1 was already disallowed for collision-sensitive use, and that predates any quantum concern.
A FALCON-derived signature standard (FN-DSA, FIPS 206) is planned but was not finalized in the November 2024 draft, so it isn’t part of the current schedule.
What does the 2035 deadline actually force?
A dated requirement is what turns “someday” into a funded program. For years the honest answer to “when do we have to do this” was “before a quantum computer exists, and nobody knows when that is,” which is exactly the kind of answer that never gets a budget line. IR 8547 replaces that open question with two years on a page. Once 2035 is written down as the year these algorithms stop being allowed, the migration stops being a research topic and becomes a program with an owner, a phase plan, and a due date, whether or not a quantum computer arrives first. The 2035 target aligns with the federal transition deadline set by NSM-10, so for federal systems it isn’t a suggestion.
What does it mean for your migration?
The document sets an order of operations on top of the dates, and that order matters more than most teams expect.
- Inventory first. IR 8547 treats a cryptographic inventory, a bill of materials covering every algorithm, key size, and protocol in use, as the prerequisite to everything else. Planning a migration means mapping the schedule to your own systems first, and most organizations find their existing asset inventories don’t capture cryptography at that level.
- Migrate key establishment before signatures. Key exchange is the half exposed to harvest-now-decrypt-later: an adversary can record encrypted traffic today and decrypt it once a quantum computer exists. Signatures generally aren’t harvestable that way, so in a protocol like TLS you swap the key-establishment method first and can move the signature on a slower track. The exception is any signature that has to stay trustworthy for years, like code signing for long-lived devices, which becomes urgent for the same reason.
- “We have until 2035” is often wrong. IR 8547’s general algorithm schedule runs to 2035, but NIST has said its application-specific standards (for TLS, IPsec/IKE, PIV credentials, and others) may require earlier transitions, and that key-establishment migration in interactive protocols will be prioritized to address HNDL. The real deadline for a given system can pull years earlier than the headline date.
Source: NIST IR 8547 ipd, §4.2.
- Hybrid is a bridge, not the destination. NIST accommodates hybrid deployments (a classical algorithm and a post-quantum one combined in one session) as a transitional measure, and it will accommodate them in FIPS 140 validation when at least one component is NIST-approved. It doesn’t mandate hybrid, and full compliance still means retiring the classical component eventually.
Common misconceptions
- “IR 8547 is a final federal rule.” It’s an Initial Public Draft. The direction is firm and the FIPS standards it references are final, but the specific timeline years live in a draft that could still change.
- “Deprecated means banned.” Deprecated means still usable with formal risk acceptance by the data owner. Disallowed is the hard stop. The 2030 line deprecates 112-bit public-key; it doesn’t switch it off. The switch-off is 2035.
- “We deployed hybrid ML-KEM, so we’re done.” Running a classical and a post-quantum algorithm together is a transitional step. The classical half still has to come out before the deadline.
- “This is only asymmetric cryptography.” Mostly true, and that’s the point NIST makes, but the 112-bit symmetric primitives (SHA-224, 3-key TDEA) are disallowed in 2030, and SHA-224/SHA3-224 collision strength is too weak to keep in collision-sensitive uses. Those get swept up in the same work.
- “It only applies to the federal government.” Directly, it applies to federal agencies, their contractors, and FIPS-validated vendors. In practice its timelines reach commercial organizations through sector regulators, insurers, and procurement requirements that reference NIST.
Everything here is the map, given freely. When your team needs IR 8547’s timeline translated into a phased migration sequenced against your own systems, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.