NIST's final IR 8547 deprecates all RSA and ECC after 2030, five days after US agency PQC plans were due

Plans fell due on 22 October; the final report came on 27 October

The White House budget office told every US federal agency on 24 June 2026 to send in a post quantum cryptography (PQC) migration plan "no later than 120 days from the date of this memorandum". Counting from 24 June, that day was Thursday 22 October 2026 (derived). The same memorandum, OMB M-26-15, says agencies "must align their plans with NIST Internal Report (IR) 8547, Transition to Post-Quantum Cryptography Standards, or successor document", and its footnote on hybrid cryptography sends readers to the November 2024 initial public draft.

NIST published the final IR 8547 on 27 October 2026, five days after the plans fell due (derived), and 714 days after the draft (derived). The final text changes one line that matters to anyone who wrote a plan against the draft. The draft deprecated classical signatures and key establishment after 2030 only at the 112 bit security level, and left RSA, ECDSA, EdDSA and the elliptic curve and finite field Diffie Hellman schemes at 128 bits and above untouched until they are disallowed after 2035. The final deprecates all of them after 2030: "NIST will instead deprecate all quantum-vulnerable digital signature algorithms after 2030 and disallow their use under NIST standards and guidelines after 2035", with the same rule for key establishment.

What this does not establish: whether any agency filed its plan by 22 October, whether the plans used the draft or an early copy of the final text (NIST's editorial review board approved the final on 21 October, the day before the deadline, according to the PDF), whether OMB will ask for plans to be revised, how much money any of this has, or whether a single agency is on track. None of the primaries read for this briefing says. For the systems the Executive Order singles out, high value assets and high impact systems, the change matters less, because their own deadlines of 2030 and 2031 come first. It matters most for everything else, and for the companies outside government that copy NIST's tables into their own policies.

This briefing reads the documents themselves: NIST's news release of 27 October, the final report (PDF, 34 pages) and the draft (PDF, 30 pages), Executive Order 14412 of 22 June 2026, OMB M-26-15 (11 pages), National Security Memorandum 10 of 4 May 2022, and CISA's product categories list that the memo cites. All were read between about 11:20 and 11:35 GMT on Thursday 29 October 2026. Infosecurity Magazine's report of 29 October was the pointer to the story and is used for nothing else. NIST is the body that wrote the algorithms it now tells agencies to adopt, and its report should be read with that interest in mind.

What changed between the 2024 draft and the final text

The two versions share most of their prose. The differences sit in the tables and in the paragraphs that cite the 2026 orders. NIST's own tables show the main one more clearly than any redrawing could, so here they are side by side.

Zoom

"Deprecated" has a defined meaning in NIST's language and it is not "banned". The final report repeats it: the algorithm "may be used, but there is some security risk. The data owner must examine this risk potential and decide whether to continue". So from 2031 a bank, a hospital or a council that follows NIST's tables can still run RSA or elliptic curve signatures at 128 bits, but someone has to sign a risk acceptance for it. Under the draft, nobody did until 2036.

The deadlines, copied from the orders, and the days left

Every date in this table was read in the order or memorandum that set it. The day counts run from Thursday 29 October 2026 and are derived. Where a document says "after 2030" the count runs to 1 January 2031; where it says "by" a date, it runs to that date.

Zoom

Two features of these dates are easy to miss. First, the Executive Order reaches past government: within 180 days the FAR Council must propose a rule "to require covered contractors to comply by December 31, 2030, with NIST's FIPS, including all applicable FIPS incorporating PQC compliant algorithms". That proposal is due by 19 December 2026 (derived). The documents read here do not show whether it has been published, or which contractors "covered" will mean. Second, NIST measures the whole effort against history: "the journey from algorithm standardization to full integration into information systems can take 10 to 20 years." The key establishment deadline is 1,524 days away, about 4.2 years (derived).

The NSA's separate CNSA 2.0 dates for national security systems, and the UK NCSC's 2028, 2031 and 2035 milestones, are outside this report and were compared in an earlier briefing on the NCSC TLS guidance. The memorandum does not apply to national security systems, and the order's 2030 and 2031 directive excludes them.

What agencies are told to do, and in what order

IR 8547 is a road map, not a procedure. Its introduction gives the order in one sentence: organisations "should treat the migration to PQC as a current operational priority, beginning with cryptographic inventories, migration planning, and early deployments of PQC-enabled products and services." OMB M-26-15 turns that into five phases, each with years attached:

Three ordering rules run through both documents.

• Key establishment before signatures. The reason is "harvest now, decrypt later": data encrypted today can be recorded and read once a quantum computer exists, while a signature only has to hold at the moment it is checked. IR 8547 says authentication "may continue to use quantum-vulnerable algorithms" until such a computer exists, but warns that signatures are still urgent because the change is longer and involves more parties.
• Long lived secrets first. OMB tells agencies to prioritise systems holding "data expected to remain mission-sensitive in 2030", and IR 8547 restates Mosca's rule: start before the years data must stay secret plus the years the migration takes exceed the years until a quantum computer arrives.
• Slow hardware early. Smart card credentials, readers and the PKI behind them follow multi year replacement cycles, so IR 8547 says their updates "must begin early". Devices whose code signing check cannot be updated after manufacture should be built to require quantum resistant signatures if they will outlive the arrival of a quantum computer.

The algorithm choices are printed with their standard numbers. For key establishment, ML-KEM from FIPS 203, "the only approved post-quantum key-establishment scheme based on public-key cryptography", with ML-KEM-768 recommended as the default and HQC to follow once its FIPS is published. For signatures, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), plus the stateful LMS and XMSS schemes of SP 800-208, which IR 8547 says are "not intended for general use but may be useful for applications like software and firmware signing". A FIPS derived from FALCON is in development. Symmetric cryptography mostly stays: NIST "does not expect to need to transition away" from AES, SHA-2 and SHA-3, although 112 bit symmetric standards will be disallowed in 2030 and SHA-1 will be disallowed in FIPS validated modules after 2030.

