OMB M-26-15 Federal PQC Migration Guide

OMB Memorandum M-26-15 turns the US federal post-quantum cryptography policy into an execution plan. It requires covered executive departments and agencies to submit a PQC Migration Plan to the Office of Management and Budget and the Office of the National Cyber Director within 120 days of June 24, 2026. It also sets a risk-based, multi-year migration sequence through 2035.

The memorandum does not apply to national security systems. It is also not a universal private-sector compliance deadline. Contractors and technology suppliers should track related acquisition requirements separately rather than assuming that every M-26-15 agency deadline applies directly to them.

This guide explains the memo’s operational requirements. Teams building the underlying program can use the PQC migration plan template, cryptographic inventory guide, and vendor questionnaire to turn the policy into owned work.

M-26-15 at a glance

Requirement	Scope or timing	Practical meaning
Submit an agency PQC Migration Plan	Within 120 days of June 24, 2026	Deliver the initial plan to OMB and ONCD, then maintain it as a living document
Prioritize quantum risk	High impact systems, High Value Assets, highly sensitive data, and other particularly vulnerable systems	Do not schedule migration only by convenience or product refresh date
Mitigate as much quantum risk as feasible	By December 31, 2030	Integrate prioritized migration into governance, budgets, cloud moves, software lifecycles, and hardware refreshes
Complete prioritized key-establishment migration	2028 through 2030 phase	Move identified priority systems to PQC for key establishment and make systems cryptographically agile
Complete prioritized signature migration	2031 phase	Migrate digital signatures for the same priority classes and preserve crypto agility
Complete remaining migration	By 2035	Finish the risk-based migration as standards and commercial products permit
Support TLS 1.3 or a successor	As soon as practicable, no later than January 2, 2030	Treat the protocol baseline as an enabling dependency, not proof that PQC is deployed

The 120-day submission deadline is a date calculation from the memorandum, not a separate date printed in it. Agencies should confirm the official submission calendar and handling instructions with OMB rather than relying on an informal countdown.

Who is in scope

M-26-15 is addressed to the heads of executive departments and agencies. It explicitly excludes national security systems as defined in 44 U.S.C. 3552(b)(6). Those systems follow separate national security policy and technical profiles.

The memo still matters beyond agency-owned infrastructure because it addresses:

products in categories that use post-quantum cryptography standards;
FedRAMP-authorized cloud services;
shared SaaS, PaaS, and IaaS used across agencies;
third-party migration responsibilities under the cloud shared-responsibility model;
supply-chain and procurement requirements;
systems that cannot support PQC or hybrid cryptography and may require replacement.

That creates planning pressure for vendors, but it does not make every supplier independently subject to every agency action in the memo. Contract clauses, procurement rules, system boundaries, and agency direction determine a supplier’s enforceable obligations.

The five migration phases

Phase 1: strategy, planning, and discovery, 2026 to 2027

Agencies should inventory cryptography, identify HVAs and high impact systems, assess risk, establish governance, assign accountable officials, and prepare training and migration plans. This is more than a certificate list. A useful inventory separates key establishment, signatures, identity, code signing, data protection, and device trust.

Automation is a central expectation. M-26-15 points to software composition analysis, static and dynamic application security testing, network scanners, and a central Cryptographic Bill of Materials as examples. The CBOM guide and template explains how to retain ownership, evidence, and dependency information rather than collecting algorithm names without context.

Phase 2: pilots and early migration, 2027 to 2028

Agencies should run pilots on prioritized systems, execute early migrations, and revise the plan using real interoperability and operational evidence. A pilot must record the exact protocol, algorithm or hybrid construction, library and version, peer compatibility, failure behavior, rollback path, and measured overhead.

Hybrid cryptography may support transition, but the memo describes it as a complex and resource-intensive stopgap that needs a deliberate tradeoff analysis. The hybrid cryptography guide covers those boundaries.

Phase 3: prioritized migration, 2028 to 2030

The memo calls for PQC key establishment across HVAs, high impact systems, systems with highly sensitive data, and systems judged particularly vulnerable to attacks using a cryptographically relevant quantum computer. It also calls for all systems to be cryptographically agile.

Key establishment is only one cryptographic function. A service using a hybrid TLS key exchange can still rely on classical certificate signatures, code-signing keys, tokens, device identities, and stored key-wrapping mechanisms. Status reporting should remain capability-specific.

Phase 4: signature migration, 2031

The same priority groups move to PQC digital signatures. This phase can depend on certificate authorities, hardware security modules, trust stores, firmware, relying parties, and protocol standards. A plan should distinguish a laboratory implementation from a production-capable and validated supply chain.

Phase 5: full migration, by 2035

The final phase covers remaining systems, based on risk assessments and the availability of commercial offerings. The date is not permission to postpone discovery. Systems that cannot support PQC or hybrid cryptography must be identified early enough to coordinate replacement, modernization, procurement, and funding.

