NIST’s Final Post-Quantum Transition Report Puts Every Quantum-Vulnerable Public-Key Scheme on One 2030 and 2035 Clock, and Three Federal Documents Word the Deadline Three Ways

On October 27, NIST published the final NIST IR 8547, Transition to Post-Quantum Cryptography Standards. Its Editorial Review Board approved the report on October 21, and it replaces the initial public draft that NIST released on November 12, 2024, almost two years earlier. The draft’s PDF now opens with a notice that it “has been withdrawn and is provided solely for historical purposes.” NIST’s news release calls the report its “high-level road map” for moving to the post-quantum standards the agency published in 2024.

I read both PDFs side by side, rendered their tables as images to confirm the text extraction, and checked the report against the two federal documents it leans on: Executive Order 14412 and OMB Memorandum M-26-15. I also read the IETF draft behind the hybrid TLS groups that large sites now negotiate, and ran TLS handshakes against 18 public hosts, 10 of them federal, with OpenSSL 3.5.7 at 10:33 UTC today.

The short version:

• The deprecation rule widened. The draft gave 112-bit RSA, ECDSA and Diffie-Hellman a deprecation step after 2030 but listed the stronger parameter sets only as “Disallowed after 2035.” The final has one row per family and puts every row under “Deprecated after 2030” and “Disallowed after 2035,” so P-256 and RSA-3072 now share RSA-2048’s dates. NIST’s news release describes the phase-out in general terms and does not say that the rule changed.
• The federal clock is separate, and for signatures it runs a year behind NIST’s. EO 14412 sets the end of 2030 for post-quantum key establishment and the end of 2031 for signatures on high value assets and high impact systems. NIST’s “deprecated after 2030” begins on January 1, 2031 by my reading, so the signature deadline lands inside the deprecation window, not ahead of it.
• Three federal documents word the deadline three ways. The order tells OMB to issue guidance “requiring” migration by those dates, the OMB memo sets an “objective” of reducing “as much quantum risk as feasible” by the end of 2030 and says its phases “should” migrate systems, and the NIST report says the systems “must adopt” post-quantum cryptography by the dates.
• Agency plans were due before the final existed. OMB told agencies to align their plans with IR 8547 “or successor document” and linked the draft’s address. By my count the 120-day plan deadline fell on October 22, five days before NIST published the final.
• The hybrid key exchange is deployed; the certificates are not. 14 of 18 hosts negotiated X25519MLKEM768, which includes ML-KEM-768, the parameter set the report recommends as the default. All 18 still authenticated with ECDSA P-256 or RSA-2048 certificates signed with ECDSA or RSA, which the report puts on the same 2030 and 2035 clock.

Our earlier post on Cloudflare’s post-quantum visibility fields described the draft’s tables, which marked only 112-bit schemes as deprecated after 2030. That description was accurate for the draft. It is out of date now.

What changed between the draft and the final

Several passages carried over unchanged, among them the warning that hybrid solutions are “typically expected to be temporary measures that lead to a second transition” and the plan to update SP 800-56C so that the first shared secret may come from FIPS 203. The differences cluster in the timeline and in the policy layer that arrived in June 2026.

The deprecation step now covers every row

In the draft, Table 2 (signatures) and Table 4 (key establishment) split their families by strength. RSA, ECDSA and the Diffie-Hellman families at 112 bits were “Deprecated after 2030” and “Disallowed after 2035.” The same families at 128 bits and above, plus EdDSA, which has no 112-bit row, carried only “Disallowed after 2035.” That is six rows in all. The draft’s text presented the 112-bit step as a replacement for the older plan to disallow 112-bit public-key schemes on January 1, 2031: NIST would “instead deprecate classical digital signatures at the 112-bit security level.”

The final drops the split. Table 2 lists ECDSA and RSA at “≥ 112 bits of classical security strength” and EdDSA at “≥ 128 bits of classical security strength,” and every row carries both statuses. The text says NIST “will instead deprecate all quantum-vulnerable digital signature algorithms after 2030 and disallow their use under NIST standards and guidelines after 2035,” and repeats the rule for key establishment: “NIST will deprecate all quantum-vulnerable cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.”

