Post-Quantum Cryptography Migration Plan

Approval #

Revision History #

Review cycle: Every year with the cryptographic inventory, and when federal guidance on post-quantum cryptography changes.

Mandate. The Office of Management and Budget (OMB) issued M-26-15, Execution of the Migration to Post-Quantum Cryptography, on June 24, 2026. It requires each agency to send a Post-Quantum Cryptography (PQC) Migration Plan to OMB and the Office of the National Cyber Director (ONCD) within 120 days, by October 22, 2026. Executive Order (EO) 14412, Securing the Nation Against Advanced Cryptographic Attacks, signed June 22, 2026, sets fixed dates for High Value Assets (HVAs) and high-impact systems. OMB M-23-02 still requires the annual cryptographic inventory that this plan draws on. EO 14306 sets the deadline for Transport Layer Security (TLS) 1.3.

1. Purpose and Scope #

This document is the Organization’s PQC Migration Plan. The CISO sends it to OMB and ONCD at PQC@omb.eop.gov.

A large enough quantum computer would break the public-key algorithms that the Organization uses today to set up encrypted connections and to create digital signatures. An attacker can record encrypted traffic now and decrypt it once such a computer exists. In this plan, the CISO sets the order in which the Organization replaces those algorithms, names who does the work, and states the dates the Organization will meet.

The plan covers every information system that the Organization owns or operates. That includes systems that contractors and cloud service providers run for it, and its public websites. OMB M-26-15 does not apply to national security systems, and this plan does not cover them.

OMB M-26-15 Action One also sets an agency-wide goal: mitigate as much quantum risk as feasible in every system by December 31, 2030. The tiers and milestones in this plan put the riskiest systems first so the Organization can meet that goal. OMB expects agencies to change their plans as the work matures. The CISO updates this plan every year with the cryptographic inventory that OMB M-23-02 requires.

2. Requirements This Plan Meets #

The table below shows each federal requirement and the part of this plan that meets it.

3. Governance Roles and Responsibilities #

The Organization adds PQC migration to its existing risk governance and does not create a separate board. The Chief Information Officer (CIO) names the people who fill the PQC roles in a signed memorandum, the Post-Quantum Cryptography Roles Designation Memorandum. The CISO keeps it with this plan in the policy library in the document management system.

EO 14412 required each agency head to name a PQC migration lead to OMB and ONCD within 30 days of June 22, 2026, which was July 22, 2026. Before submission, the CISO records the date the Organization sent that notice: [date sent].

4. Current State #

The Organization’s documents cover the High baseline of Federal Information Processing Standards (FIPS) 199. That choice sets which controls the documents cover; it does not show whether any system is high-impact. Before submission, the CISO lists each high-impact system in the table below, or writes None. The Organization has one or more HVAs under OMB M-19-03. Before submission, the CISO lists each HVA in the table below. EO 14412 sets two dates for every HVA and every high-impact system: PQC key establishment by December 31, 2030, and PQC digital signatures by December 31, 2031.

Many agency services run in cloud services that the Federal Risk and Authorization Management Program (FedRAMP) has authorized. For these services, the provider runs most of the cryptography. The Organization’s migration therefore depends on each provider’s own PQC schedule. Before submission, the CISO lists each FedRAMP cloud service the Organization uses in the appendix FedRAMP Cloud Services Used by the Organization, with an initial priority tier.

Before submission, the PQC Technical Lead tests each public website the Organization runs and records the results:

Some test tools cannot check for hybrid post-quantum key exchange. In that case, the PQC Technical Lead tests again with a tool that supports ML-KEM, the NIST post-quantum key exchange algorithm.

5. System Prioritization Strategy #

The CISO places every system in one of three priority tiers. The CISO applies the same criteria to every system, so the CISO can explain the order to OMB and to an assessor.

Within Tier 1, HVAs and high-impact systems come first, because EO 14412 sets fixed dates for them. System Owners confirm these initial Tier 1 assignments during the inventory:

When a system cannot support PQC or hybrid cryptography, the CISO marks it for replacement or retirement instead of migration. The CIO decides on each such system, and the ISSO records the decision in the system’s SSPP.

6. Migration Phases, Timelines, and Milestones #

The Organization follows the five phases in OMB M-26-15 and the dates in EO 14412. It also follows the schedule in NIST IR 8547 (initial public draft), under which NIST plans to deprecate the quantum-vulnerable algorithms in 2030 and disallow them in 2035. NIST has not made that draft final, so the CISO checks the schedule again when it does.

EO 14413, Ushering in the Next Frontier of Quantum Innovation (June 22, 2026), sets no task for the Organization’s own systems. It directs national security agencies to assess what larger commercial quantum computers mean for the migration to PQC. The CISO reviews this plan if that assessment changes the federal dates.

Phase 1: Strategy, planning, and discovery (2026 to 2027) #

Phase 2: Pilots and early migration (2027 to 2028) #

