The text of the Post-Quantum Cryptography Migration Plan
Approval #
| Role | Name | Signature |
|---|---|---|
| Chief Information Security Officer (CISO) |
Revision History #
| Date | Version | Description | Reviewer |
|---|---|---|---|
| 2026-10-31 | 1.0 | Initial issuance | [Reviewer name] |
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.
| Requirement | Source | Where this plan meets it |
|---|---|---|
| Send a PQC Migration Plan to OMB and ONCD within 120 days | OMB M-26-15, Action Two and Plan Submission | This plan; Reporting and Plan Maintenance |
| Set up or update a governance structure with defined roles | OMB M-26-15, Agency-Wide Governance and Roles, and Appendix B | Governance Roles and Responsibilities |
| Name a PQC migration lead to OMB and ONCD | EO 14412; OMB M-23-02 | Governance Roles and Responsibilities; Post-Quantum Cryptography Roles Designation Memorandum |
| Move HVAs and high-impact systems to PQC key establishment by December 31, 2030, and to PQC digital signatures by December 31, 2031 | EO 14412; OMB M-26-15 | Migration Phases, Timelines, and Milestones |
| Mitigate as much quantum risk as feasible in every system by December 31, 2030 | OMB M-26-15, Action One | Purpose and Scope; Migration Phases, Timelines, and Milestones |
| Review the inventory of HVAs and high-impact systems | EO 14412 | Current State; Migration Phases, Timelines, and Milestones |
| System prioritization strategy with a risk-based reason | OMB M-26-15, Risk-Based Prioritization, and Appendix B | System Prioritization Strategy |
| Timelines and milestones for every migration phase | OMB M-26-15, Plan Submission and Appendix B | Migration Phases, Timelines, and Milestones |
| Support TLS 1.3 or a successor version no later than January 2, 2030 | EO 14306; OMB M-26-15, Appendix A | TLS 1.3 Testing and Deployment |
| Methods and automated tools used for the cryptographic inventory | OMB M-26-15, Appendix B; OMB M-23-02 | Cryptographic Inventory Methods and Tools |
| Plan for a cryptographically agile architecture | OMB M-26-15, Appendix A and Appendix B | Cryptographic Agility |
| Build PQC into each part of the zero trust architecture | OMB M-26-15, Appendix A | Cryptographic Agility |
| Third-party coordination plan, including Federal Risk and Authorization Management Program (FedRAMP) providers and the Cybersecurity and Infrastructure Security Agency (CISA) product categories list | OMB M-26-15, Vendor and Third-Party Software, and Appendix B | Third-Party Coordination; FedRAMP Cloud Services Used by the Organization |
| Estimate of funding and personnel, and an annual funding estimate within 30 days of each inventory | OMB M-26-15, Appendix B; OMB M-23-02 | Funding and Personnel Estimate; Reporting and Plan Maintenance |
| Risk management strategy for the migration period | OMB M-26-15, Appendix B | Risk Management During Migration |
| Annual inventory of systems with quantum-vulnerable cryptography, sent to ONCD and CISA | OMB M-23-02; National Security Memorandum 10 | Cryptographic Inventory Methods and Tools; Cryptographic Inventory Fields |
| Align the plan with the National Institute of Standards and Technology (NIST) transition schedule | OMB M-26-15; NIST IR 8547 (initial public draft) | Migration Phases, Timelines, and Milestones |
| Use NIST-approved post-quantum algorithms | Federal Information Processing Standards (FIPS) 203, FIPS 204, and FIPS 205 | Cryptographic Agility |
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].
| Role | Responsibilities |
|---|---|
| CIO | Accountable for migration priorities, risk acceptance, and resources. Decides on each system that cannot migrate on time. |
| CISO | Accountable with the CIO for priorities and risk. Owns this plan and the prioritization method. Sends the plan and its annual updates to OMB and ONCD. |
| PQC Migration Lead | An employee or detailee who reports to the CIO, as EO 14412 defines the role. Coordinates the migration across the Organization. Keeps the cryptographic inventory and the PQC Migration Plan current. Reports status to the CIO and the CISO every quarter. Serves as the Organization’s contact for OMB, ONCD, and CISA. |
| PQC Technical Lead | Oversees inventory scans, algorithm selection, testing, and deployment of PQC and hybrid cryptography. Keeps the Organization’s approved algorithm list. |
| Security Architect | Builds PQC into the Organization’s zero trust architecture and plans for interoperability between systems. |
| Chief Financial Officer (CFO) | Works with the CIO, the CISO, and the PQC Migration Lead so that the annual budget request includes PQC costs. |
| System Owners | Carry out the migration for their systems. Choose products that are crypto-agile and support PQC. Set the milestone dates for their systems. |
| Information System Security Officers (ISSOs) | Record each system’s cryptographic inventory in its System Security and Privacy Plan (SSPP). Record each missed milestone as a plan of action and milestones (POA&M) item in the governance, risk, and compliance (GRC) system. |
| Program offices (requirement owners) | Include PQC readiness and crypto-agility requirements in their requirements documents. The Contracting Officer (CO) and the Contracting Officer’s Representative (COR) put those requirements into contracts. |
| Senior Agency Official for Privacy (SAOP) | Confirms which systems hold personally identifiable information (PII) that must stay protected in 2030 and later. |
4. Current State #
The Organization’s documents cover the Moderate baseline of Federal Information Processing Standards (FIPS) 199. The Organization chose it because no system is above the Moderate impact level, so it has no high-impact systems. The Organization’s profile records no HVAs under OMB M-19-03. Before submission, the CISO confirms that, and lists any 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.
| HVA or high-impact system | HVA ID or system identifier | Designation |
|---|---|---|
| [HVA name, or None] | [HVA ID] | HVA |
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:
| Check | Result |
|---|---|
| TLS versions the site accepts | [for example, 1.2 and 1.3] |
| Key exchange observed | [for example, X25519, which is quantum-vulnerable] |
| Certificate key type and length | [key type and length] |
| Certificate expiry date | [date] |
| Hybrid post-quantum key exchange offered | [yes, no, or not tested] |
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.
| Tier | Criteria | Reason |
|---|---|---|
| Tier 1 | Any HVA or high-impact system. Any system that holds data that must stay sensitive in 2030 or later, such as PII, financial records, and screening data. Any logical access control system that uses a quantum-vulnerable public-key algorithm, such as identity providers and the public key infrastructure (PKI) behind Personal Identity Verification (PIV) cards. Any system with public internet endpoints, including public websites and remote access. | OMB M-26-15 requires agencies to put these systems first. An attacker can record data today and decrypt it later, so long-lived data and exposed connections carry the most risk. |
| Tier 2 | Other systems that connect to external partners or the internet. | An attacker can record traffic on external connections. |
| Tier 3 | Internal systems whose data stops being sensitive before 2030. | These systems have the lowest exposure. They migrate during normal technology refresh. |
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:
| System or service | Tier | Reason |
|---|---|---|
| Each HVA: [HVA name], HVA ID [HVA ID] | 1 (first) | EO 14412 sets fixed 2030 and 2031 dates |
| Each high-impact system | 1 (first) | EO 14412 sets fixed 2030 and 2031 dates |
| Identity and access: the single sign-on (SSO) service, the cloud directory, the on-premises directory, and the PKI behind PIV cards | 1 | Logical access control based on public-key cryptography |
| Each public website and its hosting service | 1 | Public internet endpoint |
| Remote access through the zero trust network access (ZTNA) service, and the secure web gateway | 1 | Ends encrypted sessions for all users |
| Systems that hold personal, financial, or screening data that stays sensitive past 2030 | 1 | Data that an attacker can record now and decrypt later |
| Key management: the key management service and the key vaults in the cloud platform | 1 | Protects the keys for other systems |
| FedRAMP cloud services | 1, 2, or 3 | Listed by service in the appendix FedRAMP Cloud Services Used by the Organization |
| All other systems | 2 or 3 | Set by the criteria above 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) #
| Due date | Milestone | Owner |
|---|---|---|
| October 22, 2026 | Send this plan to OMB and ONCD at PQC@omb.eop.gov. | CISO |
| October 22, 2026 | Sign the Post-Quantum Cryptography Roles Designation Memorandum, if not signed already. | CIO |
| November 30, 2026 | Review the inventory of HVAs and high-impact systems, as EO 14412 requires. | CISO; PQC Migration Lead |
| March 31, 2027 | Get each HVA vendor’s written PQC schedule for its product and its hosting. | PQC Migration Lead |
| March 31, 2027 | Send a vendor PQC questionnaire to every FedRAMP provider and software vendor. | PQC Migration Lead |
| April 15, 2027 | Finish the automated inventory of Tier 1 systems, in time for the May 4, 2027 inventory. | PQC Technical Lead |
| May 4 each year | Send the annual cryptographic inventory to ONCD and CISA. | PQC Migration Lead |
| September 30, 2027 | Add PQC awareness to role-based training for System Owners and ISSOs in the learning management system (LMS). | CISO |
Phase 2: Pilots and early migration (2027 to 2028) #
| Due date | Milestone | Owner |
|---|---|---|
| June 30, 2028 | Pilot hybrid ML-KEM key exchange on public websites and on the secure web gateway. | PQC Technical Lead; System Owners |
| December 31, 2028 | Test PQC key establishment for each HVA’s user sessions and system interfaces. | System Owners |
| December 31, 2028 | Test the PQC readiness of the identity provider with its vendor. | PQC Technical Lead |
| December 31, 2028 | Join the General Services Administration (GSA) Federal Identity, Credential, and Access Management (FICAM) PQC working group. | PQC Migration Lead |
| December 31, 2028 | Update this plan with lessons learned from the pilots. | CISO |
Phase 3: Prioritized migration of key establishment (2028 to 2030) #
| Due date | Milestone | Owner |
|---|---|---|
| December 31, 2030 | Use PQC key establishment (ML-KEM, alone or in a hybrid) in every HVA, every high-impact system, and every other Tier 1 system. | System Owners |
| December 31, 2030 | Mitigate as much quantum risk as feasible in Tier 2 and Tier 3 systems. | System Owners |
| December 31, 2030 | Make every system crypto-agile. | System Owners; Security Architect |
| December 31, 2030 | Accept any remaining risk in writing. | CIO |
Phase 4: Signature migration (2031) #
| Due date | Milestone | Owner |
|---|---|---|
| December 31, 2031 | Use PQC digital signatures (ML-DSA or SLH-DSA) in every HVA, every high-impact system, and every other Tier 1 system. Include website certificates and PIV credentials as vendors and GSA make them available. | System Owners; PQC Technical Lead |
Phase 5: Full migration (by 2035) #
| Due date | Milestone | Owner |
|---|---|---|
| December 31, 2035 | Migrate the remaining Tier 2 and Tier 3 systems, based on risk and on the products available. | System Owners |
| December 31, 2035 | Remove every quantum-vulnerable algorithm where commercial products allow. Accept each exception in writing. | System Owners; CIO |
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.
| Milestone | Due date | Owner |
|---|---|---|
| List every TLS endpoint and the TLS versions it accepts, using vulnerability scans and traffic data from the secure web gateway. | March 31, 2027 | PQC Technical Lead |
| Test TLS 1.3 on every internal and external endpoint. | December 31, 2027 | System Owners |
| Turn on TLS 1.3 on every endpoint that can support it. | December 31, 2028 | System Owners |
| Replace or retire each endpoint that cannot support TLS 1.3, or record a POA&M item with a date before the federal deadline. | June 30, 2029 | System Owners; CIO |
| Confirm by scan that every endpoint supports TLS 1.3. | December 31, 2029 | PQC Technical Lead |
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.
| Method | Tool | What it finds |
|---|---|---|
| Network scanning | The vulnerability scanner | TLS and Secure Shell (SSH) versions, cipher suites, and certificates on the Organization’s endpoints |
| Traffic inspection | The secure web gateway | TLS versions and key exchange used in user and internet traffic |
| Endpoint and certificate data | The endpoint detection and response (EDR) tool | Certificates and cryptographic software on the Organization’s devices |
| Cloud key listing | The key management service and the key vaults in the cloud platform | Key types and lengths stored in the Organization’s cloud tenants |
| Software analysis | Software bills of materials, software composition analysis, and code scanning for applications built for the Organization | Cryptographic libraries and functions inside custom code |
| Provider statements | Vendor PQC questionnaires, and the cryptographic inventories that the FedRAMP Program Management Office obtains for authorized services | Cryptography inside FedRAMP and other software services that the Organization cannot scan |
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:
- Confirms the cryptographic standards and mandates that apply, and tells System Owners, developers, and vendors what they require.
- Updates the cryptographic inventory, starting with the systems that hold the most critical data.
- Finds gaps in the asset, configuration, vulnerability, and logging tools, and adds automated discovery of algorithms and key lengths where the tools lack it.
- Ranks the assets to fix, by risk and by the cost and effort of each change.
- 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.
| Item | Fiscal years | Estimate |
|---|---|---|
| PQC Migration Lead, as part of an existing federal position | 2027 to 2035 | [number] full-time equivalent (FTE) each year |
| PQC Technical Lead and engineering support | 2027 to 2031 | [number] FTE each year; dollars TBD |
| Automated cryptographic discovery tools, if the vulnerability scanner and the EDR tool cannot cover the need | 2027 | TBD |
| Pilots: hybrid TLS for public websites and the secure web gateway, and PQC testing for each HVA | 2027 to 2028 | TBD |
| Replacement of systems that cannot support PQC | 2028 to 2030 | TBD after the inventory |
| PIV and certificate updates | 2031 | TBD with GSA guidance |
| Total | 2027 to 2035 | TBD; the first estimate is due 30 days after the May 4, 2027 inventory |
12. Risk Management During Migration #
| Risk | How the Organization manages it |
|---|---|
| An attacker records traffic now and decrypts it later | System Owners move Tier 1 key establishment first. Records officers shorten the retention of sensitive data where records schedules allow. System Owners encrypt stored data with the Advanced Encryption Standard (AES) and 256-bit keys. |
| A provider is late with PQC support | The ISSO tracks provider dates in the SSPP. The COR raises delays with the provider. The program office considers other products at renewal. |
| A change breaks a connection with a partner or an older client | The PQC Technical Lead tests each change in a pilot first. System Owners use hybrid modes during the transition and roll back through change management in the ticketing system. |
| Hybrid setups add complexity and new flaws | System Owners use hybrid modes only where a risk assessment supports them, and only with settings the vendor supports. |
| An attacker forces a connection to use a weaker algorithm | System Owners configure systems to accept only approved algorithms. |
| A system cannot migrate on time | The ISSO records a POA&M item in the GRC system. The CIO accepts or rejects the risk in writing, with advice from the Authorizing Official. The System Owner replaces or retires the system. |
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.
| # | Field |
|---|---|
| 1 | Federal Information Security Modernization Act (FISMA) system identifier |
| 2 | FIPS 199 categorization (Low, Moderate, or High) |
| 3 | HVA identifier, if the system is an HVA |
| 4 | Each quantum-vulnerable cryptographic system in active use: the algorithm, the service it provides (key exchange, encrypted connection, or digital signature), and the key length |
| 5 | Whether the software is commercial, government, or custom, and the vendor or developer name |
| 6 | Operating systems, with major and minor versions |
| 7 | Where the system is hosted: the Organization’s premises, a commercial cloud (name the provider), a government cloud (name the agency), or a hybrid |
| 8 | Types of data in the system, using records management categories, and how long the data must stay protected |
| 9 | Other notes |
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.
| Algorithm | Use |
|---|---|
| Elliptic Curve Diffie-Hellman (ECDH), including X25519, a form of ECDH | Key establishment |
| Menezes-Qu-Vanstone (MQV) | Key establishment |
| Diffie-Hellman (DH) and its variants | Key establishment |
| Rivest-Shamir-Adleman (RSA) | Key establishment and digital signatures |
| Elliptic Curve Digital Signature Algorithm (ECDSA) | Digital signatures |
| Digital Signature Algorithm (DSA) | Digital signatures |
| Any other public-key algorithm not known to resist quantum attack | Any |
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.
| Provider and service | FedRAMP ID | Model and level | Tier | Reason and use |
|---|---|---|---|---|
| [Provider and service] | [FedRAMP ID] | [Model and level] | [1, 2, or 3] | [Reason for the tier] |
| [Provider and service] | [FedRAMP ID] | [Model and level] | [1, 2, or 3] | [Reason for the tier] |
| [Provider and service] | [FedRAMP ID] | [Model and level] | [1, 2, or 3] | [Reason for the tier] |
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.