The report takes the meaning of “deprecated” from SP 800-131A: the algorithm “may be used, but there is some security risk,” and “The data owner must examine this risk potential and decide whether to continue to use a deprecated algorithm or key length.” For anyone following NIST guidance, a scheme such as ECDSA P-256, which the draft marked only for disallowance after 2035, becomes a risk decision for the data owner from 2031.

Two clocks, and where they overlap

On the federal deadlines the report is blunt: measured against the 10 to 20 years that earlier cryptographic transitions took, “these deadlines leave little margin.” The federal dates and NIST’s own dates are easiest to read in one list.

The report never defines “after 2030.” The plan it replaces, in SP 800-57 Part 1, had projected disallowing 112-bit public-key schemes “on January 1, 2031,” so I read “after 2030” as starting on that date.

For key establishment, the two clocks start together. The end of 2030 is both the federal deadline for the most sensitive systems and the last day before NIST’s classical schemes become deprecated. For signatures they do not. The federal deadline is the end of 2031, so a high value asset that is still signing with ECDSA on January 1, 2031 is using a scheme NIST calls deprecated and is still inside the order’s deadline for another twelve months.

The report says something close to this in different words. Its section 4 states that the 2030-2035 window “does not alter the earlier deadlines that apply to high value assets, high impact systems, and other high-sensitivity federal systems,” and that continued use of deprecated algorithms is “constrained by the earlier migration deadlines established under EO 14412.” Both statements hold against the 2035 disallowance date. For signatures they do not hold against the start of the deprecation window.

Three documents, three wordings

The federal dates reach readers through four texts, and they do not use the same verbs.

The memo says it “implements” the order’s accelerated migration, and I am not offering a legal reading of what binds an agency; OMB’s later guidance and each agency’s plan are the places to look for that. The practical point is narrower. If a contract, plan or audit cites a date, it matters which of these texts it cites. The report’s “must adopt” is the firmest wording of the three, and it sits in a document whose abstract says it “supports the implementation” of the order and the memo, not that it creates the requirement.

A timing wrinkle: plans were due before the final existed

OMB’s memo is dated two days after the order. It tells agencies to submit a PQC migration plan “no later than 120 days from the date of this memorandum,” and adds: “Agencies must align their plans with NIST Internal Report (IR) 8547, Transition to Post-Quantum Cryptography Standards, or successor document.” By my count, 120 days from June 24 is Thursday, October 22. NIST’s review board approved the final on October 21 and NIST published it on October 27, five days after that date. The memo’s own footnote on hybrid architectures, in Appendix A, points to csrc.nist.gov/pubs/ir/8547/ipd, which is the draft’s address.

For the high value assets and high impact systems the order governs, the table change is moot, because they migrate earlier. For the tail of everything else, which is where the 2030 to 2035 window matters, a plan written against the draft could treat a 128-bit scheme such as P-256 as untouched until its 2035 disallowance. The final says otherwise. I have not seen any agency’s plan, so this is what the documents imply, not a finding about a particular agency.

Hybrid key exchange: what the report allows and what endpoints already do

Three descriptions of the same trade-off

The report says hybrid solutions are a hedge against a flaw in one component, but that they “add complexity to implementations and architectures, which can increase security risks and costs during the transition to PQC,” and it leaves the choice to each application. OMB’s memo calls a hybrid architecture “an intricate and resource-intensive stopgap” and asks agencies to perform “a thorough evaluation of its tradeoffs.” NIST’s news release says the option “has the advantage of being more conservative from a security standpoint but also demands more computational resources.” All three are fair summaries of one trade-off. They lead with different halves of it: the report stresses complexity and a second migration to post-quantum algorithms alone, the memo stresses cost and calls the approach a stopgap, and the news release stresses the security advantage.

Why the order of the two secrets matters

The report’s hybrid rule is the generic composite in SP 800-56C: a first shared secret Z from an approved scheme and a second secret T from anywhere, joined as Z followed by T. The final adds three things. NIST will update SP 800-56C so that “the ordering of Z and T can be reversed,” the generic composite is allowed even when T comes from a disallowed algorithm, and a composite “can be FIPS 140-validated, even if other inputs are disallowed.” It repeats the draft’s plan to update SP 800-56C so that Z may come from FIPS 203.

