Menu
Breach value calculatorCalculator

Post-Quantum Readiness Checklist: How Ready Are You, and Which Tools Help?

Measure post-quantum readiness using official roadmaps (NIST, NCSC, EU, Canada, Singapore), free tools, a CBOM, and a checklist covering personal data.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

13 min read

To measure post-quantum readiness, first find where your cryptography lives. Then sort your data by how long it must stay secret, and check vendors, protocols and certificates against a dated plan. Governments in the UK, EU, Canada and Singapore have published roadmaps with milestones you can measure against. Free tools cover parts of the job. None covers all of it. A post-quantum readiness checklist closes this post.

You can't migrate cryptography you haven't found. Most readiness work is finding it, recording it and showing progress.

Post-quantum cryptography (PQC) means algorithms designed to resist a future quantum computer. For the background (Q-Day, "harvest now, decrypt later", NIST's 2024 standards), read What Is Q-Day?.

What do official post-quantum checklists and roadmaps ask for?

They agree on the order of work: discover, prioritise, plan, migrate, verify. They differ on dates and on who they bind. I opened each document's official page on 28 October 2026.

Issuer Document Date What it asks Dates it sets
NIST (US) IR 8547, Transition to Post-Quantum Cryptography Standards (final) October 2026 (final dated 27 Oct 2026) Identifies quantum-vulnerable standards and the post-quantum standards products will need to adopt None on the CSRC page, which lists the final report; I couldn't read the PDF
NIST NCCoE (US) SP 1800-38B, Quantum Readiness: Cryptographic Discovery; SP 1800-38C, Testing Draft Standards for Interoperability and Performance 19 Dec 2023 (preliminary drafts) Finding cryptography in an estate; testing post-quantum algorithms for compatibility None
CISA, NSA and NIST (US) Quantum-Readiness: Migration to Post-Quantum Cryptography 21 Aug 2023 A quantum-readiness roadmap, a cryptographic inventory, supply-chain assessment, vendor engagement None
UK NCSC Timelines for migration to post-quantum cryptography 20 Mar 2025 Discovery and assessment, a migration plan, then migration by priority 2028: discovery and assessment complete, initial migration plan built; 2031: early, highest-priority migration done; 2035: migration of all systems, services and products complete
EU Member States, with the European Commission A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography 23 Jun 2025 Member States start transitioning; high-risk use cases first Start by end of 2026; high-risk use cases by end of 2030 (Commission PQC page)
Germany, BSI Quantum technologies and post-quantum cryptography, pointing to TR-02102-1 (recommendations and key lengths) TR-02102-1 version 2026-01 Push migration forward; combine post-quantum with classical schemes where possible; design for crypto-agility None on the page
Netherlands: AIVD, CWI, TNO The PQC Migration Handbook, second edition 29 Nov 2024 Finding cryptographic assets, assessing quantum risk, setting up crypto-agility None stated in the announcement
Canada, Cyber Centre Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001) June 2025 Three phases: preparation, identification, transition (non-classified federal systems) For federal departments and agencies: an initial departmental migration plan by April 2026, then annual progress reports; high-priority systems migrated by end of 2031; remaining systems by end of 2035
Singapore, CSA Advisory on Quantum-Safe Migration for Organisations 14 Oct 2026 Identify important systems, ask vendors for roadmaps, avoid hard-coded cryptography All organisations: a migration plan by end 2027. Critical information infrastructure (CII) owners: "a 2031 target for migration of CII systems", per CSA's separate CII guidance. Others: "encouraged to complete migration by 2035"
Singapore, CSA with GovTech and IMDA Quantum-Safe Migration Handbook and Quantum Readiness Index V1, 16 Jul 2026 A handbook plus a self-assessment questionnaire None on the page

NIST's CSRC page lists IR 8547 (Final) as released on 27 October 2026, replacing the November 2024 draft (NIST CSRC).

Not covered here: ENISA, the UAE and India, because I didn't read an official PQC document from them at source. I found no PQC-specific guidance from Saudi Arabia's National Cybersecurity Authority.

How can you measure post-quantum readiness?

Measure where your cryptography is, how long your data must stay secret, what vendors have committed to, and how easily you can change algorithms.

1. Inventory: where does cryptography live?

List every system that encrypts, signs or verifies: websites, APIs, VPNs, email, certificate authorities, code signing, databases, backups and your own software. The NCSC wants the nature, scale, version and dependencies of each system, not a formal asset register (NCSC).

2. A cryptography bill of materials (CBOM)