Phase 3: Prioritized migration of key establishment (2028 to 2030) #

Phase 4: Signature migration (2031) #

Phase 5: Full migration (by 2035) #

System Owners set dates for their own systems inside each phase. The ISSO records those dates in the GRC system.

7. TLS 1.3 Testing and Deployment #

EO 14306 and OMB M-26-15 require the Organization to support TLS 1.3 or a successor version as soon as practicable, and no later than January 2, 2030. TLS 1.3 is also the protocol the Organization uses to add hybrid post-quantum key exchange.

For a public website that already supports TLS 1.3, two steps remain. The System Owner adds hybrid key exchange in Phase 2, and a post-quantum certificate in Phase 4 once certificate authorities offer one.

8. Cryptographic Inventory Methods and Tools #

Each year the Organization sends ONCD and CISA an inventory of systems that use quantum-vulnerable cryptography, as OMB M-23-02 requires. The appendix Cryptographic Inventory Fields shows what each entry must include. The PQC Technical Lead uses automated tools first, as the CISA strategy for automated PQC discovery and inventory tools advises. The PQC Technical Lead records by hand only what the tools cannot see.

The PQC Technical Lead combines these results into a cryptographic bill of materials (CBOM) for each system. CISA and NIST will publish the minimum elements of a CBOM, as EO 14412 directs. When they do, the PQC Technical Lead updates the Organization’s CBOM format to match. The ISSO attaches each system’s CBOM to its SSPP, and the PQC Migration Lead builds the annual submission from these records.

The PQC Technical Lead sends scan results to a continuous monitoring dashboard in the security information and event management (SIEM) system. The CIO and CISO use the dashboard to track migration progress against the dates in this plan.

9. Cryptographic Agility #

Cryptographic agility means the Organization can change an algorithm by changing a setting and rotating keys, without rebuilding the system. System Owners must make every new or modernized system meet these rules:

• Use cryptographic modules that hold an active FIPS 140-3 validation.
• Use the NIST post-quantum algorithms: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for digital signatures. Use at least the ML-KEM-768 parameter set.
• Set algorithm choices in configuration files, not in compiled code.
• Use current libraries that support new algorithms through configuration, such as OpenSSL 3 or later.
• Configure protocols to accept only approved algorithms, so an attacker cannot force a weaker one.
• Make sure the key management service and any hardware security modules support both classical and PQC key types.
• Include PQC upgrades in planned cloud migrations, software releases, and hardware refreshes.

The PQC Migration Lead runs cryptographic agility as a repeating cycle, as NIST Cybersecurity White Paper (CSWP) 39-upd1 describes. Each year the PQC Migration Lead:

1. Confirms the cryptographic standards and mandates that apply, and tells System Owners, developers, and vendors what they require.
2. Updates the cryptographic inventory, starting with the systems that hold the most critical data.
3. Finds gaps in the asset, configuration, vulnerability, and logging tools, and adds automated discovery of algorithms and key lengths where the tools lack it.
4. Ranks the assets to fix, by risk and by the cost and effort of each change.
5. Tracks the changes to completion. Where a system cannot change its algorithms, the System Owner adds compensating controls, such as a cryptographic gateway in front of a legacy system, and records them in the SSPP.

The Security Architect writes the Organization’s cryptographic policy, the approved and disallowed algorithms and key sizes, as a configuration profile that tools can enforce and scan against. Before an algorithm is retired, the System Owner plans how to handle data already encrypted under it and documents already signed with it. (NIST CSWP 39-upd1)

Hybrid cryptography combines a classical algorithm with a PQC algorithm. The Organization uses it where the System Owner’s risk assessment supports it, for example on public web connections during Phases 2 and 3. Every algorithm change goes through change management in the ticketing system.

Zero trust architecture #

OMB M-26-15 requires PQC in each part of a zero trust architecture. System Owners apply these rules as each system migrates:

• Devices. System Owners move device attestation, such as the Trusted Platform Module checks that the mobile device management (MDM) tool relies on, to PQC algorithms as vendors support them.
• Networks. System Owners configure every device or service that ends TLS or IPsec sessions to support PQC key exchange with NIST algorithms. This includes firewalls, virtual private network (VPN) concentrators, cloud gateways, the secure web gateway, and application programming interface (API) gateways.
• Applications. System Owners configure API gateways and applications to issue and accept PQC-signed tokens as vendors support them. Developers use PQC-agile libraries in every new application.
• Data. System Owners find long-lived sensitive data and encrypt it again under keys that PQC protects. The PQC Technical Lead confirms that data loss prevention (DLP) tools still inspect PQC-protected traffic.

10. Third-Party Coordination #

• Cloud providers. By March 31, 2027, the PQC Migration Lead asks each FedRAMP provider in the appendix FedRAMP Cloud Services Used by the Organization for its PQC schedule. The PQC Migration Lead also asks each provider for a clear split of PQC duties under the shared responsibility model. The ISSO records the split in the SSPP. CISA and the Department of War, with GSA, lead PQC work for FedRAMP services that more than one agency uses. The Organization follows that work and does not repeat it.
• New purchases. Program offices use the CISA list Product Categories for Technologies That Use Post-Quantum Cryptography Standards. When a purchase falls in a listed category, the program office includes PQC support in the requirement. The CO and COR put the requirement in the contract.
• Cryptographic components. For each product that uses cryptography, the program office asks the vendor for a list of its cryptographic components (algorithms, protocols, libraries, and certificates) and whether each can be updated without replacing the product. (NIST CSWP 39-upd1)
• Renewals. At each renewal, the COR asks the vendor for its PQC plan. A vendor with no plan is a supply chain risk, and the ISSO records it in the system’s risk assessment.
• Identity and physical access. Program offices buy physical access control products only from the GSA FIPS 201 Approved Products List. The PQC Migration Lead works with the GSA FICAM office on PQC-ready PIV credentials.
• Website hosts. For each public website, the PQC Migration Lead confirms when its hosting provider and its certificate authority will support hybrid key exchange and post-quantum certificates.

11. Funding and Personnel Estimate #

The Organization pays for most of this work through planned refresh cycles and existing cloud subscriptions, because providers add PQC to their services. The scope of the remaining work is not yet known, because the PQC Technical Lead has not finished the Phase 1 inventory. Until then, the CISO shows dollar amounts as to be determined (TBD).

The CISO sends the first dollar estimate to ONCD and OMB within 30 days of the May 4, 2027 inventory, as OMB M-23-02 requires. The CFO adds it to the annual budget request. The table below shows the cost items the Organization expects.

12. Risk Management During Migration #

The PQC Migration Lead reports migration risk to the CIO and CISO every quarter through the Organization’s existing risk governance.

13. Reporting and Plan Maintenance #

• The CISO sends this plan to PQC@omb.eop.gov by October 22, 2026.
• The PQC Migration Lead sends the annual cryptographic inventory to ONCD and CISA by May 4 each year through 2035, as OMB M-23-02 requires.
• Within 30 days of each inventory, the CISO sends ONCD and OMB the estimate of funding needed for the next fiscal year, as OMB M-23-02 requires.
• The CISO updates this plan every year, and when OMB, ONCD, NIST, or CISA issues new guidance.
• Every quarter, the PQC Migration Lead reports progress to the CIO and CISO as the share of systems in each tier that have finished each phase.
• The ISSO records each missed milestone as a POA&M item in the GRC system with a new date and a reason.

Appendix A. Cryptographic Inventory Fields #

OMB M-23-02 requires these fields for each system in the annual inventory. The PQC Migration Lead names each system by its identifier only, not by a name that describes its function or location.

Appendix B. Quantum-Vulnerable Algorithms #

OMB M-26-15 lists these public-key algorithms as quantum-vulnerable. The PQC Technical Lead treats any other public-key algorithm as quantum-vulnerable unless it is known to resist quantum attack, as OMB M-26-15 advises.

Appendix C. FedRAMP Cloud Services Used by the Organization #

Before submission, the CISO lists each FedRAMP cloud service the Organization uses. The FedRAMP Marketplace shows the services each agency has authorized. The CISO also adds each service the Organization uses under another agency’s authorization. System Owners confirm each tier during the inventory, and the PQC Migration Lead sends the vendor PQC questionnaire to Tier 1 providers first.

Appendix D. References #

• OMB M-26-15, Execution of the Migration to Post-Quantum Cryptography, June 24, 2026
• OMB M-23-02, Migrating to Post-Quantum Cryptography, November 18, 2022
• Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026 (Federal Register document 2026-12909)
• Executive Order 14413, Ushering in the Next Frontier of Quantum Innovation, June 22, 2026 (Federal Register document 2026-12910)
• Executive Order 14306, Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity and Amending Executive Order 13694 and Executive Order 14144, June 6, 2025
• Quantum Computing Cybersecurity Preparedness Act, Public Law 117-260, December 21, 2022
• National Security Memorandum 10, Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems, May 4, 2022
• NIST IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards, November 2024
• NIST CSWP 39-upd1, Considerations for Achieving Crypto Agility: Strategies and Practices, December 19, 2025, updated June 29, 2026
• NIST FIPS 203, FIPS 204, and FIPS 205, August 2024
• CISA, Product Categories for Technologies That Use Post-Quantum Cryptography Standards, January 23, 2026
• CISA, Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools, August 15, 2024
• NIST SP 800-53 Revision 5, control SC-13, Cryptographic Protection
• FedRAMP Marketplace data (github.com/FedRAMP/marketplace-fedramp-gov-data)
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FIPS 140-3: Cryptographic Module Security Requirements, March 22, 2019.
• FIPS 199: Standards for Security Categorization, February 2004.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.