Sebastien Rousseau
Get in touch ›

Securing the Ledger: A Board-Level Guide to Post-Quantum Migration for Corporate Finance

Quantum risk has moved from research curiosity to active regulatory mandate. With the G7 roadmap published in January 2026 and the BIS Project Leap proving feasibility in live payment systems, the board-level question is no longer whether to migrate — it is whether the migration can be completed before the shelf-life of today's data expires.

23 min read

Quantum risk has moved from research curiosity to active regulatory mandate. With the G7 roadmap published in January 2026, the EU, UK, and Australian timelines clarified, and the BIS Project Leap proving feasibility in live payment systems, the question for boards is no longer whether to migrate — it is whether the migration can be completed before the cryptographic shelf-life of today's data expires.

Key Takeaways

  • 2026 is the year the regulatory posture hardened. The G7 Cyber Expert Group's January roadmap, the EU NIS Cooperation Group's coordinated timeline, and the UK NCSC's three-phase plan have moved the conversation from awareness to execution. The Australian Signals Directorate has gone further still, setting a hard 2030 end-date for classical asymmetric cryptography.
  • The exposure is asymmetric. RSA, ECC, and Diffie–Hellman are the immediate problem — the asymmetric algorithms underpinning SWIFT handshakes, TLS, PKI, code signing, and clearing-network authentication. Symmetric encryption (AES-256) remains stable if key lengths are maintained. The board-level focus must be on the asymmetric surface.
  • Harvest-now-decrypt-later is not a future scenario. Adversaries are intercepting and storing encrypted financial logs, settlement records, M&A material, and cross-border wire data today, with the explicit intention of decrypting once a cryptographically relevant quantum computer (CRQC) exists. For data with a 10–20 year confidentiality requirement, that risk is already realised.
  • The industry now has a working reference point. BIS Project Leap Phase 2 ⧉, published December 2025, successfully replaced traditional digital signatures with post-quantum cryptography in live liquidity transfers across TARGET2 — and surfaced the specific engineering costs (verification latency, packet size) that every migration programme will face.
  • The NIST suite is the global anchor. FIPS 203 (ML-KEM) ⧉ and FIPS 204 (ML-DSA) are referenced by every major jurisdiction, even where national positions diverge on parameter sets and hybrid requirements. Boards should treat ML-KEM-768/ML-DSA-65 as the floor and ML-KEM-1024/ML-DSA-87 as the conservative baseline for long-lived data.
  • Hybrid is the only credible path. Pure cut-overs are not advised by any major authority. Running classical and quantum-resistant algorithms in parallel is the deployment pattern endorsed by NCSC, ANSSI, BSI, and proven in Project Leap. It is heavier than either alternative, but it is the only one that addresses both today's compatibility and tomorrow's threat.

The Year the Regulatory Posture Hardened #

For most of the past decade, post-quantum cryptography lived in a comfortable corner of the long-term roadmap. Quantum computers were impressive but distant; the cryptographic mathematics underpinning RSA and elliptic curves was treated as a stable substrate; and the migration conversation was largely confined to specialist working groups. That position is no longer tenable.

In January 2026, the G7 Cyber Expert Group published its most consequential statement to date ⧉, co-chaired by the US Treasury and the Bank of England. The document is not regulation, but it carries more weight than typical guidance: it represents the shared view of finance ministries, central banks, and supervisory authorities across G7 jurisdictions that cryptographic transition is now a systemic risk-management issue. The roadmap aligns its planning horizon around the mid-2030s, with critical financial systems encouraged to migrate earlier — language that, in the careful idiom of central bankers, signals expectation rather than suggestion.

Two months earlier, the BIS Innovation Hub and the Eurosystem published the results of Project Leap Phase 2 ⧉, a technical experiment that replaced traditional digital signatures with post-quantum cryptography in live liquidity transfers between the Bank of Italy, the Banque de France, the Deutsche Bundesbank, Nexi-Colt, and Swift. The headline finding was a success — quantum-resistant signed transfers passed end-to-end through an operational payment system. The detail beneath the headline is more instructive, and it is examined later in this article.

