Sebastien Rousseau

The Quantum-Safe Banking Index in 2026: Post-Quantum Cryptography, QKD, Crypto-Agility, and Harvest-Now-Decrypt-Later Risk

Quantum risk has moved from theoretical threat to migration programme: banks need to measure cryptographic exposure, migration readiness, and crypto-agility.

8 min read
Banner for: The Quantum-Safe Banking Index in 2026: Post-Quantum Cryptography, QKD, Crypto-Agility, and Harvest-Now-Decrypt-Later Risk

Quantum-safe banking in 2026 is about operational migration, not speculation. NIST has finalised the first three post-quantum cryptography standards, and banks must now understand which systems depend on RSA, ECC, TLS, signatures, HSMs, certificates, payment channels, archives, and long-lived confidential data. The index question is simple: can the institution replace cryptography before the threat becomes operational?


Executive Summary / Key Takeaways

  • NIST standards are now concrete. FIPS 203 defines ML-KEM for key encapsulation, FIPS 204 defines ML-DSA for signatures, and FIPS 205 defines SLH-DSA as a stateless hash-based signature standard.
  • Inventory is the first maturity gate. A bank cannot migrate what it cannot find: certificates, keys, protocols, applications, vendors, HSMs, APIs, archives, and embedded systems must be mapped.
  • Crypto-agility is the durable objective. The goal is not a one-time algorithm swap; it is the ability to change cryptographic primitives without redesigning entire applications.
  • Long-lived data changes urgency. Harvest-now-decrypt-later risk means data captured today may become readable later if it remains valuable long enough.
  • QKD is a specialised complement. Quantum key distribution may be relevant for the highest-value channels, but it does not replace institution-wide PQC migration.

Why 2026 Is the Year This Index Matters #

Three shifts in 2024-2025 made quantum-safe a measurable bank programme rather than a research watchpoint. First, NIST finalised the primary post-quantum standards on 13 August 2024: FIPS 203 (ML-KEM) ⧉, FIPS 204 (ML-DSA) ⧉, FIPS 205 (SLH-DSA) ⧉. The algorithm-selection debate closed on that date; banks still running internal "which scheme wins" workstreams in 2026 are 18 months out of date.

Second, the NSA's CNSA 2.0 ⧉ set the US federal end-state at 2033 with intermediate cutoffs starting in 2027 for software and firmware signing, 2030 for browsers and operating systems. Any bank with US federal counterparty exposure — FedNow, Treasury operations, federal customer accounts — sits inside that perimeter for the systems that touch federal data. The clock is no longer abstract.

Third, Harvest-Now-Decrypt-Later (HNDL) ⧉ is the load-bearing risk argument for urgency. Sophisticated adversaries are already capturing TLS-protected payment messages, SWIFT envelopes, KYC documentation, and long-lived archive ciphertext at major financial centres. The data captured in 2026 only needs to remain confidentiality-sensitive at the moment of decryption — for 30-year mortgages, life-insurance underwriting, MiFID II / GDPR transaction recordings, and M&A retention archives, that window extends well past every credible estimate for a Cryptographically Relevant Quantum Computer (CRQC). The adversary does not need a quantum computer today. They need one before the data stops mattering.

The Quantum-Safe Banking Index measures whether your institution can ship the migration before that intersection arrives. The work is no longer about whether to migrate; it is whether the migration completes on a defensible timeline.

The 2026 Index Architecture #

Index Layer 2026 Direction Readiness Metric Risk if Mishandled
Inventory Map cryptographic assets, protocols, certificates, vendors, and data classes Percentage of estate inventoried Unknown quantum-vulnerable dependencies
Exposure Classify systems by confidentiality lifetime and transaction criticality High-risk assets by value and lifetime Misprioritised migration
Migration Adopt hybrid and PQC-ready patterns aligned to NIST standards ML-KEM and ML-DSA readiness Emergency re-platforming under deadline
Crypto-agility Separate application logic from cryptographic primitives Policy-controlled crypto coverage Hard-coded algorithms across the estate
Assurance Test interoperability, performance, HSM support, certificates, and vendor readiness Test pass rate and exception backlog Broken channels or weak fallback controls

The Board-Level Quantum Scorecard #

