On October 27, NIST published the final version of IR 8547, Transition to Post-Quantum Cryptography Standards. If you followed the draft from November 2024, you might think you know what it says. You probably don't, because the final version changed the one thing that mattered most.
The draft deprecated only the 112-bit parameter sets after 2030. That left a comfortable reading: RSA-3072, P-256 ECDSA, and Ed25519 looked acceptable until 2035. The final report closes that door. Every approved quantum-vulnerable public-key algorithm is deprecated after 2030 and disallowed under NIST standards and guidelines after 2035, regardless of key size.
That is not a small edit. It moves the algorithms most products actually ship today into the deprecation category, with just over four years on the clock.
What the schedule actually says
For signatures, RSA, ECDSA, and EdDSA are all deprecated after 2030 and disallowed after 2035. For key establishment, finite-field Diffie-Hellman, elliptic-curve Diffie-Hellman, MQV, and RSA key transport get the same treatment. The dates are the same as the draft. The scope is much wider.
"Deprecated" in NIST usage does not mean banned. It means the algorithm may still be used, but there is a security risk, and the data owner has to examine that risk and decide whether to continue. In practice, that turns into a documented risk-acceptance obligation. For federal high-value assets and high-impact systems, the grace period is shorter than it looks: an executive order from June 2026 requires post-quantum key establishment by December 31, 2030, and post-quantum signatures by December 31, 2031. Those systems do not get until 2035. They get 2030 and 2031.
And the report does not stop at federal systems. NIST explicitly positions it as a blueprint for critical infrastructure and other organizations. The deadlines reach private vendors through procurement, not through NIST directly.
How a government report becomes your vendor requirement
NIST IR 8547 is not binding on private companies. It reaches them through five mechanisms, and together they explain why this report functions as a vendor requirement in practice.
First, the executive order directs the FAR Council to propose a rule requiring covered contractors to comply with NIST's post-quantum FIPS by December 31, 2030. That proposed rule is due around December 19, 2026, under a 180-day clock. Second, OMB Memorandum M-26-15, issued in June 2026, tells agencies to build post-quantum integration into product requirements and to settle post-quantum responsibilities with FedRAMP cloud providers. Agencies owed their migration plans by October 22, 2026. Third, CISA published a list of product categories back in January 2026, from web browsers to endpoint encryption, where agencies "should acquire only PQC-capable products." Fourth, NIST is revising its module validation processes to move faster. Fifth, CISA owes minimum elements for a cryptographic bill of materials by around March 19, 2027.
If you sell software, cloud services, or hardware into any of those categories, expect to be evaluated on post-quantum capability in federal acquisitions now, not after the FAR rule lands. And vendors are unlikely to keep separate federal and commercial cryptographic baselines for long. One baseline wins, and it will be the post-quantum one.
A Government Accountability Office report from October found that none of the 24 agencies it reviewed had fully addressed all three preparatory practices: building a cryptographic inventory, identifying funding, and planning testing. The people with the biggest budgets and the clearest mandate are behind. That should tell smaller teams something: this is not a task you start in 2029.
The hybrid question finally has an answer
For builders, the most useful clarification in the final report is about hybrid key establishment, the approach that pairs ML-KEM with a classical exchange like X25519. Until now, it was unclear how such constructions would fare in FIPS 140 validation once the classical half became deprecated or disallowed. The final report answers it: as long as at least one input to an approved composite key-establishment technique comes from an approved scheme, the combination can be validated. A hybrid mode does not lose its validation status because its classical half ages out.
That removes the last respectable excuse to wait. You can ship hybrid now without painting yourself into a validation corner later.
Two cautions, though. A validated module that supports hybrid ML-KEM does not prove that a given deployment actually negotiates it. Capability and enablement are different things, and buyers should check which one they are getting. And on hybrid signatures, NIST is more careful: it will accommodate dual signatures in validation but notes that their security properties are complex and need careful analysis. Signatures are the slower, more operationally disruptive half of this transition. They touch certificate authorities, firmware signing, hardware security modules, and smart cards, and none of those move quickly.
NIST also named ML-KEM-768 as its recommended default parameter set, calling it a large security margin at a reasonable performance cost, and said it has no current plans to standardize additional KEMs beyond HQC. If you are picking a parameter set today and want the choice least likely to be second-guessed, that is the one.
What I would do this quarter
I build a small end-to-end encrypted messenger, and I went through this migration myself: ML-KEM-768 for key establishment and ML-DSA-65 for identity signatures, replacing a classical design. The protocol part was not the hard part. The hard part was everything around it: key storage, migration paths for existing sessions, and making sure a new key type did not silently break an old client. That experience shapes how I read this report, and it is why I think the practical checklist matters more than the dates.
First, make a cryptographic inventory. You cannot migrate what you cannot list. Walk your codebase and your infrastructure and write down every place a public key is generated, exchanged, stored, or verified. Include the boring ones: TLS certificates, code signing, backup encryption, JWT signing keys, SSH host keys. The inventory is the part the GAO found agencies missing, and it is the part most small teams skip.
Second, put ML-KEM-768 behind a flag in your key establishment path, hybrid with your existing classical exchange, and turn it on where you control both ends. Do not wait for a perfect migration plan. The hybrid validation answer means this step is safe to take now.
Third, design for crypto-agility from the start. The algorithm you pick today will not be the last one you ship. If swapping a KEM or a signature scheme requires touching twenty files and a database migration, fix that structure before you fix the algorithm. A clean seam between "what key type" and "what the protocol does with it" is worth more than picking the perfect parameter set.
Fourth, treat signatures as a separate, longer project. Key establishment can go hybrid quickly. Signatures touch trust roots, and trust roots move slowly. Start the inventory for signatures now, even if the migration itself takes years.
Fifth, watch two dates that are closer than 2030: the FAR proposed rule around December 19, 2026, and the CISA bill-of-materials elements around March 19, 2027. If you sell to anyone who sells to the government, those will show up in your contracts and questionnaires before the 2030 deadline does.
The deadline stopped being a draft
For two years, the post-quantum transition had the feel of a long-range plan: real standards, vague dates, and plenty of room to say "we will get to it." The final IR 8547 changes the texture of it. The dates are now attached to procurement rules, validation processes, and contract clauses. The deprecation scope now covers the strong classical defaults, not just the weak ones. And the agencies that were supposed to be ready first have, by the GAO's account, not finished their homework.
None of this means a quantum computer is about to break RSA next week. It means the paperwork, the procurement, and the product roadmaps have caught up with the standards. If your plan still says RSA-3072 and P-256 are fine until 2035, that plan is out of date as of October 27. Rewrite it now, while rewriting it is still cheap.
Sources: NIST IR 8547 (Final, October 2026); OMB Memorandum M-26-15 (June 2026); Executive Order 14412 (June 2026); GAO-27-108740 (October 2026); Cloud Security Alliance research note on IR 8547 (October 30, 2026).
Top comments (0)