Post-Quantum Cryptography, (PQC) Crypto Modernisation and Key Sizes: Why It Matters Now

A digital signature that fitted in 70 bytes under ECDSA now runs to 3,309 bytes under ML-DSA-65. A key exchange that moved in 32 bytes under X25519 now carries 1,184 bytes under ML-KEM-768. Under SLH-DSA, the conservative hash-based fallback, a single signature runs from 7,856 bytes at the smallest parameter set to 49,856 bytes at the largest. These are not rounding differences. They are a different category of object, and the protocols, hardware and certificate architecture built around the old numbers were never designed to carry the new ones.

Post-quantum cryptography gets pitched as an algorithm swap: retire RSA and elliptic curve, install the replacement, close the ticket. The size increase alone disproves that pitch. This is a modernisation programme with load-bearing consequences for protocol design, embedded hardware, certificate chains, HSM firmware and procurement cycles. Solved as a maths problem, it gets solved on paper. Solved as the ecosystem problem it actually is, it gets solved in production, and those are not the same piece of work.

Why the size increase is an infrastructure problem, not a maths problem for Crypto Modernisation

Run the numbers through a live system rather than a paper comparison. ML-KEM-768, the parameter set deployment has converged on for general use, needs a 1,184-byte encapsulation key and produces a 1,088-byte ciphertext, against X25519's 32 bytes. A TLS handshake built around single-digit-kilobyte exchanges now carries several times that in the key exchange alone, before certificates are added. Stack ML-DSA signatures through a certificate chain and packet fragmentation stops being a theoretical edge case in constrained networks: satellite links, industrial control systems, smart metering, anything provisioned against fixed MTU assumptions inherited from a decade of RSA and ECC deployment.

Nor is 768 a settled answer. NIST designates no default parameter set, and the NSA's CNSA 2.0 suite requires ML-KEM-1024 for national security systems, at 1,568 bytes in each direction. Which regime an organisation sits under changes its size budget before a line of code is written.

Hardware security modules built around classical key ceremonies were not sized for lattice-based key material at scale. The FIPS 140-3 certification landscape already reflects this pressure: SITG-Consulting's thematic review of 2026 validations tracks thirty new certificates issued between January and mid-July this year, with HSM vendors, authentication providers and edge-device manufacturers all racing to meet the September 2026 FIPS 140-2 retirement. That is not a standards milestone sitting in a future slide deck; it is a vendor selection filter reshaping procurement decisions now. Smart cards and secure elements with kilobyte-class storage budgets were not built to hold multi-kilobyte signatures. Certificate chains lengthen and handshake latency rises, and every one of these effects reaches a procurement conversation and a capital budget before it reaches a security control. Equipment with a fifteen-year service life, deployed against today's key sizes, will still be in the field when the 2035 disallowment dates land. That turns a cryptography decision into a capital equipment decision, on a horizon longer than standard procurement cycles are built to plan against.

Size also varies sharply within the post-quantum set itself, not only against the classical algorithms it replaces. ISO standardised Classic McEliece within ISO/IEC 18033-2 in mid-2026, adding a code-based key encapsulation option beside the lattice-based standards. Classic McEliece's public keys run to hundreds of kilobytes, against ML-KEM's low four figures. Same security objective, size profiles three orders of magnitude apart. The choice between them is a procurement and network-engineering decision as much as a cryptographic one, and it is being made now, by people who inherit the consequences of getting the size budget wrong.

The mathematics was never the uncertain part for PQC

Shor's algorithm has been published since 1994. It proves that a sufficiently large, fault-tolerant quantum computer factors integers and solves discrete logarithms in polynomial time, which is a formal way of saying RSA and elliptic curve cryptography stop being hard problems the day such a machine exists. That proof is three decades old. What has changed is not the mathematics. What has changed is the seriousness with which standards bodies now treat the engineering timeline behind it.