A credible quantum readiness scorecard requires tracking exact percentages, not just project statuses:

  1. Inventory Completeness: The percentage of tier-1 applications with a fully mapped Cryptographic Bill of Materials (CBOM).
  2. HNDL Exposure: The volume of long-lived confidential data (e.g., PII, trade secrets) transmitted over networks without hybrid quantum-safe key encapsulation.
  3. NIST Migration Progress: The percentage of asymmetric encryption keys and digital signatures migrated to FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) standards.
  4. Crypto-Agility Readiness: The percentage of critical systems where cryptographic algorithms can be rotated via centralized policy without requiring code recompilation.

Current Signals to Track #

Signal What It Means for Banks Source
FIPS 203 ML-KEM Primary NIST standard for general encryption key establishment NIST ⧉
FIPS 204 ML-DSA Primary NIST standard for digital signatures NIST ⧉
FIPS 205 SLH-DSA Hash-based signature alternative and backup design NIST ⧉
Immediate integration encouraged NIST explicitly tells administrators to start integrating standards because full integration takes time NIST ⧉
Bank quantum programmes are expanding Major banks are exploring quantum technologies while preparing PQC transitions Quantum Insider ⧉

The Migration Starts With the Ledger of Cryptography #

Photograph of a control-room dashboard mapping cryptographic primitives across a bank's TLS endpoints, HSM partitions, certificate authorities, and long-lived data archives — the visual register of a Cryptographic Bill of Materials.

The migration sequence is well-understood at this point. Each gate produces evidence that drives the next; skipping or compressing a gate is what generates the emergency re-platforming risk that shows up in the Index Architecture failure column.

flowchart LR
    A["Discovery<br/>CycloneDX CBOM<br/>scanners + CMDB"] --> B["Exposure model<br/>lifetime × capture<br/>× CRQC horizon"]
    B --> C["Hybrid TLS 1.3<br/>X25519MLKEM768<br/>external endpoints"]
    C --> D["HSM PQC firmware<br/>vendor-by-vendor<br/>roadmap rollout"]
    D --> E["Crypto-agility<br/>PKCS#11 + policy<br/>registry + kill switch"]
    E --> F["Pure PQC<br/>2028+<br/>conformance + audit"]

    style A fill:#eff5ff,stroke:#0056b3,color:#111
    style B fill:#eff5ff,stroke:#0056b3,color:#111
    style C fill:#fff4cf,stroke:#5a3e00,color:#111
    style D fill:#fff4cf,stroke:#5a3e00,color:#111
    style E fill:#e8f5e9,stroke:#1b5e20,color:#111
    style F fill:#e8f5e9,stroke:#1b5e20,color:#111

The first deliverable is not a new algorithm; it is a cryptographic bill of materials (CBOM). Banks need a living inventory that connects business services to algorithms, libraries, certificates, key lengths, HSMs, data lifetimes, vendors, and operational owners. Without that ledger, quantum-safe migration becomes guesswork.

The CBOM record set should capture, for each cryptographic primitive: the protocol or interface (TLS 1.3, IPsec, SSH, custom payment-message format), the algorithm and parameter set (RSA-2048, ECDH P-256, ML-KEM-768, ML-DSA-65), the library and version (OpenSSL 3.4, BoringSSL commit hash, vendor SDK build), the hardware boundary (HSM partition, TPM, secure enclave, or none), the certificate identity if applicable, the application owner, and the data-classification lifetime. Tools landing in production in 2025-2026 — IBM Quantum Safe Inventory, the open-source CycloneDX CBOM specification ⧉, enterprise scanners from CryptoNext / Sandbox / PQShield — integrate into existing CMDB pipelines. None of them is complete on its own; expect a 12-18 month CBOM build cycle even with vendor tooling and dedicated headcount.

The metric to track is freshness, not coverage. A CBOM that is two months out of date is worse than no CBOM at all because it gives the security team false confidence about what has been migrated.

Hybrid First, Agile Always #

Most banks will not switch everything at once. The realistic pattern is hybrid deployment, where classical and post-quantum mechanisms run together while vendors, protocols, certificates, and operational tooling mature. The long-term target is crypto-agility: policy-controlled cryptographic choices that can be changed without rebuilding the business application.

[Insert Interactive Component: Harvest-Now-Decrypt-Later (HNDL) Risk Calculator — A slider-based tool where executives input data shelf-life vs. estimated quantum timeline to see their exposure window.]

