US federal agencies owed OMB and the National Cyber Director a post-quantum migration plan on 22 October, and the NCSC has just told UK organisations which key exchanges to use. The cryptography is largely settled. The hard part is finding everywhere you use the old kind.
A deadline that has just passed
On 24 June 2026 the Office of Management and Budget issued memorandum M-26-15, signed by OMB Director Russell T. Vought, on executing the migration to post-quantum cryptography (PQC). It gives agencies 120 days to submit a migration plan. Day 120 is 22 October 2026.
The memo’s objective is “mitigating as much quantum risk as feasible by December 31, 2030”, and it lays out five phases:
| Phase | Years | What happens |
|---|---|---|
| 1. Strategy, planning and discovery | 2026 to 2027 | Inventory and planning |
| 2. Pilots and early migration | 2027 to 2028 | First deployments |
| 3. Prioritised migration | 2028 to 2030 | PQC key establishment for high-value and high-impact systems |
| 4. Signature migration | 2031 | PQC digital signatures for the same systems |
| 5. Full migration | 2035 | Everything else |
It also requires agencies, consistent with Executive Order 14306, to support TLS 1.3 or a successor “as soon as practicable, but not later than January 2, 2030”, and to align plans with NIST IR 8547. The memo’s reasoning is worth quoting: “TLS 1.3 is foundational for deploying PQC at the network level.”
The UK picture
The NCSC’s migration timelines use three milestones, 2028, 2031 and 2035: define goals, discover what you have and build an initial plan by 2028; finish the early, highest-priority migration by 2031; complete migration by 2035. The US and UK dates line up closely, which is convenient for anyone who sells to both governments.
On 15 October the NCSC published version 1.2 of its guidance on using TLS, with an accompanying blog post. The post is blunt about the old protocol versions: “TLS 1.3 is the only version that supports PQC; earlier versions will not be upgraded.”
The updated guidance recommends the hybrids X25519MLKEM768 or SecP256r1MLKEM768, or pure MLKEM768, and also rates SecP384r1MLKEM1024 and MLKEM1024 acceptable. For authentication it keeps ECDSA P-256 and RSA 2048 for now. Partly that is because post-quantum authentication standards for TLS aren’t finished, and partly it is priorities. Key exchange is what protects recorded traffic from future decryption, the “harvest now, decrypt later” problem. Signatures only need to resist a quantum computer at the moment they are checked, so they can wait.
What this means in practice
Most of the work has nothing to do with lattices. Browsers already offer hybrid key exchange: the deployment table at tldr.fail lists Chrome from version 124 on desktop and Safari from iOS 26. If your CDN or web servers support it too, some of your public web traffic is already protected, whether or not you planned it. The problems are elsewhere:
- Anything stuck on TLS 1.2. Load balancers, appliances, mainframe gateways, payment links, industrial kit. If it can’t do TLS 1.3, it can’t do PQC, and the NCSC says TLS 1.2 itself won’t be upgraded.
- Middleboxes. Hybrid key shares make the TLS ClientHello too big for one packet, and tldr.fail keeps a list of servers and middleboxes that reset the connection instead of reading the rest. Test before you enable it across the estate, and ask your vendors.
- Things you didn’t know used cryptography. VPNs, SSH, code signing, internal PKI, hardware security modules, and every vendor product with its own TLS stack.
- Long-lived data. If what you send today still matters in 2035, it’s at risk today, not in 2035.
What to do
- Start the inventory now. Both governments put discovery first. You can’t migrate what you haven’t found, and the inventory always takes longer than the migration.
- Make TLS 1.3 the floor on anything you control, and list the systems that can’t meet it, with an owner and a date.
- Enable hybrid key exchange where your libraries support it, using the NCSC’s named groups, and test against your middleboxes first.
- Leave certificates alone for now. The NCSC keeps classical authentication, and the US signature phase is 2031.
- Ask your suppliers for their PQC roadmap in writing. The ones without an answer are your 2030 problem.
For the UK legislative backdrop, see our piece on the Cyber Security and Resilience Bill at Lords Report stage.
Sources
- OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography (24 June 2026, PDF)
- NCSC: Timelines for migration to post-quantum cryptography
- NCSC: Using TLS to protect data (version 1.2, 15 October 2026)
- NCSC blog: Post-quantum updates to our TLS guidance (15 October 2026)
- tldr.fail: post-quantum ClientHello compatibility and deployment
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards