The PQC Readiness Checklist Every CISO Should Run Through

Post-quantum cryptography readiness has a specific structure. There are six areas that must all advance for a migration to succeed: cryptographic discovery, algorithm selection, programme management, hybrid deployment, governance, and supply chain coverage. A CISO who can give a confident status on all six has a usable readiness picture. One who cannot has unassessed risk in the uncovered areas.

This checklist is a self-assessment instrument, not a compliance audit. Compliance requirements vary by organisation, jurisdiction, and sector. The six sections below map to the technical and programme management foundations that every organisation planning a PQC migration needs in place, regardless of which regulatory framework applies. The structure follows the gap analysis dimensions in NIST IR 8547 (November 2024), the NCSC's March 2025 migration timeline guidance, and NIST NCCoE SP 1800-38B.

Score each item: 0 (not started), 1 (in progress), 2 (complete). Maximum score across 16 items: 32. Interpretation is in Section 8.

Section 1: Cryptographic Discovery and Inventory

The CBOM is the prerequisite for everything that follows. You cannot prioritise what you have not mapped, and no migration plan survives first contact with an unknown algorithm deployment.

• ☐ A cryptographic discovery exercise has been completed across all IT environments, all applications, all network infrastructure, all external-facing systems, and all OT environments with network-accessible cryptographic components. Discovery covers both automated scanning (tools such as BouncyCastle, Cryptosense Analyzer, IBM Guardium, or equivalent) and manual review for bespoke applications and embedded systems that automated tools cannot reach.

• ☐ A Cryptographic Bill of Materials (CBOM) has been produced. Minimum content: algorithm identity (e.g. RSA-2048, ECDSA P-256, AES-128-GCM), key size, protocol context (TLS, IPsec, S/MIME, code signing, SSH, database TDE), location in the stack (operating system, middleware, application, hardware), certificate and PKI dependencies, and dependency relationships between applications and libraries. A CBOM populated from memory is not a CBOM.

• ☐ All RSA, ECDH, ECDSA, DSA, DH, and classical finite-field key exchange instances have been identified and prioritised by data classification and system criticality. The prioritisation order follows NIST NCCoE SP 1800-38B: (1) systems protecting data with long confidentiality requirements (HNDL-exposed); (2) internet-facing systems with high connection volumes; (3) certificate and PKI infrastructure; (4) internal systems.

For the detailed methodology for building a CBOM, including tooling selection and inventory templates, see the cryptographic asset register build guide.

Section 2: Algorithm Selection

Algorithm selection is not a free choice. The NIST FIPS standards define the approved targets. The only variable is which parameter set applies to your organisation's compliance context.

• ☐ Approved target algorithms have been selected and documented. The reference table below shows the standard selection. Deviations from the primary recommendation must be documented with a rationale.

• ☐ CNSA 2.0 applicability has been assessed. Organisations operating US national security systems, or providing services to US government customers under CNSA 2.0, must use the higher parameter sets: ML-KEM-1024, not ML-KEM-768, and ML-DSA-87, not ML-DSA-65. For reference: ML-DSA-65 produces a signature size of 3,309 bytes (FIPS 204 Table 2) and a public key of 1,952 bytes. ML-DSA-87 produces a signature size of 4,595 bytes and a public key of 2,592 bytes. An organisation in CNSA 2.0 scope that has selected ML-DSA-65 is not compliant with NSA's requirements.

• ☐ Hybrid scheme design has been determined for TLS. For internet-facing TLS 1.3 key exchange, the recommended hybrid is X25519+ML-KEM-768, specified in IETF RFC 9496 (the X-Wing hybrid KEM) and deployed in production by Cloudflare, Google, and Mozilla since 2023-2024. For CNSA 2.0 scope: X25519+ML-KEM-1024 or equivalent higher parameter hybrid. TLS 1.3 key exchange is negotiated independently of the certificate, so hybrid key exchange can be deployed without changing the PKI.

Section 3: Programme Management and Timelines

A PQC migration is a multi-year cross-functional programme, not an IT project. Without a programme owner and a written plan, the work stops at the discovery phase and does not restart until a regulator or an incident forces it.

• ☐ A PQC migration programme owner has been named with board-level mandate, defined scope, and a reporting line to the CISO and CEO. Cross-functional dependencies in a PQC migration include IT, OT, legal, procurement, and finance. Without the mandate, those dependencies become blockers.

• ☐ Migration milestones have been aligned to at least one applicable regulatory framework. The three primary frameworks and their key dates:

The strictest applicable timeline governs. For organisations in CNSA 2.0 scope with legacy systems still using classical asymmetric algorithms, 2033 is the binding endpoint. For the full timeline analysis by framework, see PQC migration timeline 2025, 2026, and 2027.

• ☐ A written migration plan exists with a schedule, named owner per workstream, and current status. A migration plan that exists only in a CISO's head is not a programme. The plan must include: (a) cryptographic inventory baseline; (b) migration priority order by system; (c) dependency map — which systems must be migrated before others can follow; (d) supplier PQC roadmap integration; (e) testing and validation approach for hybrid deployments; (f) rollback procedures if a PQC deployment causes service degradation.