The combination of these two events — a coordinated G7 policy framework and a working proof point in a real payment system — has produced what the technical community has been waiting a decade for: a definitive answer to the question "is this real?" The answer, in May 2026, is yes. The remaining question is one of pace.

Three Threat Vectors That Should Concern the Board #

Before discussing migration mechanics, it is worth being precise about what specifically is at risk. Quantum risk in corporate banking is not uniform across the cryptographic estate, and the board's attention is best directed at the three vectors where the exposure is most acute.

1. Harvest Now, Decrypt Later (HNDL) #

The most immediate concern is not future. It is present. State-level and sophisticated criminal adversaries are systematically intercepting and storing encrypted financial traffic — wire transfers, SWIFT message flows, M&A communications, cross-border settlement logs, swap agreements, and KYC files — with no current ability to read them. Their objective is straightforward: store now, decrypt later, once a CRQC exists. As the Bank for International Settlements has explicitly noted ⧉, this collection is already happening.

For boards, the implication is uncomfortable but specific: any sensitive data transmitted under classical asymmetric encryption today, whose confidentiality requirement extends beyond the arrival of a CRQC, must already be considered exposed. There is no breach notification when HNDL occurs. There is no alarm in the SIEM. The encryption holds — for now — but the data has already left the perimeter.

2. Long-Term Sensitivity Risk #

Corporate banking data has unusually long institutional shelf lives. Strategic M&A documentation can remain market-sensitive for a decade. Trade-secret communications and intellectual property valuations may stay confidential for fifteen to twenty years. Cross-border settlement logs, central counterparty exposures, and counterparty credit assessments retain commercial sensitivity well beyond their immediate transactional life.

The Mosca equation ⧉, originally articulated by Michele Mosca and now embedded in every serious migration framework, formalises the problem. If S is the shelf life of the data, M is the time required to migrate the systems that protect it, and Q is the time until a CRQC is available, then:

If S + M > Q, the data is already exposed.

For data with a twenty-year confidentiality horizon and a migration programme realistically requiring five to seven years to complete, the implicit Q value the board is betting on is at least 25 years out. A growing body of expert assessment — Forrester's 2026 APAC predictions ⧉, the Global Risk Institute's annual surveys, and a February 2026 architecture paper proposing CRQC at approximately 100,000 physical qubits using QLDPC codes — suggests that bet is unsafe.

3. The Vulnerability of Core Handshakes #

The third vector is the most architecturally significant. Symmetric ciphers (AES-256) remain comparatively stable; Grover's algorithm halves the effective security level, but doubling key length restores margin. The catastrophic exposure is to asymmetric algorithms, and these are precisely the algorithms that underpin every authenticated handshake in corporate finance: RSA in SWIFT public-key infrastructure, ECDSA in TLS client/server authentication, ECDH in session key establishment, and ECC variants throughout client mobile authentication, API signatures, and code-signing pipelines.

A functional CRQC running Shor's algorithm does not gradually weaken these systems. It breaks them. Once a CRQC is operational, every RSA-protected handshake, every ECDSA signature, and every elliptic-curve key exchange becomes recoverable — not over months of effort, but in hours. The transition from "secure" to "compromised" is binary, and it propagates simultaneously across every system using the affected algorithm. This is the foundation on which the regulatory urgency rests.

Regulatory Tightening: A Jurisdiction-by-Jurisdiction View #

The global regulatory picture in May 2026 is no longer a patchwork of suggestions. It is a coordinated set of timelines that vary in stringency but converge on the same destination. A multinational bank operating across the major financial centres is now subject to the most stringent applicable jurisdiction, not the most lenient.

United States #

