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.
Document control
| 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
1. Scope, drivers and deadlines
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
| 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
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
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
5.1 Method
- Set X from the data retention and sensitivity schedule (for signatures, the time the signature must stay trusted).
- Estimate Y from the upgrade path and vendor roadmap.
- Compute the margin M = X + Y - Z, using Z from section 3.
- Assign priority: P1 if M is above 0; P2 if M is between -3 and 0; P3 if M is below -3.
- 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
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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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.