A CBOM is a machine-readable inventory of cryptographic assets, kept alongside your software bill of materials (SBOM). CycloneDX describes it as a way to "Discover, manage, and report on cryptographic assets in preparation for a quantum-safe future" (CycloneDX).

3. Data-lifetime triage

For each data store, write down how many years the data must stay confidential. If health records must stay secret for 20 years and the system that moves them won't be upgraded until 2033, that gap is your risk.

4. Vendor attestations

Your readiness is mostly your vendors' readiness. Singapore's CSA suggests asking vendors whether their products support quantum-safe cryptography, what their upgrade roadmap is, and whether their timelines match yours (CSA advisory). Record the answer, the date and who gave it. Our rule, not CSA's: "on the roadmap" without a date counts as no.

5. A simple maturity scale (CyphrQ's own)

This scale is ours, not a standard.

Level Name What it looks like
0 Unaware No one owns the topic; no inventory
1 Discovering An owner exists; inventory started; long-lived data identified
2 Planned Inventory covers the main systems; priorities and dates agreed; vendor answers recorded
3 Migrating Highest-priority systems use hybrid or post-quantum key exchange; progress measured each quarter
4 Agile Algorithms can be changed by configuration; inventory updates automatically; re-tested after every upgrade

In our reading, the NCSC's 2028 milestone lines up roughly with level 2.

Which tools can help?

Tools help with discovery and testing, not data lifetimes or vendor answers. TLS is the protocol that encrypts web and API traffic. A "hybrid" key exchange pairs a classical algorithm with a post-quantum one.

Tool What it measures What it can't tell you
Quantum Readiness Index (CSA Singapore) A self-assessment questionnaire across "five domains" that returns recommendations and helps "prioritise action areas" Anything technical about your systems; it's only as good as your answers
testssl.sh Per its README, it "checks a server's service on any port for the support of TLS/SSL ciphers, protocols as well as some cryptographic flaws". Free, GPLv2 Cryptography off the network: files, databases, code signing. The README doesn't say how it reports post-quantum groups; check your version's changelog
Open Quantum Safe (liboqs) "An open source C library for quantum-resistant cryptographic algorithms", with prototype integrations including OpenSSL Your estate: it's a library for lab testing, not a scanner
CycloneDX CBOM A format for recording cryptographic assets and their relationships to software It records findings; it discovers nothing itself
Hybrid TLS handshake checks Whether a server negotiates X25519MLKEM768 with a capable client. See our TLS guide Anything beyond that one connection path

I haven't tested any commercial discovery product, so I name none. If you trial one, ask what it finds beyond a TLS and dependency scan, and ask for CBOM output.

In practice: the NCSC expects you to be able to "quantify how many of your software clients are using PQC" during migration (NCSC). A repeated TLS scan of your own endpoints is a low-cost way to produce that number for network traffic.

What does post-quantum risk mean for personal data and privacy?

Personal data that stays sensitive for years comes first: a diagnosis, identity number or fingerprint doesn't expire. This isn't legal advice; it's how I'd frame the question for a data protection officer (DPO).

What the law asks for

Data protection law doesn't mention quantum computers. It asks for security matched to the risk. The UK regulator, the ICO, quotes Article 32 of the UK GDPR: "Taking into account the state of the art, the costs of implementation", organisations must act "to ensure a level of security appropriate to the risk" (ICO, A guide to data security).

The ICO adds that "for a number of years the ICO has considered encryption to be an appropriate technical measure". As post-quantum algorithms ship in mainstream software, "state of the art" moves. Whether a regulator would expect them is a question for your lawyers.

Retention minimisation is a post-quantum control

Data you've deleted can't be decrypted later. Shorter retention shrinks what "harvest now, decrypt later" can reach, at no technology cost. Start with archives, backups and old exports.

What to tell your DPO

  • Which datasets hold personal data that must stay confidential for 10 years or more.
  • Which systems carry it over networks, and whether they use hybrid key exchange yet.
  • Whether its retention periods can be shortened.
  • Which processors hold it, and what each has said about post-quantum plans.
  • When the risk assessment is next reviewed, so post-quantum risk is noted there.

What does the research say?

Three examples I could verify at source:

  • MIT: post-quantum encryption on tiny devices. In 2019, MIT researchers presented a chip of about 2 mm² that runs lattice-based cryptography on low-power Internet of Things devices. Sampling uses about 80% of the energy in such schemes, and their sampling hardware was about two orders of magnitude more efficient than traditional methods (MIT News, 1 March 2019). The lead author cautioned that "figuring out if these techniques are really secure takes a long time."
  • CWI, TNO and the AIVD: migration practice. The second edition of their PQC Migration Handbook adds advice on finding cryptographic assets and a TNO tool, PQChoiceAssistant, which "helps companies choose a PQC method" (AIVD).
  • Google: the cost of breaking RSA keeps falling. Craig Gidney's May 2025 estimate cut the resources needed to factor an RSA-2048 key well below his 2019 figure (our explainer).

None of this says when a quantum computer able to break today's encryption will exist. It says the replacements work on real hardware, and threat estimates keep moving.

Worked example: a small company measures itself (illustrative)

This example is fictional. A 40-person physiotherapy chain runs a booking website, a cloud patient-records system, a site-to-site VPN between clinics, and nightly backups to a second cloud provider.

  1. Inventory. Its IT provider lists 9 systems that use cryptography. Two weren't on anyone's list: an old file-transfer server used by one insurer, and a code-signing certificate for an in-house tablet app.
  2. Data triage. Patient notes stay sensitive for years, so they're priority one.
  3. Protocol check. A TLS scan shows the booking website negotiates hybrid key exchange through its host. The VPN appliance doesn't.
  4. Vendors. The records vendor gives a dated, written roadmap. The VPN vendor's undated "on the roadmap" is recorded as no.
  5. Score. On CyphrQ's scale the company moves from level 0 to level 1 in a week. To reach level 2: replace or upgrade the VPN, retire the file-transfer server, and review backup retention with its DPO.

Most of the findings came from asking questions and reading configuration, not from specialist tools.

Post-quantum readiness checklist

CyphrQ's checklist (preview). This list is ours, not an official standard.

  1. A named owner is accountable for post-quantum readiness.
  2. A migration plan exists, dated against the official milestones that apply to you.
  3. Every system that uses cryptography is listed, with version and dependencies.
  4. Each data store has a confidentiality lifetime; long-lived personal data is priority one.
  5. Internet-facing TLS endpoints are tested for hybrid key exchange, with result and date.
  6. Algorithms and TLS groups are set in configuration, not hard-coded.
  7. Key vendors are asked for a dated post-quantum roadmap; undated answers count as no.
  8. Scans repeat each quarter, and raw output is kept.

The full post-quantum readiness checklist maps each item to the guidance above. Start with items 1, 3 and 4.

Going deeper: for security and IT teams

What to put in a cryptographic inventory record

CycloneDX models cryptography as a component of type cryptographic-asset, defined as "A cryptographic asset including algorithms, protocols, certificates, keys, tokens, and secrets" (CycloneDX 1.6 JSON reference). Its schema adds crypto-specific properties to that component. I couldn't read the full field list, so take exact field names from the JSON reference for the version your tooling emits.

Whatever the format, each record needs at least (our list, not a standard):

  • asset type: algorithm, certificate, key, protocol;
  • algorithm and parameter set (for example ML-KEM-768, RSA-2048, ECDSA P-256);
  • where it runs: host, service, library and version;
  • what depends on it: the component reference in your SBOM;
  • owner, and the date it was last verified;
  • the confidentiality lifetime of the data it protects.

Where to look

TLS endpoints, load balancers, service meshes and TLS-inspecting proxies; SSH configurations and authorised-key types; VPN IKE settings and firmware crypto libraries; CA key algorithms, certificate profiles and HSM firmware; code and firmware signing keys; crypto libraries in your dependency tree; and how database, disk and backup keys are wrapped. The companion checklist adds vendor questions.

How to evidence progress

Auditors and boards will want trends, not a one-off spreadsheet. Track these each quarter:

  • share of in-scope TLS endpoints that negotiate a hybrid group such as X25519MLKEM768 with a capable client;
  • certificates in use by signature algorithm and key size, with counts;
  • share of systems where the algorithm or TLS group list is set in configuration, not code (crypto-agility);
  • share of long-lived data stores whose transport and key exchange are post-quantum protected;
  • share of key vendors with a dated, written roadmap;
  • inventory coverage: systems inventoried as a share of the asset register.

Keep raw scan output with dates, so each number traces back to a test.

Standards to map against

Key takeaways

  • Readiness is measurable: inventory coverage, data lifetimes, vendor commitments, protocol tests and crypto-agility.
  • The UK, EU, Canada and Singapore publish dates to plan against; NIST's final IR 8547 is dated 27 October 2026.
  • Long-lived personal data comes first; shorter retention reduces exposure at no technology cost, though it still takes process and legal review.

Learn more

Sources

All read on 28 October 2026.

Spotted a mistake? Report a correction.