The US has the most prescriptive position for any institution touching federal systems. The NSA's Commercial National Security Algorithm Suite 2.0 ⧉ mandates ML-KEM-1024 and ML-DSA-87 for national security systems, with new systems required to deploy PQC from January 2027 and complete infrastructure migration by 2035. OMB Memorandum M-23-02 binds federal agencies to the same trajectory. For commercial banks, the immediate exposure is through federal procurement chains, NSS-adjacent contracts, and the indirect pressure that NSA guidance places on the broader market.

European Union #

The EU is operating on three layers. The European Commission's Coordinated Implementation Roadmap ⧉, elaborated by the NIS Cooperation Group in June 2025, sets phased milestones at 2026 (national strategies), 2030 (high-risk systems migrated), and 2035 (full transition). The Cyber Resilience Act will mandate state-of-the-art security upgrades for digital products from the end of 2027. NIS2 reinforces ICT risk management, although neither directive contains an explicit PQC requirement. National regulators, however, have moved ahead of the Commission. Germany's BSI mandates hybrid key exchange and approves a conservative basket of ML-KEM, FrodoKEM, and Classic McEliece. France's ANSSI requires hybrid for both key encapsulation and signatures. The Netherlands NLNCSA and Norway's authorities have aligned around ML-KEM-1024 as the conservative baseline for long-lived data.

United Kingdom #

The UK NCSC published its definitive guidance in March 2025 and reaffirmed it through the 2025 Annual Review. The three-phase timeline is explicit:

For UK financial institutions, the CMORG (Cross-Market Operational Resilience Group) PQC Guidance ⧉ sits alongside the NCSC framework, treating banks as critical national infrastructure and emphasising vendor readiness and supply-chain alignment.

Asia-Pacific #

The APAC posture is more fragmented but moving fast. Australia's ASD has the hardest position globally: classical public-key cryptography must not be used beyond the end of 2030, no hybrid recommendation, and ML-KEM-1024 required (ML-KEM-768 acceptable only until 2030). Organisations should have a refined transition plan by end-2026. Singapore's Monetary Authority has issued formal quantum-safe readiness guidance. Japan and South Korea are investing substantially, though both have national algorithm tracks (Korea has selected NTRU+ and SMAUG-T as KEMs, ALMer and HAETAE as signatures). India's National Quantum Mission, backed by a Rs. 6,003.65 crore government outlay, explicitly identifies banking and financial systems as a strategic priority. Forrester's 2026 APAC predictions ⧉ put the number of regional enterprises expected to invest in post-quantum technologies this year at more than 90%.

The Net Position #

For a board, the practical synthesis of these jurisdictional positions is straightforward. A multinational bank cannot manage to any single regulator's timeline; it must manage to the most stringent applicable. For most major institutions, that means a planning horizon of end-2030 for high-risk systems and end-2035 for the long tail — with ASD-exposed entities targeting pure-PQC by 2030 and CNSA-exposed entities targeting the same window with ML-KEM-1024 and ML-DSA-87 specifically.

BIS Project Leap: What the Industry Has Actually Proved #

Project Leap is worth a board's attention not because it is a marketing milestone but because it is the most credible end-to-end demonstration of post-quantum cryptography in a live financial payment system to date. The headline conclusion is straightforward: it works. The detail beneath is where the operational implications sit.

Phase 1, completed in 2023, established a quantum-resistant VPN between IT systems at the Bank of France and the Deutsche Bundesbank, with payment messages transmitted between Paris and Frankfurt under a hybrid encryption scheme. Phase 2, completed in late 2025 and reported in December ⧉, went considerably further. The consortium replaced traditional RSA-based digital signatures with post-quantum signatures in the execution of liquidity transfers across TARGET2, the Eurosystem's Real-Time Gross Settlement system. The participants — the BIS Innovation Hub Eurosystem Centre, the Bank of Italy, the Banque de France, the Deutsche Bundesbank, Nexi-Colt (which provides TARGET2 connectivity), and Swift — represent precisely the institutions whose infrastructure must eventually migrate.

