Post-Quantum Readiness Checklist
A reusable post-quantum readiness checklist in eight groups, with a completed fictional example and a blank copy, each item mapped to official guidance.
This checklist is CyphrQ's own, not an official standard. Each item notes the official guidance it draws on, so you can check the source yourself. It is not legal advice. Companion to How Ready Are You for Post-Quantum Cryptography?.
How to use it: mark each item Done, Partly or Not started, add evidence (a file, a scan, an email), and note the date. Repeat every quarter.
Source key
| Code |
Source (all read 28 October 2026) |
| CISA |
CISA, NSA and NIST, Quantum-Readiness: Migration to Post-Quantum Cryptography (21 Aug 2023) |
| NCSC |
UK NCSC, Timelines for migration to post-quantum cryptography (20 Mar 2025) |
| EU |
A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (23 Jun 2025) and the Commission PQC page |
| CA |
Canadian Centre for Cyber Security, ITSM.40.001 (June 2025) |
| SG |
CSA Singapore, Advisory on Quantum-Safe Migration for Organisations (14 Oct 2026) and Quantum Readiness Index (V1, Jul 2026) |
| BSI |
BSI, Quantum technologies and post-quantum cryptography (TR-02102-1 v2026-01) |
| NL |
AIVD, CWI and TNO, The PQC Migration Handbook, 2nd edition (29 Nov 2024) |
| NIST |
NIST IR 8547 (final, Oct 2026); NCCoE SP 1800-38B/C (preliminary drafts, Dec 2023) |
| CDX |
CycloneDX, CBOM |
| ICO |
ICO, A guide to data security (UK GDPR Article 32) |
| Ours |
CyphrQ's own suggestion, not from an official source |
The checklist (with source mapping)
A. Governance
| # |
Item |
Based on |
| A1 |
A named owner is accountable for post-quantum readiness |
Ours |
| A2 |
A quantum-readiness roadmap or migration plan exists, with dates |
CISA (roadmap); NCSC (plan by 2028); SG (plan by end 2027); CA (plan April 2026) |
| A3 |
Progress is reported to leadership at a set interval |
CA (annual reporting); SG (QRI supports discussions with senior management) |
| A4 |
The applicable official milestones are written into the plan |
NCSC; EU; CA; SG |
B. Inventory
| # |
Item |
Based on |
| B1 |
Systems that use cryptography are listed, including vendor-run ones |
CISA (inventory); NCSC (discovery and assessment) |
| B2 |
Each entry records version information and dependencies |
NCSC (nature, scale, version, dependencies) |
| B3 |
Inventory is kept in a machine-readable format (for example a CycloneDX CBOM) linked to the SBOM |
CDX; NL (finding cryptographic assets) |
| B4 |
Discovery covers TLS, SSH, VPN, PKI/HSM, code signing, libraries and data at rest |
NIST SP 1800-38B (cryptographic discovery); Ours (list of places) |
C. Data triage (including personal data)
| # |
Item |
Based on |
| C1 |
Each data store has a confidentiality lifetime in years |
Ours |
| C2 |
Personal data with long sensitivity (health, identity, biometrics) is flagged priority one |
ICO (security appropriate to the risk); Ours (categories) |
| C3 |
Systems carrying long-lived data are ranked first for migration |
NCSC (highest-priority migration by 2031); EU (high-risk use cases by end 2030) |
| C4 |
Long-lifespan or hard-to-update equipment is identified |
Ours |
D. Protocol readiness
| # |
Item |
Based on |
| D1 |
Internet-facing TLS endpoints tested for hybrid key exchange; result and date recorded |
NCSC (quantify clients using PQC); BSI (combine classical and PQ); Ours (test method) |
| D2 |
Key agreement prioritised ahead of signatures |
BSI (key agreement most immediately threatened) |
| D3 |
Algorithms and TLS groups set in configuration, not hard-coded |
SG (avoid hard-coded encryption); BSI and NL (crypto-agility) |
| D4 |
Interoperability of PQ algorithms tested before production |
NIST SP 1800-38C |
E. PKI and certificates
| # |
Item |
Based on |
| E1 |
Certificates and signing keys listed by algorithm, key size and expiry |
CDX (algorithms, keys, certificates); Ours |
| E2 |
Long-validity signature keys (roots, firmware, code signing) identified for early planning |
BSI (signatures where keys have long validity) |
| E3 |
CA and HSM vendors asked for their post-quantum plans |
CISA (vendor engagement); Ours |
F. Vendors and supply chain
| # |
Item |
Based on |
| F1 |
Every key vendor asked for PQ support, upgrade roadmap and timeline fit |
SG; CISA |
| F2 |
Answers recorded with date and source; undated answers treated as "no" |
Ours |
| F3 |
New contracts and renewals favour vendors preparing for the transition |
Ours |
| F4 |
Supply-chain dependencies on PQ readiness assessed |
CISA |
G. Testing and evidence
| # |
Item |
Based on |
| G1 |
Self-assessment completed (for example Singapore's Quantum Readiness Index) |
SG |
| G2 |
Scans repeated each quarter and after library upgrades; raw output kept |
NCSC (assurance metrics); Ours (frequency) |
| G3 |
Metrics tracked: share of endpoints with hybrid key exchange, certificates by algorithm, share of crypto-agile systems |
NCSC; Ours (metric set) |
H. Privacy and DPO
| # |
Item |
Based on |
| H1 |
DPO briefed on which personal datasets are exposed to "harvest now, decrypt later" |
ICO (security appropriate to the risk); Ours |
| H2 |
Retention periods for long-lived personal data reviewed and shortened where possible |
Ours (retention as a PQ control) |
| H3 |
Processors holding long-lived personal data asked about their PQ plans |
SG (vendors); Ours |
| H4 |
Post-quantum risk noted in the next security risk assessment for those datasets |
ICO ("state of the art"); Ours |
Questions for vendors (supports E3, F1 and F4)
Ours, drawing on the vendor-engagement advice from CISA and SG. Record each answer with its date and who gave it (F2).
- Which post-quantum or hybrid algorithms does the product support today, and which are on by default?
- Which crypto library and version does it ship, and how is it updated?
- Can we change algorithms or TLS groups by configuration?
- Can you provide a CBOM, or at least a list of the cryptography in the product?
- What is the dated plan for post-quantum signatures and certificates?
- Does any TLS inspection or proxy feature pass hybrid key exchange through?
Where to look during discovery (supports B4)
Ours, not from an official source.
- TLS: public and internal endpoints, load balancers, service meshes, TLS-inspecting proxies.
- SSH: server and client configurations, and the key types in authorised-key files.
- VPN: IKE and TLS settings on gateways, plus the firmware's crypto library.
- PKI and HSMs: root and issuing CA key algorithms, certificate profiles, HSM firmware and its algorithm support.
- Code and firmware signing: signing key algorithms and how long signed artefacts stay trusted.
- Libraries: crypto libraries and versions in your dependency tree, from SBOMs or package manifests.
- Data at rest: database, disk and backup encryption, and how their keys are wrapped and exchanged.
Completed example (fictional)
Fictional organisation: a 40-person physiotherapy chain with a booking website, a cloud patient-records system, a site-to-site VPN and cloud backups. Assessed over one week. Every detail below is invented to show how the checklist is used.
| # |
Status |
Evidence / note |
| A1 |
Done |
Operations manager named owner |
| A2 |
Partly |
Draft plan, no dates yet |
| A3 |
Not started |
First board update planned next quarter |
| A4 |
Done |
Using NCSC 2028 milestone as the planning date |
| B1 |
Done |
9 systems listed by the IT provider |
| B2 |
Partly |
Versions missing for 3 systems |
| B3 |
Not started |
Spreadsheet for now |
| B4 |
Partly |
Code-signing certificate and old file-transfer server found late |
| C1 |
Done |
Lifetimes recorded for all data stores |
| C2 |
Done |
Patient notes flagged priority one |
| C3 |
Done |
Patient-records transfer and VPN ranked first |
| C4 |
Done |
VPN appliance flagged as hard to update |
| D1 |
Partly |
Booking site negotiates hybrid key exchange via host; VPN does not |
| D2 |
Done |
Key exchange first |
| D3 |
Not started |
VPN algorithms fixed by firmware |
| D4 |
Not started |
Not applicable until VPN upgrade |
| E1 |
Partly |
Website and code-signing certificates listed; VPN certificate missing |
| E2 |
Done |
Code-signing key noted |
| E3 |
Not started |
— |
| F1 |
Partly |
2 of 4 key vendors asked |
| F2 |
Done |
Records vendor gave dated roadmap; VPN vendor undated, recorded as "no" |
| F3 |
Not started |
VPN contract renewal next year |
| F4 |
Not started |
— |
| G1 |
Not started |
Plan to complete the QRI next month |
| G2 |
Not started |
First scan is the baseline |
| G3 |
Partly |
Baseline: 1 of 2 internet-facing endpoints hybrid |
| H1 |
Done |
DPO briefed |
| H2 |
Partly |
Backup retention under review |
| H3 |
Partly |
Records vendor asked; backup provider not yet |
| H4 |
Not started |
Next review in the spring |
Result on CyphrQ's scale (ours, not a standard): level 1, Discovering. Next steps: upgrade or replace the VPN, retire the file-transfer server, finish vendor questions, complete the QRI.
Blank copy
Organisation: __ · Assessed by: _ · Date: ___
| # |
Item |
Status (Done / Partly / Not started) |
Evidence / note |
Next review |
| A1 |
Named owner accountable |
|
|
|
| A2 |
Roadmap or plan with dates |
|
|
|
| A3 |
Regular reporting to leadership |
|
|
|
| A4 |
Official milestones in the plan |
|
|
|
| B1 |
Systems using cryptography listed |
|
|
|
| B2 |
Versions and dependencies recorded |
|
|
|
| B3 |
Machine-readable inventory (CBOM) |
|
|
|
| B4 |
Discovery covers TLS, SSH, VPN, PKI/HSM, signing, libraries, data at rest |
|
|
|
| C1 |
Confidentiality lifetime per data store |
|
|
|
| C2 |
Long-sensitivity personal data flagged |
|
|
|
| C3 |
Long-lived data systems ranked first |
|
|
|
| C4 |
Hard-to-update equipment identified |
|
|
|
| D1 |
TLS endpoints tested for hybrid key exchange |
|
|
|
| D2 |
Key agreement prioritised |
|
|
|
| D3 |
Algorithms set in configuration |
|
|
|
| D4 |
PQ interoperability tested |
|
|
|
| E1 |
Certificates and keys by algorithm, size, expiry |
|
|
|
| E2 |
Long-validity signing keys identified |
|
|
|
| E3 |
CA and HSM vendors asked |
|
|
|
| F1 |
Key vendors asked about PQ support and roadmap |
|
|
|
| F2 |
Answers dated; undated treated as "no" |
|
|
|
| F3 |
Contracts favour prepared vendors |
|
|
|
| F4 |
Supply-chain dependencies assessed |
|
|
|
| G1 |
Self-assessment completed |
|
|
|
| G2 |
Scans repeated; raw output kept |
|
|
|
| G3 |
Metrics tracked |
|
|
|
| H1 |
DPO briefed |
|
|
|
| H2 |
Retention reviewed |
|
|
|
| H3 |
Processors asked |
|
|
|
| H4 |
PQ risk in the risk assessment |
|
|
|
Level on CyphrQ's scale (0 Unaware · 1 Discovering · 2 Planned · 3 Migrating · 4 Agile): ____
