# Post-Quantum Cryptography Migration Plan: [Organisation or programme name]

> Plan for moving an organisation's cryptography from quantum-vulnerable public-key algorithms (RSA, elliptic
> curve and finite field Diffie-Hellman, ECDSA, EdDSA) to the NIST post-quantum standards: FIPS 203 (ML-KEM),
> FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), published August 2024. It covers drivers and deadlines, governance,
> the cryptographic inventory, quantum risk ranking by data shelf life (Mosca's inequality), migration waves with
> hybrid key exchange first and signatures second, crypto-agility architecture, vendor tracking, testing,
> roadmap, risks and reporting. Dates follow NIST IR 8547, *Transition to Post-Quantum Cryptography Standards*
> (final, October 2026): quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed under
> NIST standards after 2035. US federal phases follow OMB Memorandum M-26-15 (24 June 2026). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use one plan per organisation or per major programme. The rules (which algorithms are allowed when) belong in the Cryptography Standard (`security/cryptography-standard`); this plan says how and when you get there.
- Fill section 4 (inventory) and section 5 (risk ranking) first. Without them every later date is a guess.
- Start with key establishment, because "harvest now, decrypt later" makes today's recorded traffic tomorrow's breach. Signatures follow, starting with trust anchors and devices that cannot be updated later.
- Treat the plan as a living document: review it at least every quarter and whenever NIST, a regulator or a key vendor publishes a change.
- Cross-reference: PKI and Certificate Architecture (`security/pki-certificate-architecture`), Asset Inventory (`compliance/asset-inventory`), Supply chain security (`security/supply-chain-security`), Zero Trust Architecture Plan (`security/zero-trust-architecture`), Supplier Security Assessment (`compliance/supplier-security-assessment`), Architecture Decision Record (`architecture/adr-full`).
- Pitfall: treating the migration as an algorithm swap. Most effort goes into finding cryptography, chasing vendors and testing larger keys and signatures in real networks and devices.
-->

## Document control

<!-- Guidance: Record the sponsor and the date basis. When NIST, a government or a key vendor changes a date, update section 1.2 and record it in the revision history. -->

| Field | Value |
|---|---|
| Document ID | [PQC-PLAN-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@pqc-programme-lead] |
| Executive sponsor | [@ciso or @cio] |
| Approvers/reviewers | [@chief-architect], [@pki-lead], [@platform-lead], [@procurement-lead], [@risk-officer] |
| Related standard | [SEC-STD-CRY-001, Cryptography Standard] |
| Planning date basis | [NIST IR 8547 final, October 2026; other roadmaps in section 1.2] |
| Review cadence | [Quarterly] |
| Classification | [Confidential: the inventory reveals weak points] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Risk committee | [@name] | [Decision] | YYYY-MM-DD |
| Finance (budget) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft with inventory baseline |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Dates aligned with NIST IR 8547 final; RFC 10024 hybrid groups adopted as wave 1 target |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved with budget for waves 1 and 2 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, drivers and deadlines](#1-scope-drivers-and-deadlines)
2. [Governance and roles](#2-governance-and-roles)
3. [Threat model and urgency](#3-threat-model-and-urgency)
4. [Cryptographic inventory](#4-cryptographic-inventory)
5. [Quantum risk ranking](#5-quantum-risk-ranking)
6. [Target state and algorithm choices](#6-target-state-and-algorithm-choices)
7. [Migration waves](#7-migration-waves)
8. [Crypto-agility architecture](#8-crypto-agility-architecture)
9. [Vendor and third-party tracking](#9-vendor-and-third-party-tracking)
10. [Testing, performance and interoperability](#10-testing-performance-and-interoperability)
11. [Roadmap and milestones](#11-roadmap-and-milestones)
12. [Risks, dependencies and budget](#12-risks-dependencies-and-budget)
13. [Metrics and reporting](#13-metrics-and-reporting)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope, drivers and deadlines

<!-- Guidance: Say what the plan covers and which dates bind you. Questions: Which regulators, customers or contracts set dates? Do you supply US federal agencies or other governments? Pitfall: copying a government deadline that does not apply to you, or ignoring one that applies through a customer contract. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* All public-key cryptography in systems the organisation builds or operates: TLS, SSH, VPN, PKI, code and firmware signing, document signing, key transport and wrapping | Symmetric encryption and hashes at 128-bit strength or above (reviewed, not migrated, see section 6.3) |
| *Example:* Products shipped to customers, including devices with a field life beyond 2035 | Supplier internals that never process organisation data |
| *Example:* SaaS and cloud services, through supplier tracking (section 9) | [Item] |
| [Item] | [Item] |

### 1.2 Drivers and dates

| ID | Driver | Date or requirement | Applies to us? | Source |
|---|---|---|---|---|
| PQD-001 | NIST IR 8547 (final) | Quantum-vulnerable signatures and key establishment deprecated after 2030, disallowed under NIST standards after 2035 | [Yes, through our standard] | https://csrc.nist.gov/pubs/ir/8547/final |
| PQD-002 | OMB M-26-15 (US federal agencies) | High value assets, high impact and highly sensitive systems: post-quantum key establishment by 2030-12-31, signatures by 2031-12-31; full migration by 2035; TLS 1.3 support by 2030-01-02; agency plans due 120 days after 24 June 2026 | [Yes / No: only if we supply federal systems] | whitehouse.gov |
| PQD-003 | Executive Order 14412, *Securing the Nation Against Advanced Cryptographic Attacks* (22 June 2026) | Policy framework for accelerated federal migration | [Yes / No] | whitehouse.gov |
| PQD-004 *(Example)* | Customer contract clause | Post-quantum roadmap with dates requested in vendor assessments | Yes | [Contract ID] |
| PQD-005 | [Other national roadmap or sector regulator] | [Dates] | [Yes / No] | [Official link, checked YYYY-MM-DD] |

OMB M-26-15 describes five federal phases: strategy, planning and discovery (2026 to 2027); pilots and early migration (2027 to 2028); prioritised migration of key establishment (2028 to 2030); signature migration (2031); full migration (2035). Non-federal organisations can use the same shape with their own dates. This plan is not legal advice; check the current official texts that bind you.

## 2. Governance and roles

<!-- Guidance: The migration touches every team, so accountability must be explicit. M-26-15 stresses that the migration is not only the CIO's and CISO's job. Questions: Who decides priority conflicts? Who owns the inventory? Pitfall: a programme with a lead but no authority over product roadmaps or procurement. -->

| Role | Responsibility |
|---|---|
| Executive sponsor | Funding, priority across portfolios, quarterly report to the board or risk committee |
| PQC programme lead | Plan, roadmap, tracking, reporting, escalation |
| Cryptography architect | Algorithm choices, standard updates, design reviews, exception advice |
| Inventory owner | Discovery tooling, CBOM quality, data feeds to risk ranking |
| PKI lead | CA hierarchy and certificate migration (`security/pki-certificate-architecture`) |
| System and product owners | Migrate their systems, register cryptography, test |
| Procurement and supplier management | Contract clauses and vendor tracking (section 9) |
| Risk officer | Accepts residual risk for systems that cannot migrate in time |

Decision forum: [PQC steering group], meets [monthly], minutes and decisions recorded as ADRs.

## 3. Threat model and urgency

<!-- Guidance: Explain why dates matter for each kind of asset. Questions: How long must each data set stay confidential? How long must a signature be trusted? How long will the migration take? Pitfall: waiting for a quantum computer announcement; recorded traffic is already exposed. -->

A cryptographically relevant quantum computer (CRQC) would break the public-key algorithms used today for key establishment and signatures. None is known to exist, but NIST IR 8547 and OMB M-26-15 treat migration as urgent because:

- **Harvest now, decrypt later (HNDL):** traffic and files recorded today can be decrypted once a CRQC exists. Key establishment protecting long-lived data is the first priority.
- **Long migrations:** earlier cryptographic transitions took more than a decade; products, procurement and integration all take time.
- **Signatures and trust anchors:** signatures are not exposed to HNDL, but roots, firmware and devices that cannot be updated after manufacture must verify post-quantum signatures before a CRQC appears.

Mosca's inequality, as described in NIST IR 8547 section 3, frames the urgency: if X is the number of years data must stay secure and Y the years needed to migrate, start now whenever X + Y is greater than Z, the expected years until a CRQC exists.

| Term | Meaning | Value in this plan |
|---|---|---|
| X | Confidentiality horizon of the data (or trust lifetime of a signature) | Per system, section 5 |
| Y | Years needed to migrate the system, including vendor lead time | Per system, section 5 |
| Z | Planning assumption for years until a CRQC | *Example:* 10 years from 2026, a planning assumption and not a prediction; review yearly |

## 4. Cryptographic inventory

<!-- Guidance: Build the inventory with automated discovery and keep it current; M-26-15 Appendix A names SBOM analysis, code scanning and network scanning as sources for a cryptographic bill of materials (CBOM). Questions: Which discovery sources do you have? Which systems are invisible to scanners (devices, OT, partners)? Pitfall: counting certificates only and missing keys inside applications and libraries. -->

### 4.1 Discovery sources

| Source | Finds | Owner | Coverage *(Example)* |
|---|---|---|---|
| External and internal TLS scanning | Protocol versions, groups, certificates | [@secops] | All registered IP ranges |
| Certificate inventory and CT monitoring | Certificates, issuers, algorithms, expiry | [@pki-lead] | Public and private CAs |
| Code scanning (SAST rules) | Calls to cryptographic APIs, hard-coded algorithms | [@appsec] | [85]% of repositories |
| Software composition analysis and SBOMs | Libraries that implement public-key cryptography | [@appsec] | All built artefacts |
| KMS, HSM and secrets platform exports | Key types, sizes, usage | [@platform] | All accounts |
| SSH and configuration management | Host keys, user keys, VPN settings | [@infrastructure] | Managed servers |
| Supplier questionnaires | Cryptography inside SaaS and products | [@procurement] | Critical suppliers |

### 4.2 Inventory record

Each record holds: asset ID, system, owner, asset type, function (key establishment, signature, encryption, hashing), algorithm and parameters, protocol, library and version, location, data classification, confidentiality horizon (X), trust lifetime for signatures, upgrade path (configuration, software update, hardware replacement, vendor dependency), discovery source, last seen. Record the inventory in CycloneDX CBOM format (CycloneDX 1.6 or later) where tooling allows.

### 4.3 Baseline summary

| Asset class | Count | Quantum-vulnerable | Hybrid or post-quantum today |
|---|---|---|---|
| TLS endpoints, external *(Example)* | 140 | 140 | 22 |
| TLS endpoints, internal *(Example)* | 610 | 610 | 0 |
| SSH host keys *(Example)* | 900 | 900 | 0 |
| Private CAs *(Example)* | 5 | 5 | 0 |
| Code and firmware signing keys *(Example)* | 14 | 14 | 0 |
| KMS key-encryption keys, AES-256 *(Example)* | 260 | 0 | Not applicable |
| VPN gateways *(Example)* | 6 | 6 | 0 |
| Partner file transfer connections *(Example)* | 35 | 35 | 0 |
| **Total** *(Example)* | **1,970** | **1,710** | **22** |

In the example, 22 of 140 external endpoints (15.7%) already negotiate hybrid key exchange because the content delivery provider enabled it by default. AES-256 keys are not quantum-vulnerable in practice, but the keys that wrap or transport them may be: trace key transport paths for each KMS integration.

## 5. Quantum risk ranking

<!-- Guidance: Rank systems with a simple, repeatable rule. The margin X + Y - Z shows how late a system already is. Add exposure factors (internet-facing, recorded by third parties, cannot be updated). Questions: Who set X for each data set? Is Y based on vendor dates or hope? Pitfall: ranking by system criticality alone; a low-criticality archive of long-lived personal data can be the top HNDL risk. -->

### 5.1 Method

1. Set X from the data retention and sensitivity schedule (for signatures, the time the signature must stay trusted).
2. Estimate Y from the upgrade path and vendor roadmap.
3. Compute the margin M = X + Y - Z, using Z from section 3.
4. Assign priority: P1 if M is above 0; P2 if M is between -3 and 0; P3 if M is below -3.
5. Raise one level if the system is internet-facing and its traffic is likely recorded, or if it cannot be updated after deployment.

### 5.2 Ranking (Z = 10 years, *Example*)

| ID | System | Function at risk | X (years) | Y (years) | X + Y | Margin M | Priority |
|---|---|---|---|---|---|---|---|
| PQR-001 *(Example)* | Customer records API | TLS key establishment | 10 | 3 | 13 | 3 | P1 |
| PQR-002 *(Example)* | Records archive backups | RSA key transport of archive keys | 25 | 4 | 29 | 19 | P1 |
| PQR-003 *(Example)* | Device firmware signing | Signature trust over device field life | 15 | 5 | 20 | 10 | P1 |
| PQR-004 *(Example)* | Partner file transfer | Key establishment | 6 | 3 | 9 | -1 | P2 |
| PQR-005 *(Example)* | Staff VPN | Key establishment | 5 | 3 | 8 | -2 | P2, raised to P1 (internet-facing) |
| PQR-006 *(Example)* | Internal metrics pipeline | Internal TLS | 1 | 2 | 3 | -7 | P3 |
| [PQR-NNN] | [System] | [Function] | [X] | [Y] | [X + Y] | [M] | [Priority] |

## 6. Target state and algorithm choices

<!-- Guidance: Name the target algorithms and parameter sets so that every team migrates to the same thing. Align with the Cryptography Standard. Questions: Which category (3 or 5) for which data? Do HSMs and libraries support the targets? Pitfall: picking parameter sets that partners or devices cannot handle. -->

### 6.1 Key establishment

| Use | Transition target | End state | Notes |
|---|---|---|---|
| TLS 1.3 | Hybrid group X25519MLKEM768 (RFC 10024) | ML-KEM, hybrid or pure per future guidance | NIST IR 8547 recommends ML-KEM-768 as the default parameter set |
| High assurance TLS | SecP384r1MLKEM1024 | ML-KEM-1024 | For category 5 data |
| SSH | Hybrid post-quantum key exchange supported by the SSH implementation | Same | Check the implementation's current defaults |
| IKEv2 VPN | Additional post-quantum key exchange with ML-KEM where the product supports it | Same | Vendor dependent (section 9) |
| Key transport and wrapping | ML-KEM-based encapsulation through KMS or HSM | Same | Replaces RSA-OAEP key transport |

### 6.2 Signatures

| Use | Target | Notes |
|---|---|---|
| Certificates and TLS authentication | ML-DSA-65 once CAs, browsers and clients support it | Public TLS follows browser root programs; do not run ahead of them |
| Private CA roots | ML-DSA-87 or SLH-DSA in a parallel hierarchy | Plan root lifetime against 2035 |
| Firmware and boot | LMS or XMSS (SP 800-208), or ML-DSA, verified in hardware | Devices that cannot update the verifier must ship with post-quantum verification |
| Code and container signing | ML-DSA, possibly dual signatures during transition | Timestamp signatures |
| Documents and long-term archives | SLH-DSA or dual signatures with archive timestamp renewal | Long trust lifetimes |

### 6.3 Symmetric cryptography and hashes

NIST IR 8547 section 4.1.3 notes that approved symmetric primitives with at least 128 bits of classical security meet at least post-quantum category 1. No migration is needed for AES-128 and above or SHA-256 and above; move away from 112-bit symmetric standards, which are disallowed in 2030. Prefer AES-256 for data that must stay confidential for decades.

### 6.4 Hybrid policy

Hybrid techniques keep a session or signature secure if either component holds, which hedges against implementation flaws in new algorithms. They add complexity and are expected to be temporary. M-26-15 Appendix A describes hybrid key exchange (two shared secrets combined through a key derivation function) and hybrid signatures (two signatures, both verified). Decision for this plan: [hybrid key exchange for all TLS and VPN during transition; dual signatures only where a relying party cannot yet verify post-quantum signatures]. Record the decision as an ADR.

## 7. Migration waves

<!-- Guidance: Group work into waves that deliver risk reduction early. Wave 1 is usually configuration changes on platforms you control. Questions: What can be switched on without code? What depends on vendors? Pitfall: one big-bang programme with nothing delivered for two years. -->

```mermaid
flowchart LR
  W0["Wave 0: inventory, governance, standard update"] --> W1["Wave 1: hybrid key exchange on platform TLS, CDN, mesh, SSH"]
  W1 --> W2["Wave 2: key transport in KMS and HSM, VPN, partner links"]
  W2 --> W3["Wave 3: private PKI and code signing, parallel post-quantum hierarchy"]
  W3 --> W4["Wave 4: product and device signatures, long-tail systems"]
  W4 --> W5["Wave 5: retire quantum-vulnerable algorithms, close exceptions"]
```

| Wave | Content | Systems (from section 5) | Entry criteria | Exit criteria | Target date |
|---|---|---|---|---|---|
| 0 | Inventory, ranking, governance, Cryptography Standard update | All | Sponsor approval | Inventory covers [95]% of assets; ranking approved | YYYY-MM-DD |
| 1 | Hybrid key exchange on load balancers, CDN, service mesh and SSH | PQR-001, PQR-006 | Library support confirmed | [90]% of external endpoints negotiate hybrid groups | YYYY-MM-DD |
| 2 | ML-KEM key transport in KMS and HSM; VPN; partner file transfer | PQR-002, PQR-004, PQR-005 | Vendor support (section 9) | Archive keys rewrapped; VPN hybrid enabled | YYYY-MM-DD |
| 3 | Parallel post-quantum private CA hierarchy; code-signing keys | PQR-003 | HSM firmware with ML-DSA | Pilot services on post-quantum certificates | YYYY-MM-DD |
| 4 | Product firmware verification, document signing, remaining systems | PQR-003 and long tail | Hardware refresh funded | All P1 and P2 systems migrated | YYYY-MM-DD |
| 5 | Disable quantum-vulnerable algorithms where no longer needed | All | Wave 4 complete | Exceptions closed or accepted by the risk officer | Before 2035 |

Systems that cannot support post-quantum or hybrid cryptography are listed for replacement or decommissioning, as M-26-15 also directs agencies to do.

## 8. Crypto-agility architecture

<!-- Guidance: Design so that the next algorithm change is cheap. NIST CSWP 39 describes agility strategies; M-26-15 Appendix A lists modern libraries with providers, configuration-driven cryptography, protocol negotiation and agile key management. Pitfall: wrapping algorithms in an in-house abstraction that becomes its own legacy. -->

```mermaid
flowchart TB
  POL["Central crypto policy (approved algorithms, parameters)"] --> CFG["Configuration delivery"]
  CFG --> TLS["TLS terminators and mesh"]
  CFG --> LIB["Approved libraries with provider model"]
  CFG --> KMS["KMS and HSM with post-quantum key types"]
  LIB --> APP["Applications"]
  TLS --> APP
  KMS --> APP
  SCAN["Discovery and scanning"] --> CBOM["CBOM inventory"]
  CBOM --> DASH["Migration dashboard"]
  APP --> SCAN
  TLS --> SCAN
```

| ID | Design rule | Status |
|---|---|---|
| AGL-001 | Algorithms and groups are set by central configuration, not code constants | [Planned / In place] |
| AGL-002 | Stored data carries algorithm identifiers and key versions | [Status] |
| AGL-003 | Protocols negotiate algorithms and can be restricted to acceptable ones to prevent downgrade | [Status] |
| AGL-004 | Key management supports classical and post-quantum keys side by side | [Status] |
| AGL-005 | Message formats and databases tolerate larger keys and signatures (ML-DSA-65 signatures are 3,309 bytes; ML-KEM-768 encapsulation keys are 1,184 bytes) | [Status] |
| AGL-006 | Discovery runs continuously and feeds the dashboard | [Status] |

## 9. Vendor and third-party tracking

<!-- Guidance: Much of the migration depends on suppliers: HSMs, CDNs, VPNs, operating systems, SaaS. Ask for dated roadmaps and track them. CISA publishes a list of product categories that use post-quantum standards, which M-26-15 points agencies to. Pitfall: accepting "on the roadmap" without a version and date. -->

| ID | Vendor and product | Function | Current support | Committed version and date | Evidence | Contract clause | Status |
|---|---|---|---|---|---|---|---|
| PQV-001 *(Example)* | [CDN provider] | Edge TLS | Hybrid X25519MLKEM768 enabled by default | Available | Release notes YYYY-MM-DD | Yes | Done |
| PQV-002 *(Example)* | [HSM vendor, model] | Key storage, CA keys | ML-KEM and ML-DSA in firmware [x.y], validation pending | FIPS 140-3 validation expected [quarter] | Vendor letter | Renewal YYYY-MM-DD | Tracking |
| PQV-003 *(Example)* | [VPN vendor] | Staff VPN | No post-quantum key exchange | Not committed | Questionnaire | Add at renewal | Escalated |
| [PQV-NNN] | [Vendor and product] | [Function] | [Support] | [Version and date] | [Evidence] | [Clause] | [Status] |

Standard questions for suppliers: which public-key algorithms you use for our data; whether hybrid key exchange is available and on by default; the dated roadmap for ML-KEM and ML-DSA; FIPS 140-3 validation status for post-quantum modes; how keys we control will move; how you will tell us about changes.

## 10. Testing, performance and interoperability

<!-- Guidance: Post-quantum keys and signatures are larger, and some networks and devices break on larger handshakes. Test before rollout. Questions: Do middleboxes drop large ClientHello messages? Do constrained devices have memory for verification? Pitfall: lab tests that skip real partner and client populations. -->

| ID | Test | Method | Pass criterion | Result |
|---|---|---|---|---|
| PQT-001 *(Example)* | Hybrid TLS handshake through load balancers, proxies and firewalls | Canary rollout to [5]% of traffic | No rise in handshake failures above [0.1] percentage points | [Result] |
| PQT-002 *(Example)* | Client compatibility | Telemetry on negotiated groups by client type | Fallback works for clients without hybrid support | [Result] |
| PQT-003 *(Example)* | Latency and CPU | Load test before and after | p95 handshake latency within [10]% of baseline | [Result] |
| PQT-004 *(Example)* | Device signature verification | Bench test on lowest-spec device | Verification fits memory and boot time budgets | [Result] |
| PQT-005 *(Example)* | Rollback | Switch configuration back | Service restored in under [15] minutes | [Result] |

## 11. Roadmap and milestones

<!-- Guidance: Map waves to dates and to the external deadlines in section 1.2. Show slack, because vendor dates slip. Pitfall: a roadmap that ends in 2035 for everything, leaving no margin. -->

| Milestone | Target date | Linked driver | Owner | Status |
|---|---|---|---|---|
| Inventory baseline approved *(Example)* | YYYY-MM-DD | PQD-001 | [@inventory-owner] | [Status] |
| Hybrid key exchange on all external endpoints *(Example)* | YYYY-MM-DD | PQD-001, HNDL risk | [@platform-lead] | [Status] |
| All P1 key establishment migrated *(Example)* | Before 2030-12-31 | PQD-001, PQD-002 if applicable | [@pqc-programme-lead] | [Status] |
| Post-quantum signatures for P1 systems *(Example)* | Before 2031-12-31 | PQD-002 if applicable | [@pki-lead] | [Status] |
| No quantum-vulnerable algorithms outside accepted exceptions *(Example)* | Before 2035-12-31 | PQD-001 | [@ciso] | [Status] |

## 12. Risks, dependencies and budget

<!-- Guidance: List the programme risks with owners and responses; link to the risk register. Questions: What if a post-quantum algorithm is weakened? What if a key vendor never delivers? Pitfall: no budget line for hardware refresh of devices that cannot be updated. -->

| ID | Risk or dependency | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| PQK-001 *(Example)* | HSM vendor validation for post-quantum modes delayed | Medium | High | Hybrid approach; parallel software pilot; second vendor evaluation | [@pki-lead] |
| PQK-002 *(Example)* | Cryptanalysis weakens a selected algorithm | Low | High | Hybrid mode; agility rules AGL-001 to 004; watch NIST announcements | [@crypto-architect] |
| PQK-003 *(Example)* | Devices in the field cannot verify new signatures | Medium | High | Hardware refresh budget; dual signature period | [@product-lead] |
| PQK-004 *(Example)* | Partners not ready | High | Medium | Bilateral test windows; contract clauses; keep hybrid fallback | [@partner-manager] |

| Budget line | Amount *(Example)* | Period |
|---|---|---|
| Discovery tooling | [Amount] | [Years] |
| HSM upgrades and licences | [Amount] | [Years] |
| Engineering effort (waves 1 to 4) | [Amount] | [Years] |
| Device and hardware refresh | [Amount] | [Years] |

## 13. Metrics and reporting

<!-- Guidance: Report progress in risk terms, not activity. Questions: How much P1 data still travels over quantum-vulnerable key exchange? Pitfall: reporting the number of meetings or scans. -->

| Metric | Definition | Baseline *(Example)* | Target |
|---|---|---|---|
| Inventory coverage | Assets with a complete record / discovered assets | [60]% | 95% |
| External hybrid coverage | External endpoints negotiating hybrid groups / external endpoints | 15.7% (22 of 140) | [90]% |
| P1 systems migrated (key establishment) | Count of P1 systems complete / P1 systems | 0 of 4 | 100% |
| Vendor roadmap coverage | Critical vendors with a dated roadmap / critical vendors | [Value] | 100% |
| Accepted exceptions | Open exceptions with an exit date | [Value] | Falling each quarter |

Report quarterly to [risk committee or board], with the dashboard fed by the CBOM.

## 14. Glossary and references

<!-- Guidance: Keep terms short and references dated. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| CRQC | Cryptographically relevant quantum computer |
| HNDL | Harvest now, decrypt later: recording encrypted data today to decrypt it later |
| Hybrid | Combination of a classical and a post-quantum scheme so both must be broken |
| ML-KEM, ML-DSA, SLH-DSA | Post-quantum standards in FIPS 203, 204 and 205 |
| LMS, XMSS | Stateful hash-based signatures in NIST SP 800-208 |
| CBOM | Cryptographic bill of materials |
| Mosca's inequality | Start migration when X + Y exceeds Z (section 3) |

### 14.2 References

| Reference | Version or date | Use |
|---|---|---|
| NIST IR 8547, *Transition to Post-Quantum Cryptography Standards*, https://csrc.nist.gov/pubs/ir/8547/final | Final, October 2026 (initial public draft November 2024) | Deprecation and disallowance dates, parameter sets, Mosca framing, hybrid discussion |
| OMB Memorandum M-26-15, *Execution of the Migration to Post-Quantum Cryptography* (whitehouse.gov) | 24 June 2026 | Federal phases, deadlines, Appendix A technical guidance |
| Executive Order 14412, *Securing the Nation Against Advanced Cryptographic Attacks* | 22 June 2026 | Federal policy framework |
| FIPS 203, FIPS 204, FIPS 205, https://csrc.nist.gov/projects/post-quantum-cryptography | August 2024 | Algorithms |
| NIST SP 800-208, *Recommendation for Stateful Hash-Based Signature Schemes* | October 2020 | LMS and XMSS |
| RFC 10024, *Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3* | 2026, Proposed Standard | Hybrid TLS groups |
| NIST CSWP 39, *Considerations for Achieving Cryptographic Agility* | December 2025, updated June 2026 | Agility strategies |
| CISA, *Product Categories for Technologies That Use Post-Quantum Cryptography Standards* (cisa.gov) | Current page | Procurement categories |
| CycloneDX specification (cyclonedx.org) | 1.6 and later | CBOM format |

## Standard and licence note

Based on NIST IR 8547 (final, October 2026), FIPS 203, 204 and 205, NIST SP 800-208, NIST CSWP 39, OMB Memorandum M-26-15 and Executive Order 14412, which are works of the US Government, and on IETF RFC 10024. The plan structure, scoring method, tables and examples are original text written for this collection; no publication text is reproduced. Deadlines from US federal policy apply to federal agencies and are shown as dated examples; check which laws, regulators and contracts bind you, and check the current official texts before relying on a date. This is a documentation format, not legal advice. Template licence: MIT.