The report flagged three findings that every migration programme should internalise:

For a CFO reviewing a PQC business case, the Project Leap findings are useful precisely because they are precise. The cost of post-quantum migration is not a single capital line. It is verification latency that ripples through SLA contracts, message-size expansion that touches storage and bandwidth budgets, and a transitional period of duplicated cryptographic operations that affects compute capacity planning. None of these are speculative. They have been measured in a live central-bank system.

The NIST Toolkit: ML-KEM and ML-DSA Compared #

The technical centrepiece of every credible national framework is the NIST suite of post-quantum standards published in August 2024. Two of these standards are the immediate focus for corporate banking: ML-KEM (FIPS 203) for key encapsulation and ML-DSA (FIPS 204) for digital signatures. They share a mathematical foundation — both rely on the hardness of Module Learning With Errors (ML-LWE) and Module Short Integer Solution problems over structured lattices — but they serve very different roles in the cryptographic estate, and their performance and size profiles differ materially.

ML-KEM (FIPS 203) — Key Encapsulation #

ML-KEM, derived from CRYSTALS-Kyber, is the replacement for ECDH and RSA-KEM in protocols where two parties need to establish a shared symmetric key over an insecure channel. It is, in practical terms, where TLS handshakes go after RSA and ECDH are retired. NIST defines three parameter sets at increasing security strength and decreasing performance: ML-KEM-512 (NIST Category 1), ML-KEM-768 (Category 3), and ML-KEM-1024 (Category 5).

ML-DSA (FIPS 204) — Digital Signatures #

ML-DSA, derived from CRYSTALS-Dilithium, is the replacement for RSA and ECDSA signatures. It handles certificate signing, code signing, document signing, and authentication. The three parameter sets are ML-DSA-44, ML-DSA-65, and ML-DSA-87, corresponding broadly to NIST Categories 2, 3, and 5.

Size and Performance Profile #

For a CIO scoping migration capacity, the most important figures are the artefact sizes. These are the inputs to network capacity planning, storage projections, and protocol-level testing.

Algorithm Public Key Ciphertext / Signature Closest Classical Equivalent Size vs Classical
ML-KEM-512 800 bytes 768 bytes (ciphertext) ECDH P-256 (~32 bytes pub key) ~25× larger
ML-KEM-768 1,184 bytes 1,088 bytes (ciphertext) ECDH P-384 ~25× larger
ML-KEM-1024 1,568 bytes 1,568 bytes (ciphertext) ECDH P-521 ~25× larger
ML-DSA-44 1,312 bytes ~2,420 bytes (signature) ECDSA P-256 (64-byte sig) ~38× larger
ML-DSA-65 1,952 bytes ~3,293 bytes (signature) ECDSA P-384 ~50× larger
ML-DSA-87 2,592 bytes ~4,595 bytes (signature) ECDSA P-521 ~70× larger

Source: Synthesis of NIST FIPS 203 ⧉ and FIPS 204 specifications, with comparative data from independent benchmarking literature.

Three operational implications follow directly. First, signature size is the binding constraint for most enterprise deployments. An ML-DSA-65 signature is approximately fifty times the size of an ECDSA P-256 signature, and TLS certificate chains carrying intermediate CAs grow proportionally. Capacity work on this surface is not optional — it is load-bearing. Second, ML-KEM is computationally competitive with ECDH and in some implementations meaningfully faster, particularly on hardware with vectorised support for the underlying lattice arithmetic. Third, ML-DSA verification is consistently fast (often faster than ECDSA verification), but ML-DSA signing involves a rejection-sampling loop that can require multiple attempts on constrained hardware. For high-throughput signing services, this is a benchmark to verify rather than assume.

Choosing Parameter Sets #