The IETF draft explains why order is a live question in TLS. It notes that SP 800-56Cr2 approves HKDF over two shared secrets “with the condition that the first one is computed by a FIPS-approved key-establishment scheme,” and that for this reason “the ML-KEM shared secret is placed first in X25519MLKEM768, while the ECDH shared secret is placed first in SecP256r1MLKEM768 and SecP384r1MLKEM1024.” The draft states the consequence directly: for the two NIST-curve groups the ECDH implementation must be certified and the ML-KEM one need not be, and for X25519MLKEM768 the ML-KEM implementation must be certified. The draft is revision 05, dated May 26, 2026, and it labels its own FIPS discussion “informal notes.”

CSRC’s page for SP 800-56C Revision 2 (August 2020) carries a planning note dated January 6, 2026: “NIST has decided to revise this publication.” No revised text is posted there. My reading is that the report’s ordering relaxation is aimed at exactly this rule, but until the revision appears, a claim that a given hybrid group is FIPS-aligned rests on the existing wording plus NIST’s stated intent.

What 18 handshakes show

To see how much of this is already visible on the wire, I connected to 18 public hosts with OpenSSL 3.5.7, which offers the X25519MLKEM768 hybrid group by default. For each host I recorded the negotiated key-exchange group, the certificate key, and the signature algorithm on every certificate the server sent. This is the check, run in Git Bash here for four of the hosts:

for h in www.nist.gov www.whitehouse.gov www.nsa.gov github.com; do
  echo "== $h"
  echo | openssl s_client -connect $h:443 -servername $h 2>/dev/null \
    | grep -E "Negotiated TLS1.3 group|Peer Temp Key|Peer signature type|Server public key"
done

A host that negotiates the hybrid prints Negotiated TLS1.3 group: X25519MLKEM768. A host that falls back to plain X25519 prints Peer Temp Key: X25519, 253 bits instead. This is what I got:

== www.nist.gov
Peer signature type: ecdsa_secp256r1_sha256
Negotiated TLS1.3 group: X25519MLKEM768
Server public key is 256 bit
== www.whitehouse.gov
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
Server public key is 256 bit
== www.nsa.gov
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
Server public key is 2048 bit
== github.com
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
Server public key is 256 bit

The key type and the issuer’s signature on the leaf certificate can be read by piping the same handshake into openssl x509:

echo | openssl s_client -connect www.nist.gov:443 -servername www.nist.gov 2>/dev/null \
  | openssl x509 -noout -text | grep -E "Signature Algorithm|Public Key Algorithm|Public-Key|NIST CURVE"

        Signature Algorithm: ecdsa-with-SHA384
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                NIST CURVE: P-256
    Signature Algorithm: ecdsa-with-SHA384

Here is the full set of 18, from one client at about 10:33 UTC on October 28, 2026:

Three readings follow from the table, with the limits stated below it.

• Key establishment is mostly hybrid already. 14 of 18 hosts negotiated X25519MLKEM768 (8 of 10 federal, 6 of 8 other). The four that stayed on plain X25519 were www.whitehouse.gov, www.federalregister.gov, github.com and kernel.org. X25519 is elliptic-curve Diffie-Hellman, and the report’s Table 4 lists elliptic-curve Diffie-Hellman among the schemes that are deprecated after 2030 and disallowed after 2035; it cites SP 800-56A for the family and does not name X25519.
• Authentication has not moved. All 18 leaf certificates are classical: 9 use ECDSA P-256 and 9 use RSA-2048. Every certificate the servers sent is signed with ECDSA or RSA, with SHA-256 or SHA-384. Under Table 2 these sit on the same “Deprecated after 2030” and “Disallowed after 2035” clock, and for high value assets the order’s signature deadline is the end of 2031.
• The agencies’ own sites differ from each other. www.nist.gov and csrc.nist.gov, where the report is hosted, negotiated the hybrid group, and so did www.cisa.gov, www.govinfo.gov, www.irs.gov, www.treasury.gov, www.nsa.gov and www.gsa.gov. www.whitehouse.gov and www.federalregister.gov did not.

The limits matter. This is one client, one network path and one moment. CDNs and edge providers can decide which groups a hostname supports, and the answer may differ by region or client. A public website is not a high value asset or a high impact system, so none of this says anything about the systems the order targets. I did not test whether any server would accept a client that offers only classical groups, or whether a client that offers only the hybrid would be refused.

What the documents leave open