Symmetric cryptography sits outside that exposure. Grover's algorithm gives only a quadratic speed-up against AES, which a longer key already absorbs: AES-256 remains sound against a quantum adversary in a way RSA-2048 and ECC P-256 do not. The cryptanalytic results published against AES remain reduced-round: a 2026 result against seven of AES-128's ten rounds needed roughly 2^105 chosen plaintexts under one fixed key, which is not an attack anyone mounts. The exposure is confined to the public-key layer, which is exactly where identity, key exchange and signing live, and exactly what carries the size increase described above.

The urgency does not wait for that machine to exist. Encrypted traffic and stored ciphertext harvested today can be retained and decrypted retrospectively once a cryptanalytically relevant quantum computer arrives: the harvest-now, decrypt-later model. Anything encrypted under RSA or ECC today, carrying a confidentiality requirement that outlives the arrival of that capability, is already exposed. The exposure is not a future event. It is a decision made now, about data whose shelf life was underestimated.

Michele Mosca's inequality frames this precisely. If X is the number of years the data must stay confidential, Y is the number of years the migration takes, and Z is the number of years until a cryptanalytically relevant quantum computer exists, then X plus Y greater than Z means exposure has already occurred, regardless of when Z eventually lands. Z is the only genuinely uncertain term in that equation. X and Y are governance decisions, made or deferred by the organisation holding the data, not by the pace of quantum hardware.

Where the deadlines actually sit

NIST finalised the first three post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), in August 2024. NIST IR 8547 sets the transition clock behind them: 112-bit schemes such as RSA-2048 and ECC P-256 are targeted for deprecation from 2030, and all RSA and ECC, regardless of key strength, is disallowed in NIST standards from 2035. That document remains an initial public draft, which has not stopped it becoming the planning baseline every downstream mandate refers back to.

United States: Executive Order 14412, OMB M-26-15 and CNSA 2.0

Two instruments turned that guidance into an operating mandate in June 2026. Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, signed on 22 June, requires federal agencies to move all high value assets and high impact systems to post-quantum key establishment by 31 December 2030 and to post-quantum digital signatures by 31 December 2031, with national security systems handled separately. The same order gives CISA 270 days to publish its view of the minimum elements for a cryptographic bill of materials, which turns the CBOM from a voluntary exercise into a federal compliance artefact (SITG-Consulting's Quantum Weekly carries the detail).

OMB Memorandum M-26-15, issued two days later, carries the execution burden: a migration plan from every agency within 120 days, and a five-phase timeline running from inventory in 2026 and 2027 through to full migration of remaining systems by 2035. The 2035 date sits in the memorandum, not the order, which is worth knowing before quoting it at a regulator.

The NSA's CNSA 2.0 suite runs a parallel schedule for national security systems, sequenced by use case rather than by one cut-off. New acquisitions must support CNSA 2.0 from 1 January 2027. Software and firmware signing and traditional networking equipment must use it exclusively by 2030. Operating systems, browsers, servers and cloud services have until 2033. Anyone reading CNSA 2.0 as a single date is planning against the wrong one.

United Kingdom: the NCSC's three-phase roadmap

The UK's NCSC has published its own three-phase roadmap: cryptographic inventory and migration planning complete by 2028, high-priority systems migrated between 2028 and 2031, full migration across all systems, services and products by 2035.

European Union: DORA, NIS2 and the coordinated PQC roadmap

The EU's coordinated roadmap, published in June 2025, expects member states to have started the transition by the end of this year, with national strategies, cryptographic inventories and first migration steps in place. High-risk critical infrastructure is to be migrated by the end of 2030, and the transition completed across as many systems as practically feasible by 2035. Two live instruments already carry legal weight behind that roadmap. DORA requires financial entities to maintain a register of cryptographic assets and to keep their cryptographic controls under review against developments in cryptanalysis. NIS2's implementing rules impose a comparable crypto-agility obligation on digital infrastructure and service providers. Neither waits for 2035; both are already in force.

Switzerland: FINMA Guidance 05/2026

Switzerland's FINMA added Guidance 05/2026 on 9 July, setting supervisory expectations rather than binding rules: a migration strategy and roadmap, an institution-specific risk analysis, a cryptographic inventory, protection of critical data against harvest-now, decrypt-later, oversight of external service providers, and a transition to crypto-agility. SITG-Consulting's analysis of that guidance is worth reading for what it identifies as missing, which is any account of how a programme on that scale is governed, sequenced and funded.

Australia: the ASD's 2030 cut-off

Australia's ASD has gone further again. Under the Information Security Manual, traditional asymmetric cryptography, RSA, Diffie-Hellman, ECDH and ECDSA alike, ceases to be approved at the end of 2030, with a refined transition plan expected by the end of 2026 and migration of critical systems commencing by the end of 2028. That final date is five years ahead of NIST's comparable one, set by a different agency working from the same mathematics.

Why the convergence itself is evidence

Across the United States, the United Kingdom, the European Union, Switzerland and Australia, independent regulatory processes converge on the same decade, several arriving at 2030 by different routes and different justifications. That convergence is itself evidence: this is not one agency's caution, it is a coordinated read of the same risk model across jurisdictions that do not otherwise coordinate policy on much else. Read against Mosca's inequality, the regulatory dates are not arbitrary compliance milestones. They are working estimates of Z, set by people whose job is to be right about it, with X and Y left for every other organisation to calculate for itself.

The fix is a discipline, not a patch

Migration cannot start with an algorithm choice, because nobody migrates what they have not found. You cannot secure what you cannot see, as SITG-Consulting's PQC practice frames it: the question "what exactly are we migrating?" must be answered before "when should we migrate?" A cryptographic bill of materials, an inventory of every algorithm, key, certificate and dependency in active use, is the mandatory first act: the same discipline an SBOM applies to software supply chains, applied to cryptographic ones. Skip it and the algorithm swap gets applied to the systems that happen to be visible, while the shadow estate, the embedded firmware, the vendor appliance nobody owns the source for, stays on RSA past 2035 by default rather than by decision.

The target state is crypto-agility, not a single completed swap. Key sizes will move again, and parameter sets will be revised as cryptanalysis matures. July 2026 supplied the demonstration. HAWK, a candidate two rounds into NIST's additional signatures process, was withdrawn by its own authors on 29 July after an AI-assisted analysis found an unused symmetry in its lattice structure that cut the key-recovery work factor from 2^64 to 2^38. ML-KEM and ML-DSA were unaffected, and that distinction matters, but the governance lesson does not depend on which scheme fell: a selection process years deep can still lose a candidate inside a week (tracked in SITG-Consulting's Quantum Weekly). An organisation that treats this migration as a one-off project will be back at the start of a second one within the decade.