The jurisdictional positions on parameter selection are not identical, but the convergence is clear. ML-KEM-768 and ML-DSA-65 are the enterprise floor — endorsed by UK NCSC as the baseline for UK organisations and acceptable under most European frameworks. ML-KEM-1024 and ML-DSA-87 are the conservative ceiling — mandated by NSA CNSA 2.0 for US national security systems and required by ASD for Australian regulated entities by 2030. For data with extreme long-term sensitivity — sovereign settlement logs, decade-plus intellectual property, custody records for long-dated instruments — the higher parameter sets are the defensible default.

A Shared Mathematical Foundation, A Shared Risk #

A board-level point worth noting: both ML-KEM and ML-DSA derive their security from the same family of lattice problems. A future cryptanalytic breakthrough against Module-LWE would affect both standards simultaneously. This is precisely why several national authorities — notably Germany's BSI and France's ANSSI — recommend complementing the lattice-based stack with hash-based signatures (SLH-DSA, FIPS 205) for long-term signing and code-signing use cases. Crypto-agility, in this sense, is not just about being able to swap RSA for ML-KEM. It is about being able to swap one PQC algorithm for another when the cryptanalytic landscape shifts.

A Logical Migration Path: Discovery → Triage → Hybrid Deployment #

For a board approving a multi-year PQC programme, the operational question is how to phase the work without taking unacceptable service-availability risk. The pattern that has emerged across the G7 roadmap, the NCSC framework, BIS Project Leap, and the major national guidance documents converges on three phases.

┌──────────────────────┐   ┌──────────────────────┐   ┌──────────────────────┐
│  1. DISCOVERY & CBOM │ → │  2. TRIAGE (MOSCA)   │ → │  3. HYBRID DEPLOYMENT│
│  Cryptographic       │   │  Risk-based          │   │  Dual-envelope       │
│  inventory across    │   │  prioritisation by   │   │  classical + PQC,    │
│  all systems         │   │  data shelf life     │   │  crypto-agile        │
└──────────────────────┘   └──────────────────────┘   └──────────────────────┘

Phase 1 — Discovery and the Cryptographic Bill of Materials (CBOM) #

Migration cannot be planned for a cryptographic estate that has not been mapped, and most institutions do not have an accurate map. The first phase is therefore the production of a Cryptographic Bill of Materials — a structured inventory of every instance of asymmetric cryptography across the organisation, with each instance tagged for algorithm, key length, protocol context, data sensitivity, and system owner. Automated scanning across codebases, web applications, container images, database configurations, certificate stores, hardware security modules, and vendor interfaces is the practical mechanism; manual inventory of legacy systems and proprietary protocols is the unavoidable supplement.

The output of Phase 1 is not glamorous, but it is the only foundation on which Phases 2 and 3 can rest. It is also the deliverable that most internal audit functions and external regulators will look for first when PQC compliance attestations start being requested.

Phase 2 — Risk Triage Using the Mosca Equation #

With the CBOM in hand, the institution can apply Mosca's framework asset by asset. For each cryptographic dependency, the question is whether S + M > Q — whether the data's shelf life plus the migration time exceeds the estimated time to a CRQC. Assets where the inequality is most acute — long-lived sensitive data on infrastructure that takes years to migrate — go to the front of the queue. Assets with short data lifespans or already-modernised infrastructure can be sequenced later in the programme.

This is the phase where the board's risk appetite is most visible. The Q value the institution chooses to plan against is, in effect, a strategic bet on the rate of quantum hardware progress. A conservative Q (mid-2030s) produces a more aggressive migration plan and a higher near-term capital line. An optimistic Q (post-2040) produces a more relaxed plan and a higher residual exposure to data already being harvested. Neither is wrong; both should be explicit decisions of the board, not implicit defaults of the technology function.

Phase 3 — Hybrid Deployment #