• Legacy use after 2035. The report defines “legacy use” as processing already protected information, “e.g., to decrypt ciphertext data or to verify a digital signature,” but it does not say whether disallowed schemes will get a legacy-use status. The draft’s scope paragraph listed “controlled legacy use” among the transition’s parts and the final’s does not. I found no replacement text.
• The documents that will carry the rules. The report says NIST “will revise SP 800-131A with more detailed guidelines and schedules.” CSRC’s page for Revision 2 of SP 800-131A (March 2019) still carries only a note about the initial public draft of Revision 3, which was published on October 21, 2024 and closed for comments on December 4, 2024. SP 800-52 Revision 2, the TLS guidance in which quantum-resistant key establishment “will be reflected in the next revision,” carries a May 7, 2026 note that it “is currently being reviewed.” The report gives no dates for any of these, or for the FIPS standards for HQC and the Falcon-derived signature algorithm, which it describes as under development.
• Two lines in the OMB memo that the report does not echo. The memo’s table of quantum-vulnerable algorithms names ECDSA, RSA and DSA but not EdDSA, which NIST’s Table 2 lists; the memo’s “other non-PQC asymmetric algorithms” row and its footnote on treating unknown asymmetric algorithms as vulnerable would, in my reading, cover it. Below the table the memo adds, without explanation, “Symmetric-key-based protocols should also be avoided.” The report says NIST “does not expect to need to transition away from these standards” for symmetric cryptography. These may concern different things, protocols in one case and primitives in the other, and the memo does not say.
• The order’s own deliverables. By my count from June 22, the 180-day deliverables fall on Saturday, December 19, 2026: a proposed FAR rule requiring covered contractors to comply by December 31, 2030 with NIST’s FIPS, “including all applicable FIPS incorporating PQC compliant algorithms,” revised processes to speed validation of cryptographic modules, and the start of a NIST pilot that must finish by December 31, 2027. CISA’s public guidance on minimum elements for a cryptographic bill of materials, and a second FAR rule on vulnerability disclosure that is to cover cryptographic vulnerabilities, are due 270 days out, on March 19, 2027.

What to do with it

1. For transition planning, stop sorting the inventory by 112-bit versus 128-bit strength. RSA, ECDSA, EdDSA, finite-field Diffie-Hellman and elliptic-curve Diffie-Hellman now share the same two dates in NIST’s tables.
2. Mark which systems are in the order’s scope, or serve agencies that are. For those the dates are the end of 2030 for key establishment and the end of 2031 for signatures, and the FAR rule due around December 19 may turn 2030 into a contract term.
3. Track authentication on its own line. The handshakes show that hybrid key exchange is the part already working in the field and that certificates are the part with no deployment to lean on. Merkle Tree Certificates are one route; our tutorial on building a certificate issuer walks through the size trade-offs.
4. Decide on hybrids deliberately. The report leaves it to each application and OMB asks for an evaluation. If FIPS-validated modules matter to you, the IETF draft’s ordering note tells you which implementation has to be certified for each group. Our hybrid key-exchange tutorial shows how the two secrets are combined.
5. Watch the documents that will carry the rules: SP 800-131A Revision 3, the SP 800-56C revision, the next SP 800-52, and the order’s December 19 and March 19 deliverables. Re-run the handshake check above against your own hostnames before and after any CDN or load balancer change.

Related reading

• Cloudflare’s Post-Quantum Visibility Turns Quantum Readiness Into a Per-Hop Audit, which used the draft’s tables and the order’s two clocks.
• Cloudflare’s Post-Quantum GeoKey Manager Swaps Attribute Policies for a Catalog of Regional Root Keys, on HPKE and X-Wing key wrapping.
• Post-Quantum Cryptography in Python: A Safe Adoption Checklist.
• Red Hat’s RHEL 10 Turns Post-Quantum Migration Into a Financial Services Deadline.

Sources

• NIST, NIST IR 8547, Transition to Post-Quantum Cryptography Standards (final, October 2026), and the withdrawn initial public draft (November 2024).
• NIST, news release of October 27, 2026.
• Federal Register, Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks (June 25, 2026).
• OMB, Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography (June 24, 2026).
• IETF, draft-ietf-tls-ecdhe-mlkem, Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, revision 05.
• NIST CSRC, SP 800-131A Rev. 2, SP 800-56C Rev. 2 and SP 800-52 Rev. 2 pages, read on October 28, 2026.