Most post-quantum programmes have a strategy slide and a discovery tool, but no plan that a programme board can approve, fund and track: which systems move in which wave, who owns them, what each supplier has promised and by when. This template is that plan. It is built around the three milestones the UK NCSC sets for migration (plan and discover by 2028, complete the highest-priority work by 2031, finish by 2035) and gives you fill-in sections for the programme charter, the inventory extract, priority scoring, migration waves, supplier asks and tracking, testing and rollback, and governance. It is written for the programme lead, the cryptography or PKI lead, enterprise architects and the risk and procurement staff who sit on the programme board. It does not explain the algorithms or the threat: read the Post-Quantum Cryptography Migration Guide first and use this page as the document you keep.
How to use this template
- Replace text in square brackets, such as [Organisation], [system] and [owner], with your own details. Keep the section numbers so programme reports, risk entries and supplier tickets can refer to them.
- Section 2 is an extract from your cryptographic inventory, not the inventory itself. Keep the full inventory in a CBOM or CMDB (see the Cryptographic Inventory and CBOM Guide) and copy in only the fields needed to plan.
- The scoring model, wave sizes and review periods are NHI Mgmt Group suggestions. Adapt them, but agree them at the programme board before scoring starts.
- Dates in this template follow the NCSC timeline as published when this page was checked on 9 November 2026. If you are a US federal agency or supplier, or a national security system owner, add your own mandated dates from the Post-Quantum Cryptography Deadlines Tracker and the NIST IR 8547 PQC Transition Timeline Guide. NIST published the final IR 8547 on 27 October 2026.
- Re-issue the plan at least [every six months] and at every milestone gate in section 7.
1. Programme charter
| Field | Value |
|---|---|
| Accountable executive and programme lead | [CISO or CTO], [programme lead] |
| Objective | Migrate [Organisation]'s systems, services and products that rely on quantum-vulnerable public-key cryptography (RSA, elliptic curve Diffie-Hellman and ECDSA, finite field Diffie-Hellman) to standardised post-quantum or hybrid schemes by [2035], with highest-priority systems complete by [2031]. |
| Target algorithms | As set in the [Encryption Policy], for example ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures. See the Encryption Policy Template. |
| Scope | [business units], [products sold to customers], [managed service providers], [OT and embedded estate] |
| Out of scope | [for example symmetric encryption and hashing already at AES-256 and SHA-256 or above, reviewed separately] |
| Budget and funding route | [capital], [run budget], [linked refresh programmes] |
| Programme board members | [architecture], [PKI and key management], [infrastructure], [application owners], [procurement], [risk], [OT] |
| Statement of intent | [link to the published or internal statement]. The NCSC suggests publishing a statement of intent so suppliers and customers see the demand. |
2. Inventory extract
The NCSC expects discovery to start with key services, the data they hold (its lifespan and value to an adversary) and how it is protected in transit and at rest, including systems run by managed service providers, with versions and dependencies recorded. One row per system or service.
| ID | System or service | Owner | Cryptographic uses | Current algorithms | Who controls the change | Data protected and lifespan | Dependencies |
|---|---|---|---|---|---|---|---|
| Q-001 | [Customer web front end] | [ ] | [TLS key exchange, server certificate] | [ECDHE P-256, RSA 2048 certificate] | [CDN supplier, own PKI] | [session data, minutes; login credentials] | [CDN, load balancer, public CA] |
| Q-002 | [Document archive] | [ ] | [data at rest key wrapping, backups over VPN] | [RSA 3072 key wrap; IKEv2 with ECDH] | [own; HSM supplier] | [contracts, 25 years] | [HSM, VPN gateways] |
| Q-003 | [Firmware signing for shipped devices] | [ ] | [code signing, secure boot root of trust] | [ECDSA P-384 in device ROM] | [own; chip supplier] | [device life, 15 years] | [HSM, chip supplier] |
| Q-004 | [Workload identity and service mesh] | [ ] | [mTLS, short-lived certificates, token signing] | [ECDSA P-256, RS256 JWT] | [platform team; mesh project] | [service traffic; signed tokens] | [internal CA, identity provider] |
Keys, certificates and signing services are non-human identities. Record their owners here, because migration is also a rotation and re-issuance exercise. See the Post-Quantum Migration for NHIs Guide.
3. Priority scoring
Score each inventory row on five factors, 1 (low) to 3 (high). Total of 12 or more is Priority 1, 8 to 11 Priority 2, 7 or less Priority 3 (our thresholds). The factors follow the NCSC prioritisation guidance (valuable or long-lived data, long-lived hardware, supply chain and legacy dependencies) plus Mosca's inequality: if the years the data must stay secret plus the years migration will take exceed the years until a cryptographically relevant quantum computer, the system is already late.
| Factor | 1 | 2 | 3 |
|---|---|---|---|
| A. Confidentiality lifespan of data (harvest now, decrypt later) | Under 2 years | 2 to 10 years | Over 10 years |
| B. Trust anchor or signing lifetime | Replaceable in a release | Replaceable with a planned change | Fixed in hardware or deployed devices for years |
| C. Exposure | Internal, segmented | Internal, broad or partner-facing | Internet-facing or crosses untrusted networks |
| D. Change lead time | Configuration or library update | Supplier upgrade or re-platform | Hardware replacement or re-certification |
| E. Business criticality | Supporting | Important | Critical service or regulated |
| ID | A | B | C | D | E | Total | Priority | Strategy | Rationale |
|---|---|---|---|---|---|---|---|---|---|
| Q-001 | [1] | [1] | [3] | [2] | [3] | [10] | [2] | [In-place via supplier] | [ ] |
| Q-002 | [3] | [2] | [2] | [2] | [3] | [12] | [1] | [In-place, HSM upgrade] | [ ] |
| Q-003 | [1] | [3] | [3] | [3] | [3] | [13] | [1] | [Re-platform next device generation] | [ ] |
For the strategy column use the NCSC options: in-place migration, re-platform, retire, run to end of life, or tolerate the risk. A tolerated risk needs a named approver, compensating controls and a review date in your risk register.
4. Migration waves
| Wave | Window (example) | Content | Exit criteria | Rows |
|---|---|---|---|---|
| 0 Foundations | [now to 2027] | Approved algorithm policy; PQC clauses in procurement; inventory tooling; test lab with hybrid TLS and PQC certificates; HSM and PKI roadmap | Policy approved; contract clauses live; lab can test hybrid handshakes and PQC chains | [ ] |
| 1 Discovery complete and quick wins | [to 2028] | Full inventory and scoring; supplier asks issued; hybrid key exchange turned on where the platform supports it (TLS terminators, CDNs, SSH) | NCSC 2028 milestone: discovery done, initial plan and supplier requirements communicated | [ ] |
| 2 Priority 1 | [2028 to 2031] | Long-lived data protection, trust anchors and signing roots, internet-facing services | NCSC 2031 milestone: highest-priority migrations complete; route to full migration refined | [ ] |
| 3 Priority 2 | [2029 to 2033] | Internal services, workload identity, partner integrations | All Priority 2 rows migrated or with an approved exception | [ ] |
| 4 Long tail | [2031 to 2035] | Legacy, OT and embedded; retirements; tolerated risks | NCSC 2035 milestone: migration complete | [ ] |
Detailed technical steps per area are in the Hybrid Post-Quantum TLS Key Exchange Guide, the ML-DSA and SLH-DSA Post-Quantum Signatures Guide and the OpenSSH Server Hardening Guide.
5. Supplier asks and tracking
NCSC asks organisations to communicate their requirements to suppliers by 2028, and CISA, NSA and NIST advise engaging technology vendors on their post-quantum plans. Send the same asks to every supplier in the inventory and log the answers here. The question set and what good answers look like are in the vendor readiness section of the Post-Quantum Cryptography Migration Guide.
| Supplier and product | Rows affected | Ask sent | Algorithms and parameter sets supported (with versions) | Inside a FIPS 140-3 validated boundary? | Configurable without code or firmware change? | CBOM available? | Committed date | Status |
|---|---|---|---|---|---|---|---|---|
| [CDN supplier] | [Q-001] | [date] | [ ] | [ ] | [ ] | [ ] | [ ] | [Awaiting / Roadmap dated / Available / Deployed] |
| [HSM supplier] | [Q-002, Q-003] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [Managed service provider] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
Contract clause to adapt: "The Supplier shall provide, by [date], a dated roadmap for supporting [ML-KEM and ML-DSA as specified in FIPS 203 and FIPS 204] in [product], shall make cryptographic algorithms configurable without replacement of hardware, and shall provide on request an inventory of the cryptography used in the product." Track suppliers with no dated answer as a programme risk. See the Third-Party Risk Management Guide.
6. Testing and rollback plan
| Change type | Test before rollout | Pilot ring | Rollback |
|---|---|---|---|
| Hybrid key exchange (TLS, SSH, VPN) | Handshake success, latency and packet size through every middlebox in the path | Lab, one internal service, then a small share of external traffic | Keep classical groups enabled; remove the hybrid group by configuration |
| PQC or composite certificates | Chain validation by every relying party, certificate size on constrained devices | Test CA, then one internal application | Keep the classical chain valid until all relying parties validate the new one; revoke last |
| Code and firmware signing | Dual-signed release verified on old and new devices | Internal builds, then one product line | Ship the classically signed artefact alongside |
| Data at rest re-wrapping | Restore test of re-wrapped backups | One non-critical store | Retain previous wrapped keys until restore is proven |
7. Governance, milestones and reporting
| Measure | Target (ours) | Reported to |
|---|---|---|
| Inventory rows scored, as a share of known systems | 100% by [2028] | Programme board, quarterly |
| Priority 1 rows migrated or with approved strategy | 100% by [2031] | Board risk committee |
| Suppliers with a dated PQC roadmap | [90%] of in-scope suppliers by [2028] | Procurement and programme board |
| External TLS endpoints negotiating hybrid key exchange | [rising each quarter] | Programme board |
| New contracts with PQC clauses | 100% from [date] | Procurement |
| Tolerated risks past review date | 0 | Risk committee |
| Gate | Date | Decision | Approved by |
|---|---|---|---|
| Charter and funding | [ ] | [ ] | [ ] |
| Discovery complete (NCSC 2028) | [ ] | [ ] | [ ] |
| Priority 1 complete (NCSC 2031) | [ ] | [ ] | [ ] |
| Programme close (NCSC 2035) | [ ] | [ ] | [ ] |
Implementation guidance
- Charter first: without an accountable executive and a budget line, discovery findings stall. Get section 1 signed before buying tools.
- Score a pilot slice: score 20 to 30 rows across different types (web, data store, signing, OT) and check the priorities look right to architects before scoring everything.
- Send supplier asks early: supplier lead times usually set the critical path, especially for HSMs, network appliances and embedded hardware.
- Take quick wins: enabling hybrid key exchange on platforms that already support it reduces harvest-now-decrypt-later exposure for traffic while the harder work runs.
- Re-issue the plan: update scores and waves at each gate and when standards, supplier answers or mandated dates change.
Small and large organisations: a small organisation relies mainly on suppliers. Sections 1, 5 and a short section 2 covering your own certificates, SSH keys and VPNs are enough. A large or regulated organisation needs every section, a funded programme office, and links into PKI and HSM refresh cycles. The Post-Quantum Readiness Maturity Model helps set the starting point.
Common failures: a discovery scan treated as the plan; priorities set by ease rather than data lifespan and trust anchor lifetime; supplier asks sent informally with no log; trust anchors in shipped devices found too late for the 2031 milestone; pilots without a rollback; and tolerated risks with no owner or review date.
| Template section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| 1 Charter and 7 Governance | PM-9 | GV.RM-01 |
| 2 Inventory extract | CM-8 | ID.AM-02 |
| 3 Priority scoring | PM-9 | ID.RA-05 |
| 4 and 6 Waves, testing and rollback | SC-12, SC-13 | PR.DS-01, PR.DS-02 |
| 5 Supplier asks | SA-4, SR-3 | GV.SC-05 |
Standards and references
- NCSC: Timelines for migration to post-quantum cryptography
- NIST: IR 8547 Transition to Post-Quantum Cryptography Standards
- NIST: FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard
- CISA: Post-Quantum Cryptography Initiative
- CISA, NSA and NIST: Quantum-Readiness: Migration to Post-Quantum Cryptography
- CycloneDX: Cryptography Bill of Materials (CBOM)
Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Cryptographic Inventory and CBOM Guide · Post-Quantum Readiness Maturity Model · Post-Quantum Cryptography Deadlines Tracker · Cryptographic Discovery and PQC Readiness Tools Buyer's Guide