Once priority assets are identified, deployment should follow the hybrid pattern proven in Project Leap and endorsed by NCSC, ANSSI, BSI, and the G7 roadmap. A hybrid deployment runs a classical algorithm and a post-quantum algorithm in parallel, combining their outputs into a single envelope. The composite is secure against both classical attacks (the classical algorithm holds today) and quantum attacks (the PQC algorithm holds tomorrow). Specifically, the common pattern is X25519 combined with ML-KEM-768 or ML-KEM-1024 for key encapsulation, and ECDSA combined with ML-DSA for signatures where dual signatures are operationally feasible.

The Project Leap finding that hybrid is "much, much heavier" than either pure approach is the honest counterweight to this recommendation. Boards should expect compute and storage capacity uplift, longer handshakes, and additional certificate-chain complexity during the transition. The trade-off is that hybrid removes the single largest source of migration risk: the cliff-edge cut-over from one cryptographic foundation to another in a production environment.

What This Costs and Why Doing Nothing Costs More #

Mastercard's analysis, reported in early 2026 ⧉, put global financial-sector PQC migration cost at $28–42 billion. Within that aggregate, the RedCompass Labs and CMORG research ⧉ tracking actual institutional spend suggests tier-one banks are committing $20–30 million annually to readiness programmes, with implementation timelines spanning multiple leadership cycles. These are substantial numbers. They are not, however, the relevant comparison.

The relevant comparison is the cost of a single retrospective decryption event. For an institution whose harvested wire traffic, M&A correspondence, or counterparty exposure data becomes readable to an adversary in 2032, the operational and reputational cost is not bounded by the migration capex line. It is bounded by the value of the underlying decade of strategic information — which, for any systemically important institution, is materially larger than any plausible migration budget. The G7 framing of cryptographic transition as a systemic risk-management issue rather than a technology upgrade is correct, and boards should engage with it on that basis.

There is a second cost line worth separating. Migration to PQC is a forcing function for crypto-agility — the architectural capability to swap cryptographic algorithms without rebuilding the systems that depend on them. Most institutions do not currently have crypto-agility; their RSA and ECC dependencies are deeply embedded in PKIs, code-signing chains, vendor integrations, and bespoke protocols that have accumulated over decades. The investment in agility, made under the pressure of the PQC transition, is durable. It will be drawn upon again when the next cryptographic transition arrives — whether that is a successor to lattice-based PQC, a quantum-key-distribution overlay, or something not yet on the standards roadmap. Treated correctly, the PQC migration capex is a one-time investment that yields recurring optionality.

Conclusion #

The case for treating post-quantum migration as a 2026 board-level priority is not built on the imminence of a CRQC. Estimates of that remain genuinely uncertain — credible scholarly opinion places the probability of a CRQC by 2028 at well under one per cent, rising to roughly fifty per cent by 2037–2040. The case is built on three other observations that are not uncertain.

First, harvest-now-decrypt-later is happening today, and data with a decade-plus confidentiality requirement is exposed regardless of when the CRQC arrives. Second, migration of a major financial institution's cryptographic estate takes five to seven years even with adequate funding and leadership focus — meaning the programme begun in 2026 finishes around 2031, which is well within the conservative end of the CRQC probability distribution. Third, regulatory expectations have hardened materially in the last twelve months, and the institutions whose 2026 board minutes record a clear PQC programme will be in a meaningfully stronger position than those whose minutes record a watching brief.

The institutions that begin now have the advantage of choice. They can sequence the work across leadership cycles, integrate it with broader resilience initiatives, and absorb the operational costs of hybrid deployment within normal capital planning. The institutions that wait will face the same work under tighter deadlines, with less scope for sequencing, and against the backdrop of supply constraints on PQC-capable hardware, expertise, and vendor capacity. The cost of acting early is known; the cost of acting late is asymmetric in precisely the way risk management is designed to avoid.

