PQC StatusA post-quantum cryptography (PQC) readiness checklist has one job: turn a multi-year migration into items a team can finish this quarter, each leaving behind evidence someone else can read. The order matters. Key exchange comes first because recorded traffic is protected only by the key exchange; inventory, suppliers, signatures and monitoring follow. Every item below names the artefact to produce, not only the idea to consider.
How to use this checklist
Work the phases in order, but run discovery (phase 2) and the quick wins (phase 3) in parallel: waiting for a complete inventory before enabling hybrid key exchange on a public web endpoint delays the only control that mitigates recorded traffic. Give every item an owner, a date and one artefact. The artefact is the point: PCI DSS, DORA and NIS2 ask for documented policies, inventories and reviews, and an undocumented migration looks exactly like no migration. This article is information, not legal advice.
Four terms used throughout. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key exchange standardized in NIST FIPS 203, published as a final standard on 2024-08-13. A KEM (key encapsulation mechanism) is the primitive that establishes a shared secret. HNDL (harvest now, decrypt later) is the practice of recording encrypted traffic now to decrypt it once a capable quantum computer exists. A CBOM (cryptographic bill of materials) is a machine-readable inventory of cryptographic assets.
Phase 1: governance and scope
- Name one accountable owner and a working group that includes security architecture, PKI, network, application owners and procurement. Evidence: a one-page mandate with names, scope and meeting cadence.
- Choose the timeline that anchors your plan (sector regulator, national guidance, customer contracts). Evidence: a short applicability statement naming the frameworks that bind you and those you treat as guidance. Our overview of official post-quantum migration deadlines lists them with their sources.
- Add crypto-agility to the encryption policy. The DORA regulatory technical standards, Commission Delegated Regulation (EU) 2024/1774, Art. 6, require an encryption and cryptographic controls policy including provisions for updating or changing cryptographic technology based on developments in cryptanalysis. NIS2, Directive (EU) 2022/2555, Art. 21(2)(h), requires policies and procedures on the use of cryptography and, where appropriate, encryption. Evidence: the approved policy version, dated, with the clause visible.
- Identify data with long confidentiality horizons: secrets, health and financial records, intellectual property, anything whose exposure in 2040 would still hurt. Evidence: a list of systems with the required secrecy duration per data class.
- Record HNDL in the risk register by name, with the systems affected. Evidence: the risk entry with owner and review date.
Anchor dates for planning
| Source | Milestones | Nature |
|---|---|---|
| EU Coordinated Implementation Roadmap v1.1 (2025-06-23) | Cryptographic inventory and national roadmaps by end of 2026; high-risk use cases migrated by end of 2030; medium-risk by end of 2035 | Coordinated guidance for Member States, not a regulation binding companies |
| UK NCSC (2025-03-20) | Discovery and initial plan by 2028; highest-priority migrations by 2031; complete by 2035 | Guidance |
| US federal: EO 14412 and OMB M-26-15 (June 2026) | Agency PQC migration plans due 2026-10-22; TLS 1.3 required by 2030-01-02; high-value systems on PQC key establishment by end of 2030, PQC signatures by end of 2031; full migration by 2035 (NSM-10) | Binding on US federal agencies |
| BSI TR-02102-1 (version 2026-01) | Hybrid PQC recommended; classical key agreement alone recommended only until end of 2031, end of 2030 for very high protection needs; RSA of at least 3000 bits | Technical guideline |
| ANSSI (France) | Hybridation mandatory in its regulated scope; PQC aimed at products entering qualification from 2027; after 2030 buying products without PQC considered unreasonable | Mandatory in the regulated scope, otherwise recommendation (ANSSI states its PQC recommendations are not yet regulatory obligations elsewhere) |
| NIST IR 8547 | Proposes deprecating quantum-vulnerable algorithms at 112-bit security (for example RSA-2048) after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035 | Initial public draft (2024-11-12), still a draft |
Phase 2: discovery and inventory
- Enumerate the external surface first: every public hostname, its TLS versions, offered key exchange groups, cipher suites and certificate chain. Evidence: a dated scan export per hostname, kept as the before picture.
- Extend inside: TLS terminators and load balancers, VPN concentrators, SSH fleets, service-to-service mutual TLS, database and message-queue connections, HSMs, backup encryption, firmware and software signing pipelines. Evidence: an inventory with purpose, location and owner per entry, which is also what PCI DSS v4.0.1 requirement 12.3.3 expects for cipher suites and protocols in use.
- Make discovery repeatable, not a one-off spreadsheet. OMB M-26-15 asks US agencies for an automated, continuously updated cryptographic inventory; that bar is a reasonable target elsewhere even where it does not apply.
- Produce a CBOM. This is our interpretation, not a literal requirement of the texts above: a CBOM is one practical way to evidence an inventory and to diff it between releases. See what a CBOM contains for the structure.
- Flag the obsolete and the quantum-vulnerable: RSA, ECDSA, EdDSA, ECDH, finite-field DH and DSA are broken by Shor's algorithm on a large enough quantum computer, whatever the key size. RC4 is prohibited in TLS (RFC 7465), MD5 and SHA-1 are obsolete for signatures, and the pre-standard Kyber TLS group X25519Kyber768Draft00 (codepoint 0x6399) should be removed.
openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"OpenSSL 3.5 or later is required for the ML-KEM groups. If openssl s_client rejects the group name, the client is too old and the result says nothing about the server.
Phase 3: quick wins on key exchange
- Enable hybrid key exchange on public TLS endpoints. Offer X25519MLKEM768 (IANA codepoint 0x11EC) first and keep classical X25519 after it as a fallback. SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED) are the registered alternatives. Current Chrome, Edge and Firefox already offer X25519MLKEM768 by default, so adoption is immediate for browser traffic. Evidence: the configuration diff plus a scan before and after.
- Test in staging first and watch for middleboxes that dislike larger ClientHello messages. Evidence: the staging test record and any MTU or fragmentation findings.
- Update SSH. OpenSSH 9.9 (2024-09-19) added
mlkem768x25519-sha256, OpenSSH 10.0 (2025-04-09) made it the default key agreement, and OpenSSH 10.1 (2025-10-06) warns when a connection negotiates a non post-quantum key agreement. Evidence: fleet version report and negotiated key exchange per jump host. - Prefer AES-256 for long-lived data at rest. Symmetric algorithms and hashes are not broken by Shor; Grover's algorithm is the reason AES-256 is preferred for long-term protection.
# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;Syntax and the required build differ between servers and distributions; our guide to enabling ML-KEM on nginx, Apache, HAProxy and Caddy gives the per-server directives. RFC 10024 (August 2026) specifies post-quantum traditional hybrid key agreement for TLS 1.3.
Phase 4: suppliers and procurement
Most of the estate belongs to someone else. Send the same five questions to every critical supplier and file the answers with the contract.
- Which TLS key exchange groups does your service offer today, and can we verify it from outside?
- What is your dated roadmap for ML-KEM support, and which release notes will announce it?
- Which FIPS 203, 204 or 205 implementations do you use, and in which components?
- Can you provide a CBOM or an equivalent cryptographic inventory for the delivered product?
- How does the contract handle a forced algorithm change if cryptanalysis moves?
Evidence: dated written answers per supplier, plus a crypto-agility clause in renewals. For products sold in the EU, the Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), requires protecting confidentiality, for example by encrypting relevant data at rest or in transit by state of the art mechanisms; it does not name post-quantum algorithms. Its reporting obligations apply from 2026-09-11 and it applies fully from 2027-12-11.
Phase 5: signatures, certificates and PKI
- Inventory signature algorithms and validity windows. List every certificate and signing key whose validity extends past your anchor dates. Evidence: a certificate register, which DORA RTS Art. 7 requires for ICT assets supporting critical or important functions, alongside key management across the whole lifecycle.
- Shorten lifetimes and automate renewal so an algorithm change is a configuration change, not a project. Evidence: automated issuance coverage, by percentage of certificates under automation.
- Plan code and firmware signing separately. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are the final standards; LMS and XMSS are specified in NIST SP 800-208 and are stateful, so state management is the hard engineering problem. For US National Security Systems, CNSA 2.0 requires exclusive use of its algorithms by end of 2030 for software and firmware signing and traditional networking equipment, and by end of 2033 for web browsers and servers, cloud services, operating systems and niche equipment.
- Do not force post-quantum certificates on the public web yet. Keep hybrid key exchange as the priority: recorded traffic is protected by the key exchange, so signatures and certificates can migrate later, on a planned schedule.
- Test size tolerance now: larger public keys and signatures stress certificate stores, embedded devices and handshake buffers. Evidence: a lab report per device family.
openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"Phase 6: monitoring and review
- Re-scan the external surface on a schedule and alert on regression. A load balancer replacement or a CDN configuration change can silently remove the hybrid group. Evidence: a monthly scan history per hostname.
- Review cipher suites and protocols at least every 12 months. That cadence is the literal text of PCI DSS v4.0.1 requirement 12.3.3, mandatory since 2025-03-31, together with monitoring of continued viability and a documented strategy for anticipated changes in cryptographic vulnerabilities. Evidence: the signed annual review record.
- Track the standards pipeline. NIST selected HQC as a fifth algorithm and backup KEM on 2025-03-11, planned as FIPS 207, with no draft published as of 2026-09. NIST IR 8547 and SP 800-131A Rev. 3 remain initial public drafts.
- Report one number upward: the share of critical endpoints negotiating a hybrid key exchange. Evidence: a quarterly trend, not a one-time snapshot.
Turn the checklist into a first measurement
Phase 2 and phase 6 both need the same input: an external view of what your servers actually negotiate. You can scan your domain with PQC Status for free to see the TLS versions, the offered key exchange groups and the certificate chain, then keep the export as the dated baseline for the inventory item. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation. The concrete next step is to run it on your three most exposed hostnames, file the results, and open one ticket per hostname that does not yet offer a hybrid group.