What the initial migration plan must contain

Appendix B of M-26-15 defines the minimum plan content:

A system prioritization strategy with a risk-based justification.
Timelines and milestones for the migration phases.
Testing and deployment milestones for the TLS 1.3 deadline.
The methods and automated tools used for cryptographic inventory.
A plan for cryptographically agile architecture.
A third-party coordination plan.
Estimated funding and personnel requirements.
A migration-period risk management strategy.
Defined governance roles and responsibilities.

The plan should identify who can approve a target construction, accept residual risk, authorize deployment, and trigger rollback. M-26-15 assigns responsibilities across the CIO and CISO, program and requirement owners, CFO, migration lead, technical lead, security architect, and system owners. A single security-team spreadsheet does not satisfy that governance model.

A practical M-26-15 implementation sequence

1. Establish the governance record

Name the accountable roles, decision rights, funding owner, reporting cadence, and exception process. Connect each system record to both a technical owner and a mission or business owner.

2. Build a dynamic cryptographic inventory

Record the cryptographic function, current algorithm, key location, data lifetime, exposure, dependencies, supplier, target state, and evidence. Reconcile automated discovery with owner attestation because neither source is complete alone.

3. Apply the memo’s priority test

Flag high impact systems, HVAs, highly sensitive information, data that remains mission-sensitive in 2030, and access-control systems that depend on vulnerable asymmetric cryptography. Add a documented agency risk decision for other systems exposed to harvest-now-decrypt-later or impersonation risk.

4. Map modernization and supplier dependencies

Align PQC work with cloud migration, software development, identity modernization, network refreshes, and hardware replacement. Ask suppliers for capability-level evidence with the PQC vendor questionnaire. A broad statement that a product is “quantum safe” is not enough.

5. Define pilots and exit criteria

For every pilot, specify interoperability, performance, security, fallback, logging, monitoring, rollback, and acceptance criteria. Record whether the test covers key establishment, signatures, or both.

6. Build continuous evidence

Feed inventory and policy results into reporting dashboards where feasible. Track coverage, exceptions, blockers, outdated dependencies, and verified deployments. A continuously updated inventory is explicitly favored over a one-time discovery exercise.

Standards and algorithm boundaries

M-26-15 identifies FIPS 203 ML-KEM for key establishment, FIPS 204 ML-DSA for digital signatures, and FIPS 205 SLH-DSA as a hash-based signature option. These are final NIST standards. The memo also says plans must align with NIST IR 8547 or its successor, but as of September 11, 2026, NIST still labels IR 8547 an initial public draft.

Do not treat every algorithm mentioned as equally mature or approved for every use. Implementation decisions depend on the applicable standard, validated module availability, protocol profile, agency policy, interoperability, and system risk. The NIST PQC standards guide explains the roles of the three finalized standards.

The memorandum also encourages agencies to treat asymmetric algorithms as quantum-vulnerable unless they are definitively known to be quantum-resistant. That is an inventory and risk instruction, not a license to replace algorithms with unstandardized alternatives.

Common reporting mistakes

Calling TLS 1.3 quantum-safe. TLS 1.3 is an enabling protocol baseline. It does not prove that a PQC or hybrid key exchange was negotiated, and it says nothing by itself about certificate signatures.

Reporting a product instead of a capability. A provider may support PQC in one endpoint but not in its identity, key management, signing, or private-network services.

Treating internal links or vendor roadmaps as evidence. Migration status should cite a configuration, test result, validated product, contract commitment, or dated primary documentation.

Using the 2035 date as the first milestone. Inventory, planning, priority decisions, supplier coordination, and pilots are earlier phases. Waiting removes the opportunity to combine migration with scheduled modernization.

Applying the memo universally. M-26-15 excludes national security systems and does not itself impose every agency deadline on private organizations. Record the legal, contractual, or policy basis for each deadline.

FAQ

What is OMB M-26-15?

It is the June 24, 2026 OMB memorandum titled “Execution of the Migration to Post-Quantum Cryptography.” It directs covered federal agencies to plan and execute a prioritized PQC migration.

When is the M-26-15 migration plan due?

The memorandum requires submission to OMB and ONCD within 120 days of June 24, 2026. Agencies should verify the official administrative deadline and submission process with OMB.

Does M-26-15 apply to national security systems?

No. The memorandum explicitly excludes national security systems. Separate national security requirements may still apply.

Does every federal system have to complete migration by 2030?

No. The 2028 to 2030 phase prioritizes key establishment for HVAs, high impact systems, highly sensitive systems, and other systems judged particularly vulnerable. Signature migration follows in 2031, while the final risk-based migration of remaining systems extends to 2035.

Is a cryptographic inventory enough to comply?

No. The initial plan also needs risk-based priorities, milestones, TLS 1.3 testing and deployment plans, crypto-agility architecture, third-party coordination, resources, risk management, and governance roles.