Section 4: Hybrid Deployment Progress

Hybrid deployment is the single highest-impact near-term action for HNDL risk reduction. It does not require PKI replacement, and it provides forward secrecy against a CRQC for all sessions established after deployment.

• ☐ Hybrid TLS (X25519+ML-KEM-768) has been deployed on all external-facing services. HNDL interception protection applies to all new TLS connections from the point of deployment. The certificate and PKI infrastructure do not change; only the key exchange mechanism in the TLS 1.3 handshake changes. This is the most deployable early action in the entire migration programme.

• ☐ A PKI root CA migration plan is documented. Certificate-based authentication systems depend on PKI trust anchors. Eventually, the root CA must be replaced with an ML-DSA root. Root CA migration is the most technically disruptive component of a PQC migration. A documented plan must include: current CA hierarchy map; estimated certificate count; replacement schedule; and root CA ceremony planning. Root CA ceremony planning typically requires FIPS 140-3 validated HSM capability, designated ceremony witnesses, and a cryptographic agility period during which both old and new root CAs are trusted. Understating this complexity is the most common planning failure in PKI PQC migration.

• ☐ FIPS 140-3 validated PQC cryptographic modules have been identified or are on the procurement roadmap. FIPS 140-3 validated HSMs and TPM chips supporting ML-KEM and ML-DSA became available through the NIST CMVP from 2025. For organisations whose security architecture requires FIPS-validated hardware, module availability is a prerequisite for Phase 2 migration. [ASSUMED: Kelly must verify current commercial availability of FIPS 140-3 validated PQC HSMs from specific vendors before the checklist item implies they are broadly accessible.]

Section 5: Governance and Board Visibility

PQC migration requires multi-year budget, cross-functional resource, and board-level risk acceptance. Without governance formalisation, the programme stalls when the first significant cost or integration challenge appears.

• ☐ The quantum threat has been presented to the board or audit committee. A board presentation on PQC readiness must cover: (a) the organisation's HNDL exposure window — which data is at risk and why; (b) the applicable regulatory timeline; (c) the estimated cost of the migration programme; (d) current readiness status against each section of this checklist. A board that has not seen this presentation does not have the information needed to allocate the resources the migration requires. The Mosca inequality provides the analytical basis: if migration time plus data confidentiality requirement exceeds time to a CRQC, the organisation has a current problem.

• ☐ PQC migration has been included in the information security risk register with a risk score, named owner, and treatment plan. An informal understanding that migration is "in progress" does not satisfy audit or regulatory review. The risk register entry should include: (a) risk description — data encrypted under RSA or ECDH is exposed to HNDL by a state-level adversary with a CRQC; (b) likelihood and impact assessment; (c) risk owner; (d) treatment: ongoing migration programme; (e) residual risk at each migration milestone.

Section 6: Supply Chain and Third-Party Coverage

An organisation's cryptographic posture is only as strong as the weakest link in its critical service dependencies. Under DORA Article 28, NIS2 Article 21(2)(j), and NIST IR 8547 Section 5.3, the supply chain cryptographic obligation extends beyond the organisation's own systems.

• ☐ All tier-1 critical ICT suppliers have been assessed for PQC roadmap status. For each critical supplier, the assessment answers: (a) Does the supplier support hybrid key exchange (X25519+ML-KEM-768) today? (b) Has the supplier published a PQC migration roadmap? (c) Does the supplier's roadmap align with your own migration milestones? (d) Does the roadmap include FIPS 203/204/205/206 support in its product schedule? Suppliers without a PQC roadmap are a migration risk item that requires a contractual or procurement response, not a monitoring note.

• ☐ New procurement contracts include PQC capability requirements. From 2025 onwards, any new contract for cryptographic infrastructure, network equipment, cloud services, or software with a cryptographic dependency should include: (a) a requirement for PQC migration support within the contract term; (b) a disclosure requirement for the supplier's PQC roadmap; (c) a contractual right to terminate or renegotiate if the supplier fails to provide PQC-capable versions within the agreed timeline.

Scoring Your Readiness

Add your scores across all 16 items. Maximum: 32.

Most organisations in 2026 sit in the 0-10 range. Many have not completed a CBOM. This is not a crisis observation; it is an accurate statement of where the market is. Phase 1 discovery work is time-consuming, requires dedicated resource, and was not actionable until the NIST FIPS standards were finalised in 2024. The checklist is not designed to make anyone feel behind. It is designed to make the gaps visible so that the most impactful items can be prioritised.

This scoring model is a practitioner guide, not a regulatory measurement instrument. It provides a structured baseline for an internal readiness conversation, not a compliance certification.

For a structured compliance readiness gap analysis mapped to specific regulatory frameworks including NIST IR 8547, the UK NCSC March 2025 guidance, and DORA, see the PQC compliance readiness gap analysis.