TLS gets its own paragraph in the final report. It "protects data in transit for nearly every federal system and service, making it a primary target", agencies must support TLS 1.3 by 2 January 2030, and guidance on quantum resistant key establishment in TLS, including hybrids, "will be reflected in the next revision of SP 800-52". That revision is promised, not published. For the same split between key exchange and signatures in DNS, see the earlier briefing on DNSSEC and ML-DSA signature sizes.

Hybrid schemes: accommodated, not required, and called a stopgap

A hybrid combines a classical algorithm with a post quantum one so that an attacker has to break both. NIST's release calls it "akin to using two padlocks on a door instead of one". The two primaries are cooler about it than that image suggests. IR 8547 says hybrids "add complexity to implementations and architectures, which can increase security risks and costs" and are "typically expected to be temporary measures that lead to a second transition". OMB's appendix calls the hybrid model "an intricate and resource-intensive stopgap" and lets agencies choose it "based on their own risk assessments".

Zoom

Mechanically, NIST already allows a generic composite under SP 800-56C: join a shared secret Z from an approved scheme with a second secret T from anywhere, and derive keys from the result. NIST will update SP 800-56C so that Z can come from FIPS 203 directly and so that the order can be reversed. The important line for buyers is the validation rule: "as long as at least one of the inputs to an approved composite (i.e., hybrid) key-establishment technique comes from an approved key-establishment scheme, the combination can be FIPS 140-validated, even if other inputs are disallowed." For signatures, NIST accommodates dual signatures "provided that at least one component digital signature algorithm is NIST-approved". What NIST leaves open is whether to use a hybrid at all: it "leaves the decision to each specific application".

Four labels that sound like controls

• "Aligned with IR 8547." OMB required alignment with IR 8547 "or successor document" and pointed at the draft. A plan aligned with the draft treats 128 bit RSA and elliptic curve keys as fine until 2035. The phrase is true of both kinds of plan and tells a reader nothing about which.
• "Deprecated." It reads like retired. In NIST's terms it means still allowed, with the data owner carrying the risk. Disallowed comes five years later.
• "FIPS 140 validated hybrid." A hybrid can be validated with one approved input and one disallowed input. Validation tells a buyer that one half meets NIST's rules, not that both halves are strong.
• "PQC capable." CISA's list, which OMB tells agencies to use, names product categories where PQC capable products are "widely available" and says organisations "should acquire only PQC-capable products" in them. Capable is a property of the product. Whether ML-KEM is switched on and negotiated is a property of the configuration, and the list does not check it.

Stated on the record, and not stated

What is left to agencies, and three loose ends

Agencies decide which systems count as "highly-sensitive" beyond the HVA and high impact lists, whether to use hybrids, which legacy systems to replace or decommission, how to automate inventory, and how to fund it. IR 8547 also leaves application rules to later documents: the revised SP 800-131A with "more detailed guidelines and schedules", the next SP 800-52 for TLS, and updated PIV standards. Until those exist, the 2030 and 2035 lines are the only dates NIST itself has set for everything outside the order's priority systems.

Three details in the memorandum do not line up, and an agency reading it closely would have to choose:

1. The body sets out five phases, but Appendix B asks for "Timelines and milestones to achieve all three migration phases".
2. After its list of quantum vulnerable algorithms, Appendix A says "Symmetric-key-based protocols should also be avoided." IR 8547 says NIST "does not expect to need to transition away" from its symmetric standards. The memo does not explain the line.
3. The memo's footnote for hybrids points to the draft of IR 8547, which no longer reflects NIST's position on 128 bit algorithms.

Technical details

These are the artifacts the primaries print: transition tables, parameter sets, the composite key rule, OMB's hybrid TLS handshake and its list of quantum vulnerable algorithms. They are standards text, not attack material. A defender uses them to write a crypto policy, to set scanner rules for a cryptographic inventory, and to check vendor claims. Layout is this site's; the words are copied.