For prior context on this site, the April 2026 piece on quantum threshold compression examined the underlying hardware trajectory, the November 2023 analysis of CRYSTALS-Kyber covered the mathematical foundations now standardised as ML-KEM, the December 2023 article on Quantum Key Distribution addressed the complementary QKD overlay, and the KyberLib open-source reference implementation provides a working Rust implementation of the underlying primitives for institutions wanting to inspect the cryptographic surface directly. Engagement with the practical and technical detail — not just the regulatory headlines — is how boards distinguish credible migration programmes from compliance theatre.

Frequently Asked Questions #

When will a cryptographically relevant quantum computer actually exist?

Credible estimates vary widely. As of early 2026, public quantum demonstrations have achieved roughly 24 to 28 logical qubits, while a CRQC is estimated to require approximately 6,000 logical qubits underpinned by something between 100,000 and several million physical qubits, depending on the error-correction approach. Expert consensus places CRQC probability under one per cent by 2028, around fifty per cent by 2037–2040, with significant variability across forecasts. Recent reductions in theoretical resource estimates — from 20 million qubits a few years ago to under one million in Gidney's 2025 work, and to approximately 100,000 in the February 2026 QLDPC architecture paper — have compressed the planning horizon. For board purposes, the appropriate planning assumption is mid-2030s for high-risk systems, end-2030s as a conservative midpoint, and earlier if HNDL exposure is the binding concern.

Why hybrid deployment rather than pure post-quantum?

Three reasons. First, ML-KEM and ML-DSA, while well-vetted, have shorter cryptanalytic histories than RSA and ECC. A hybrid scheme remains secure if either component holds; a pure PQC scheme is exposed if the lattice problem is unexpectedly weakened. Second, hybrid preserves backward compatibility with counterparties that have not yet migrated — critical in a multi-year industry transition. Third, every major authority outside the Australian Signals Directorate explicitly recommends hybrid for the transition period: NCSC, ANSSI, BSI, NLNCSA, and the G7 framework all endorse the dual-envelope approach. The trade-off, as Project Leap quantified, is meaningfully higher compute and storage overhead. That is the price of optionality.

Do we need both ML-KEM and ML-DSA, or can we choose one?

Both. ML-KEM and ML-DSA serve different cryptographic roles. ML-KEM replaces the key-establishment primitives in TLS, VPNs, mobile authentication, and similar protocols where two parties need to agree a shared symmetric key. ML-DSA replaces the digital-signature primitives in PKI certificates, code signing, document signing, SWIFT-style authenticated messaging, and identity assertions. An institution's cryptographic estate uses both kinds of primitive in different places; the migration must address both. ML-DSA's significantly larger signature size (50–70× ECDSA) is usually the more operationally demanding of the two; the network and storage planning work for ML-DSA dominates most migration capacity assessments.

How do we measure progress on a programme this large?

Three metrics are practical and align with the major regulatory frameworks. Coverage of the CBOM — what percentage of the institution's asymmetric cryptographic instances have been inventoried, classified, and tagged for migration priority. Migration coverage of high-risk assets — what percentage of assets where Mosca's S + M > Q condition holds have been moved to hybrid PQC. Crypto-agility coverage — what percentage of cryptographic-dependency systems can swap algorithms without code changes, configuration-only. The G7 CEG roadmap, the NCSC three-phase framework, and the EU coordinated roadmap all map to roughly these three measures, even where they use different terminology.

What is the cost of waiting another year?

It is not zero, and it is not symmetric. Waiting one year forfeits a year of HNDL protection on long-lived data — data whose confidentiality requirement extends to 2040 is exposed for a year longer than necessary. It compresses the migration window against fixed regulatory deadlines (ASD 2030, NSA CNSA 2.0 milestones, EU 2030 critical-systems target), which translates into higher delivery risk and reduced sequencing flexibility. It exposes the institution to vendor and talent supply constraints that are already visible in the market and will worsen as the industry's largest players move from planning to execution. The cost is not catastrophic in any single year, but it compounds, and the regulatory environment is converging on a position where boards will be expected to explain the delay rather than the spend.

References #

Last reviewed .