Borrowing the Federal Playbook: How to Write a Post-Quantum Migration Plan

Key ManagementOctober 22, 2026

US agencies' post-quantum migration plans are due today under OMB M-26-15. The memo is the clearest public template yet for what a credible plan contains, and any organisation can borrow it. Here is what it asks for and where to start.

Abstract navy illustration of stacked translucent panels shifting from teal to blue, topped by two interlocking rings, suggesting layered classical and post-quantum encryption

Today, 22 October 2026, is the day US federal civilian agencies must hand their post-quantum migration plans to the White House. OMB Memorandum M-26-15, issued on 24 June, gave each agency 120 days to submit a "PQC Migration Plan" to OMB and the Office of the National Cyber Director. It implements Executive Order 14412, signed two days earlier.

Most organisations reading this are not US agencies, and the memo does not bind them. It is still worth reading closely. It is the most concrete public description yet of what a credible post-quantum plan contains, who owns which part, and in what order the work should happen. If your board or a large customer asks "where is our quantum plan?", this is a reasonable template to borrow.

What the memo actually requires

The core objective is a prioritised migration that mitigates "as much quantum risk as feasible" by 31 December 2030. The executive order sets the hard dates for high value assets and high impact systems: quantum-safe key establishment by 31 December 2030 and digital signatures by 31 December 2031. The order also asks the FAR Council to require covered federal contractors to comply with NIST FIPS standards, including PQC algorithms, by the end of 2030.

The memo then lays out five phases:

Strategy, planning and discovery (2026–2027): inventory, risk assessment, governance and named accountable officials.
Pilots and early migration (2027–2028): test on prioritised systems and refine the plan.
Prioritised migration (2028–2030): move key establishment to PQC for the highest-risk systems.
Signature migration (2031): move digital signatures to PQC for the same systems.
Full migration (2035): finish the remaining systems, based on risk and commercial availability.

Plans must align with NIST IR 8547, which is still an initial public draft. Its proposed transition tables mark quantum-vulnerable algorithms such as RSA and ECDSA at 112-bit strength as deprecated after 2030, and all of them as disallowed after 2035.

Why key establishment comes first

The ordering is deliberate. Encrypted traffic recorded today can be stored and decrypted later, once a cryptographically relevant quantum computer exists. A forged signature, by contrast, only matters at the moment someone checks it. So confidentiality of long-lived data is the more urgent exposure, and the memo tells agencies to prioritise systems with data "expected to remain mission-sensitive in 2030".

In practice, the first wave is mostly about key exchange in TLS and VPNs. The memo's technical appendix requires TLS 1.3 support by 2 January 2030 and describes the hybrid approach: the client sends both a classical key share (such as X25519) and an ML-KEM-768 share, and the two secrets are combined before key derivation. An attacker then has to break both schemes.

The memo is candid that hybrid designs are "an intricate and resource-intensive stopgap" rather than an end state. That is a useful corrective to vendor messaging that treats a hybrid toggle as the whole job.

What a plan must contain

Appendix B of the memo lists the minimum sections. Stripped of federal vocabulary, they translate well to any organisation:

a system prioritisation strategy, with a risk-based justification;
timelines and milestones for each migration phase, including the TLS 1.3 deadline;
the methods and automated tools used for the cryptographic inventory;
a plan for a crypto-agile architecture;
a third-party coordination plan;
an estimate of funding and staff;
a risk management strategy for the migration period;
governance roles and responsibilities.

Two items deserve emphasis. First, the memo says plainly that migration "is not only the responsibility" of the CIO and CISO, and it gives the finance office a named role in budgeting. Second, it treats third parties as a first-class part of the plan, not an appendix.

Inventory and agility are the real work

The memo states that manual approaches to discovering and managing cryptography "are often insufficient". It points to automation: software composition analysis over SBOMs, static and dynamic testing to find cryptographic calls in code, and network scanning for protocols and cipher suites. The results should feed a central cryptographic bill of materials (CBOM) that stays current.

On agility, the guidance is specific and practical:

Use libraries built for swapping algorithms, such as provider-based architectures, rather than hard-coding them.
Drive algorithm choice from configuration, so it can change without a new software release.
Negotiate capabilities in protocols, while making sure endpoints can be restricted to acceptable algorithms to prevent downgrade.
Make key management agile too. Your KMS and HSMs must be able to generate, store and manage both classical and PQC keys.

NIST's paper on considerations for achieving cryptographic agility covers the same ground in more depth and is a good companion read for architects.

Use the supplier lists when you buy

The memo directs agencies to CISA's product categories for technologies that use PQC standards. CISA divides categories into those where PQC is widely available, including cloud platforms, browsers and web servers, and full disk encryption, and those still in transition, such as identity and access management, databases, networking and SaaS.

For widely available categories, CISA says buyers should plan to acquire only PQC-capable products. It also notes that most of these support PQC for key establishment but not yet for signatures, so "PQC-capable" does not mean fully quantum resistant. That nuance belongs in your procurement questions.

A checklist you can start this week

You do not need a federal mandate to take the first useful steps:

Name an owner. One accountable migration lead, with a sponsor outside the security team and a line to finance.
Start the inventory with what faces the outside world. Scan TLS and VPN endpoints for protocol versions and key exchange groups, and record which already negotiate hybrid ML-KEM.
List data that must stay confidential past 2030. Those systems go first.
Find the places you cannot change. Hard-coded algorithms, embedded devices and unsupported products go on a replace-or-retire list now, aligned to existing refresh cycles.
Ask your key management stack the hard questions. Can your KMS, HSMs and certificate tooling hold PQC keys, and is algorithm selection a configuration change?
Add PQC to contracts. Ask suppliers for their roadmap for key establishment and signatures separately, and for how they will support crypto agility.
Write it down as a living plan. Use the plan sections above as headings, and expect to revise it yearly.

The same questions apply to whichever key management service you rely on, including our own OXU KMS: where algorithm choices live, and how keys of a new type would be introduced without disruption.

Conclusion

M-26-15 does not invent new cryptography. Its value is in making the migration ordinary: a governed programme with an inventory, a priority list, supplier commitments and a budget line. Organisations outside the US federal government can borrow that structure today. Start with key establishment for long-lived data, make your cryptography and key management configurable, and treat your first plan as version one.