The final transition rows for classical public key algorithms. Anything on this list in your inventory has a 2030 deprecation date and a 2035 disallowance date under NIST's rules, earlier for federal priority systems.

Table 2. Quantum-vulnerable digital signature algorithms
ECDSA [FIPS186]  >= 112 bits of classical security strength  Deprecated after 2030, Disallowed after 2035
EdDSA [FIPS186]  >= 128 bits of classical security strength  Deprecated after 2030, Disallowed after 2035
RSA   [FIPS186]  >= 112 bits of classical security strength  Deprecated after 2030, Disallowed after 2035

Table 4. Quantum-vulnerable key-establishment schemes
Finite Field DH and MQV [SP80056A]    >= 112 bits of classical security strength  Deprecated after 2030, Disallowed after 2035
Elliptic Curve DH and MQV [SP80056A]  >= 112 bits of classical security strength  Deprecated after 2030, Disallowed after 2035
RSA [SP80056B]                        >= 112 bits of classical security strength  Deprecated after 2030, Disallowed after 2035

The post quantum replacements, with NIST's default for key establishment. A scanner rule that flags ML-KEM-512 or ML-KEM-1024 is not flagging an error; NIST allows them where 768 is impractical or more security is needed.

ML-KEM [FIPS203]  ML-KEM-512   128 bits  1
                  ML-KEM-768   192 bits  3
                  ML-KEM-1024  256 bits  5
NIST recommends using ML-KEM-768 as the default parameter set

ML-DSA [FIPS204]  ML-DSA-44  128 bits  2
                  ML-DSA-65  192 bits  3
                  ML-DSA-87  256 bits  5
The security category for ML-DSA-44 is reduced to category 1 if an approved RBG with less than 192 bits of security is used.

The composite key rule that makes hybrids possible inside NIST's framework. Z is a shared secret from an approved scheme; T is the second secret.

The value Z’=Z||T may then be treated as a shared secret and any of the key
derivation methods given in SP 800-56C may be applied to Z’ to derive secret keying material.
SP 800-56C will also be updated to reflect that the ordering of Z and T can be reversed
(i.e., Z’=T||Z is also allowed).
The order of the shared secrets will need to be specified at the protocol level to avoid confusion.

OMB's description of a hybrid key exchange in TLS 1.3. It is what an agency network team, or anyone copying the federal approach, would look for in a handshake capture: two key shares in one ClientHello.

1. ClientHello: The client signals its support for a hybrid key exchange by sending key
shares for both a traditional group (e.g., x25519) and a PQC KEM (e.g., FIPS 203 ML-
KEM-768) in the key_share extension.
2. ServerHello: If the server supports the proposed hybrid scheme, it generates its own
corresponding key shares and sends them back in its key share extension.
3. Key Derivation: Both the client and server now independently compute two shared
secrets, one from the classical exchange and one from the PQC exchange. These two
secrets are then combined (e.g., concatenated) and used as the input to the TLS 1.3 key
derivation function to generate the session’s traffic keys.

OMB's list of what counts as quantum vulnerable, which is the search list for an inventory. Its footnote 13 tells agencies to treat as quantum vulnerable "any asymmetric algorithm that is not definitively known to be quantum-resistant".

Elliptic Curve Diffie-Hellman (ECDH) Key Exchange   NIST SP 800-56A/B/C
Menezes-Qu-Vanstone (MQV) Key Exchange              NIST SP 800-56A rev3
Elliptic Curve Digital Signature Algorithm (ECDSA)  FIPS PUB 186-5
Diffie-Hellman (DH) Key Exchange and variants       NIST 800-56A rev3
Rivest-Shamir-Adleman (RSA) Signature Algorithm     FIPS SP 800-56B rev 1
RSA Key Establishment                               SP 800-56B rev1
Digital Signature Algorithm                         FIPS 186-5
Other non-PQC Asymmetric Algorithms                 Not applicable
Symmetric-key-based protocols should also be avoided.

Finally, the minimum contents OMB set for each agency's plan. It doubles as a ready made outline for any organisation's own migration plan.

A system prioritization strategy with risk-based justification;
Timelines and milestones to achieve all three migration phases;
Timelines and milestones for testing and deployment to meet the TLS 1.3 support
deadline established by this memorandum;
The methodologies and automated tools used for the cryptographic inventory;
A plan for implementing a cryptographic agile architecture;
A third-party coordination plan;
An estimate of funding and personnel resources required;
A risk management strategy for the migration period; and
A section defining governance roles and responsibilities.

If you are not a federal agency but want to follow it

IR 8547 says it serves "as a blueprint for critical infrastructure owners and operators and other organizations". In order of what pays off first:

The question the record leaves open

Every agency had to file a plan aligned with IR 8547 by 22 October. The only version public on that day told them that RSA and elliptic curve keys at 128 bits and above could run without a risk sign off until 2035. Five days later NIST moved that line to 2030. So the question for OMB, and for any board that has copied the federal road map: how many of the plans already filed were written against the draft, and who will ask for them to be redone before they become the baseline that 2030 is measured against?

Key facts