Key insight: If your data needs to remain confidential for 10 years, and a Cryptographically Relevant Quantum Computer (CRQC) is 7 years away, your migration deadline isn't in 7 years — it was 3 years ago.

In practice this means TLS 1.3 with the hybrid X25519MLKEM768 key share for externally-facing endpoints (Chrome / Firefox / Cloudflare / Akamai all support this today), classical signature chains until HSM and CA infrastructure catches up, and a PKCS#11 abstraction layer that lets the policy registry rotate algorithms without recompiling business applications. Crypto-agility is what determines whether the next algorithm transition (when, not if) is a six-week rotation or another seven-year programme.

Where QKD Fits #

Quantum key distribution belongs in the index as a high-sensitivity channel option, especially for financial-market infrastructure, central-bank connectivity, and extremely sensitive institutional flows. It should be treated as a complement to PQC, not as an excuse to delay enterprise migration.

What This Means by Bank Type #

Global Systemically Important Banks #

The hard problem is scale: tens of thousands of TLS endpoints, hundreds of HSM partitions, dozens of internal certificate authorities, hundreds of business applications with embedded cryptographic primitives, and vendor SDKs the bank cannot modify. The investment is not another pilot; it is the CBOM tooling, the PKCS#11 abstraction layer wired into every new build, the HSM consolidation plan that picks one vendor to lead on PQC firmware and accepts a multi-year tail on the others, and the policy registry that becomes the durable crypto-agility surface long after the FIPS 203 / 204 / 205 migration completes.

Transaction and Corporate Banks #

The migration scope is narrower than at G-SIB tier but the HNDL exposure is acute: SWIFT cross-border messaging, structured payment data carrying corporate-counterparty PII, document-exchange platforms holding trade-finance documentation, and long-retention reporting archives. Prioritise hybrid TLS on every customer-facing endpoint and PQC at rest for retention archives. Push HSM-vendor accountability — the corporate-banking platform team has direct procurement leverage that the wholesale technology team often lacks.

Regional Banks #

Buy the vendor stack that already has the crypto-agility primitives. Pick a core banking platform whose vendor publishes a CBOM and commits to ML-KEM / ML-DSA support timelines. Validate the vendor's HSM roadmap aligns with the bank's migration deadline. The engineering capacity required to build crypto-agility from scratch is multi-year; the vendor pays that cost across many customers and the bank inherits the benefit. The validation work — checking the vendor's claims survive the institution's MRM process — is the legitimate internal scope.

Fintechs, PSPs, and Infrastructure Providers #

The competitive question for vendors selling into banks in 2026 is not "do you support PQC." It is "can you produce a CycloneDX CBOM for your platform, an HSM-vendor support matrix, and a written algorithm-rotation SLA." Vendors who answer with yes will pass tier-1 procurement gates in 2026-2027. Vendors who cannot will lose the renewal cycle to a competitor that can.

Conclusion #

Quantum-safe banking in 2026 is not a research watchpoint; it is a delivery programme with a deadline set by the intersection of two curves — confidentiality lifetime of the data the institution holds today, and the arrival horizon of a Cryptographically Relevant Quantum Computer. The institutions that look credible to regulators and counterparties in 2030 are the ones that started CBOM construction in 2024, deployed hybrid TLS on every external endpoint by end-2026, and engineered crypto-agility into every new build from day one. The institutions that did not will discover whether their migration window has already closed for the data their adversary is harvesting today.

Measure the migration the way you measure any operational programme: scope known, sequencing prioritised, deadlines committed, exception registers honest. The harder you look at your own estate, the smaller the migration window feels.

Questions? Answers.

What should a bank inventory first?

Start with externally exposed TLS, payment channels, customer authentication, interbank connectivity, HSM-backed services, long-term archives, and systems handling confidential data with a long useful life.

Is PQC only a cybersecurity issue?

No. It affects payments, identity, legal evidence, transaction signing, customer trust, data retention, vendor management, and operational resilience.

What does crypto-agility mean?

Crypto-agility means the ability to change cryptographic primitives through policy and platform controls instead of hard-coded application changes.

Should banks wait for more standards?

No. NIST has encouraged administrators to begin integrating the first final standards because full integration takes time.

References #

Last reviewed .