Crypto-agility means the tested ability to swap an algorithm in production, not a capability claimed on a slide. Hybrid deployment, pairing a classical algorithm with its post-quantum counterpart in the same handshake so a break in either scheme alone does not compromise the session, is the credible bridge for systems that cannot move in one step. It is already shipped, not experimental: OpenSSL 3.5 arrived on 8 April 2025 carrying ML-KEM, ML-DSA and SLH-DSA natively, and OpenSSH 10.0 followed the next day, making the hybrid X25519/ML-KEM-768 exchange its default.

Execution has to run in waves, mapped to the exposure calculation rather than to whichever system is easiest to touch first. The data with the longest shelf life and the shortest remaining runway against Z moves first. That is a sequencing decision, not a convenience decision, and it belongs on the same page as the CBOM rather than in an engineering backlog nobody above delivery level ever reads.

None of this is infrastructure work a board can delegate downward and forget. Fiduciary liability attaches to a known, dated, quantified risk that was not acted on inside a stated regulatory window. A CBOM, a phased migration plan and a named board-level accountability line are the difference between a governance record that withstands scrutiny and a shadow crypto estate discovered during due diligence, litigation or a breach investigation, which is a considerably more expensive way to find out what was still running RSA.

The question worth asking this week

Every date above was set by a body that does not need your organisation's cooperation to be right. The open variable is not whether the deadlines move. It is whether your migration plan was built against them, or against an internal estimate nobody has stress-tested against Z. A board that can state its CBOM coverage, its wave sequencing and its 2030 exposure position in one sentence has done the work. A board that cannot has a compliance date and no plan against it. Key sizes tripled and quadrupled for a reason. The question is whether your infrastructure, your contracts and your board pack were built to notice.