Checklist · CISO

Post-quantum readiness checklist: 15 questions every CISO should be able to answer

Published 7 October 2026 · 7 min read · By Ali Korsi If your board, regulator or auditor asked about quantum risk tomorrow, these are the questions you would need to answer, and the evidence that would make the answers credible.

Lire en français

The standards are no longer the bottleneck. NIST approved FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024. In June 2025 the NIS Cooperation Group published the EU’s Coordinated Implementation Roadmap, which expects first steps, including cryptographic inventories, by the end of 2026, high-risk use cases migrated by the end of 2030, and as many systems as feasible by 2035. NIST’s draft IR 8547 proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035.

What is still missing in most organisations is a clear, evidence-backed view of where they stand. This checklist is designed to give you that view. It is deliberately practical: each question comes with what “good” looks like, so you can tell the difference between a real answer and a hopeful one.

Short on time? Our free 2-minute PQC readiness assessment asks the same questions interactively and gives you a score with suggested next steps.

1. Visibility and inventory

Do we know where cryptography is used across our estate?
You cannot migrate, prioritise or report on what you have not found. The EU roadmap puts inventories in its first, end-2026 milestone for exactly this reason.

Good looks like: a cryptographic inventory covering source code, certificates and network endpoints, built from discovery rather than questionnaires alone.
Is that inventory machine-readable and kept current?
A spreadsheet compiled once for an audit is out of date within weeks. Inventory has to keep pace with releases.

Good looks like: a CBOM in CycloneDX 1.6 format, regenerated automatically, for example in your CI pipeline.
Can we name every quantum-vulnerable algorithm in use, and where it lives?
RSA, ECDSA, ECDH and finite-field Diffie-Hellman are the algorithms Shor’s algorithm breaks. Knowing that they are “somewhere” is not enough.

Good looks like: a per-asset list of algorithm, key size, library and location (file, certificate or host), filterable by system owner.

2. Risk and data lifetime

Do we know how long our sensitive data must stay confidential?
Confidentiality lifetime is what turns quantum risk from a future problem into a current one.

Good looks like: data classes with documented retention and confidentiality periods, linked to the systems that process them.
Have we assessed our harvest-now-decrypt-later exposure?
Traffic captured today can be decrypted later. Long-lived data crossing networks under quantum-vulnerable key exchange is already at risk.

Good looks like: a documented HNDL assessment identifying which flows carry long-lived data over RSA or ECDH key exchange.
Is quantum risk scored per asset, not as a single organisation-wide rating?
A flat rating cannot tell you where to start. Prioritisation needs asset-level differences.

Good looks like: each asset carries a risk score that combines algorithm weakness, exposure and data lifetime, so the top of the list is defensible.

3. Governance and regulation

Is there a named owner and a budget line for post-quantum migration?
Migration spans application, infrastructure, PKI and procurement teams. Without an owner it stalls between them.

Good looks like: an accountable executive, a programme lead and funding approved for at least the inventory and first migration phase.
Have we mapped quantum risk to our regulatory obligations?
DORA, NIS2 and the EU Cyber Resilience Act already require appropriate cryptography and risk management. Quantum risk falls within those duties.

Good looks like: a mapping of findings to DORA Article 9, NIS2 Article 21 and CRA obligations, reviewed by compliance.
Has the board seen a quantum risk briefing based on our own data?
Generic threat briefings do not support decisions. Boards need to know your exposure and what fixing it will cost.

Good looks like: a short board report showing current exposure, priorities and timeline against the 2026/2030/2035 EU milestones.

4. Suppliers and third parties

Do we know our critical vendors’ PQC roadmaps?
Much of your cryptography sits inside products you do not control: HSMs, cloud KMS, VPN gateways, payment and identity platforms.

Good looks like: written roadmap statements from critical suppliers, with dates for FIPS 203/204 support, tracked in your third-party risk register.
Can our PKI and HSMs issue and handle post-quantum or hybrid certificates?
PKI is often the longest-lead item: root lifetimes, firmware updates and relying-party compatibility all take time.

Good looks like: a tested assessment of CA software, HSM firmware and certificate consumers, with a plan for root and intermediate rollover.
Do new contracts and procurements include PQC requirements?
Systems bought today may still be running in 2035. Each new contract without a requirement extends your exposure.

Good looks like: standard procurement clauses requiring support for NIST PQC standards and crypto-agility, plus disclosure of cryptographic components (for example via a CBOM).

5. Execution and crypto-agility

Do we have a sequenced migration roadmap?
“Migrate everything” is not a plan. Sequencing by risk and dependency is what makes the work achievable.

Good looks like: a phased roadmap, starting with high-HNDL, high-exposure assets, aligned to the FIPS 203/204/205 migration path.
Can we change an algorithm without rewriting the application?
The first post-quantum algorithms will not be the last. Crypto-agility determines what each future change costs.

Good looks like: cryptography behind central libraries or services, algorithms set by configuration, and no hard-coded primitives in business logic.
Are we preventing new quantum-vulnerable cryptography from being introduced?
Inventory without a gate is a leaking bucket: teams keep adding RSA and ECDSA while you remove them.

Good looks like: automated checks in CI that flag new quantum-vulnerable usage, with an exceptions process.

How to score yourself

Give yourself one point for each question you could answer today with evidence, not intent. Treat the result as a conversation starter, not a measurement: the bands below are practitioner guidance, not a validated maturity model.

Score	What it usually means
0–5	Early stage. Start with the inventory (questions 1–3); everything else depends on it.
6–10	Foundations in place. Focus on per-asset risk scoring, supplier roadmaps and a sequenced plan.
11–15	Well positioned. Shift attention to execution, crypto-agility and keeping the inventory current.

Where CRYPTAGION fits

Several of these questions depend on an accurate inventory. CRYPTAGION builds one through static analysis of Python, JavaScript/TypeScript, Java, Go and C/C++, X.509 certificate parsing and live TLS endpoint scanning. It assigns each asset a 0–100 quantum risk score that accounts for HNDL exposure, exports a CycloneDX 1.6 CBOM, produces a board-ready PDF mapped to DORA, NIS2, the EU CRA and FIPS 203/204/205, and proposes a four-wave migration roadmap. It runs on-premises or air-gapped.

Want your score without the pen and paper? Take the free 2-minute PQC readiness assessment.

Sources

How ready are you, really?

Get a readiness score in two minutes, with the next steps that matter most for your organisation.

Take the 2-minute assessment →

Prefer to talk it through? Book a free discovery call.

← All resources · Home