Post-Quantum Cryptography: the roadmap to quantum readiness

The planning benchmark is the cryptographically relevant quantum computer (CRQC): enough error-corrected qubits and runtime stability to run Shor's algorithm against real-world key lengths. Today's systems are orders of magnitude away from that. The news of 2024, then, wasn't a record number but an inflection point: Google's Willow chip showed for the first time under real conditions that the error rate falls as the error-correction code grows — the central scaling hurdle has demonstrably been overcome.

What matters, then, isn't the date of Q-Day but the confidentiality lifetime of each data class: how long would disclosure be damaging? Anything whose shelf life extends beyond the — unknown — Q-Day is already exposed today, the moment it crosses a wire under classical encryption.

The value of the test lies in its discipline: x forces data classification with defined shelf lives, y forces an honest estimate of your own pace of change — experience in grown environments puts this at three to seven years, longer in large enterprises — and z makes the Q-Day assumption explicit instead of implicitly setting it to “sometime.” Run the test per data class, not once for the whole company: the spread between classes is exactly the prioritization that Chapter 11 formalizes.

You can run the test interactively with the Mosca calculator on our PQC services page.

The schemes are fast, but larger: keys and signatures grow from double-digit bytes into the kilobyte range. ML-KEM-768 works with a 1,184-byte public key and a 1,088-byte ciphertext; ML-DSA-65 signs with 3,309 bytes, where ECDSA P-256 needs around 64; SLH-DSA-128s comes in at 7,856 bytes per signature. This is where the practical migration issues arise: handshake packets, certificate chains, HSM storage, MTU limits, and protocol fields with fixed lengths.

In TLS 1.3, the de facto standard is X25519MLKEM768: client and server run X25519 and ML-KEM-768 in parallel and merge both secrets in the key schedule. For the generic case, NIST standardizes the combination in SP 800-227; the BSI names CatKDF and KeyCombine as recommended methods in TR-02102-1 (2026-01). Important for auditors: hybrid is not a weakening but the operating mode explicitly recommended by the BSI for the transition years — from 2032, classical key establishment is meant to run only in hybrid mode anyway.

• Browsers: Chrome, Edge, and Firefox negotiate X25519MLKEM768 by default.
• Network: over 50% of human web traffic at Cloudflare is quantum-safe encrypted (10/2025); since 09/2026, “Automatic Key Exchange” has also been upgrading origin connections.
• Messaging: Signal (PQXDH, 2023) and Apple iMessage (PQ3, 2024) protect session setup and ongoing communication, respectively, in hybrid mode.
• Libraries: OpenSSL 3.5 LTS (04/2025) brings ML-KEM, ML-DSA, and SLH-DSA natively; BouncyCastle and liboqs cover the Java and research stacks.

Legally, the roadmap is a recommendation — but it takes effect indirectly: it defines what supervisory authorities will understand by “state of the art” going forward. That exact term is the yardstick for cryptography in both NIS2 and DORA. Anyone who has to explain in a 2028 audit why high-risk systems are still classically encrypted is arguing against a documented European consensus.

NIST's transition plan IR 8547 (a draft since November 2024) classifies 112-bit security-level schemes — including RSA-2048 and ECDSA P-256 — as “deprecated” starting in 2030, and provides for “disallowed” status for RSA and ECC overall starting in 2035. Still a draft, but already a reference point for US agency planning: FIPS-validated products and US cloud services will phase out their classical modes along these dates — for European customers too.

The signals are unmistakable: in February 2025, the Quantum Safe Financial Forum at Europol called on institutions, vendors, and policymakers to elevate PQC migration to a strategic goal — notably, not through new regulation but coordinated within the existing framework. In January 2026, a joint prioritization methodology followed with FS-ISAC, weighing quantum risk against migration effort. As early as September 2024, the G7 Cyber Expert Group had called on financial supervisors to factor quantum risk into their planning.

The result consolidates into a Cryptography Bill of Materials (CBOM) — a machine-readable inventory of cryptographic components, analogous to the SBOM for software components and representable in standardized form with CycloneDX. The difference from a spreadsheet: a CBOM is versionable, diffable, and verifiable in CI/CD — and answers auditor questions (PCI 12.3.3, the DORA certificate register) as a byproduct. The typical findings are the same everywhere: SHA-1 and 3DES in legacy interfaces, hardcoded cryptography in source code, uncontrolled certificate sprawl outside any CA governance, shadow key stores in deployments — and a supply chain that can't say offhand what cryptography is inside its products.

The target architecture doesn't “build in PQC” — it builds in swappability: algorithms and key lengths in central policies rather than application code, a cryptographic abstraction layer, protocols with room for larger keys and new identifiers, movable trust anchors — and centralized key management anchored in HSMs as the backbone, which incidentally satisfies DORA RTS Art. 7. The practical test of agility is a single question: “How long would it take us to change key establishment across all externally reachable services?” Answers in days demonstrate agility; answers in years reveal a need for action.

The pilot (Phase 4) doesn't prove that PQC works — billions of browser connections have already taken care of that — it proves that your operations can handle it: can the infrastructure cope with the larger handshakes? Do monitoring, IDS rules, and SIEM parsers recognize the new algorithm identifiers instead of flagging ML-KEM handshakes as an anomaly? And does the documented rollback path work? The pilot concludes with a numbers sheet (latency deltas, error rates per client class, middlebox findings, SOC detection rate) — turning the rollout decision into a calculation.

• Weeks 1–2: secure a mandate — a one-page board memo with deadlines, HNDL, and the cost of delay; name a steering committee.
• Weeks 2–4: scan the outer shell — a TLS/certificate scan of all externally reachable services as the fastest reality check.
• Immediately: retire legacy schemes — disable SHA-1, 3DES, and RSA-1024, or place them in the exception register with a date.
• Weeks 3–6: define shelf lives per data class and run the Mosca test per class — the strongest slide for the board.
• Weeks 4–10: commission the cryptographic inventory as a discovery project, consolidate the result as CBOM v1.
• In parallel: systematically ask critical suppliers about their PQC roadmaps and add the sample clause to ongoing tenders.
• Weeks 8–13: launch a hybrid pilot on a real service (X25519MLKEM768) with measurements.
• Weeks 12–13: present a draft roadmap with a wave plan, budget path, KPI set, and reporting cadence.

All templates — the board slide, the sample procurement clause, the objections guide — are included in the whitepaper “Quantum Readiness for CISOs” (download above on this page).