2026-07-13 • 13 Min Read
Post-Quantum Cryptography: Preparing Regulated Finance for Q-Day
A sufficiently large quantum computer will break the public-key cryptography that protects today's payments, PKI, and confidential records. The migration is not a future IT ticket — because of "harvest now, decrypt later," the data you encrypt this year is already exposed. Here is a pragmatic, risk-based playbook.
The Clock Has Already Started
It is tempting to file quantum risk under "someday." A cryptographically relevant quantum computer capable of running Shor's algorithm against 2048-bit RSA does not yet exist publicly, and credible estimates place it somewhere in the next decade. But the deadline that matters is not the day that machine switches on. It is today.
The reason is a strategy known as harvest now, decrypt later. An adversary with the patience and storage to record encrypted traffic — cross-border payment messages, customer records, intellectual property — can simply archive it and wait. The moment a capable quantum computer becomes available, every harvested session encrypted with classical public-key cryptography can be retroactively opened. For a bank, a payment instruction loses sensitivity in days, but a mortgage record, a merger document, or a customer's identity data must stay confidential for decades.
That mismatch is the whole problem. If your data must remain secret for fifteen years and a quantum computer is plausible within ten, then anything you encrypt today is already inside the exposure window.
The Clock Has Already Started
Share of data encrypted in 2026 that remains confidentiality-sensitive over time
New Algorithms, New Constraints
In 2024 NIST finalized the first post-quantum standards: ML-KEM (FIPS 203, key encapsulation, derived from CRYSTALS-Kyber) and ML-DSA (FIPS 204, digital signatures, derived from CRYSTALS-Dilithium), with SLH-DSA as a hash-based backup. These are not experimental; they are the algorithms regulators and standards bodies now expect you to adopt.
The catch is engineering, not theory. Post-quantum keys and signatures are substantially larger than the elliptic-curve cryptography they replace. A larger handshake means more bytes on every TLS connection, fatter certificate chains, and real pressure on constrained environments — smart cards, HSMs, payment terminals, and embedded devices with fixed memory. A migration that looks like a library upgrade on a web server can be a hardware refresh on the edge.
New Algorithms, New Constraints
Public-key size in bytes — classical vs. NIST post-quantum schemes
You Can't Migrate What You Can't See
The single biggest predictor of a smooth migration is whether an organization knows where its cryptography actually lives. In most banks it is everywhere and catalogued nowhere: hard-coded in legacy applications, baked into firmware, embedded in third-party libraries, and scattered across certificates whose owners left years ago.
Before any algorithm changes, you need a cryptographic bill of materials — an inventory of every algorithm, key length, certificate, and protocol in use, mapped to the data it protects. This is the foundation of crypto-agility: the architectural ability to swap cryptographic primitives without re-engineering the systems around them. Organizations that abstract cryptography behind well-defined interfaces today will absorb not just this migration but the next one.
You Can't Migrate What You Can't See
Where cryptography typically lives across a banking technology estate
A Phased, Risk-Based Roadmap
Post-quantum migration is not a single cutover; it is a multi-year programme that overlaps discovery, prioritization, and deployment. The pragmatic pattern is to begin with strategy and inventory, then move to a hybrid posture in which classical and post-quantum algorithms run together, so a weakness in either one does not break confidentiality. Only once hybrid deployments are proven do you retire classical algorithms entirely.
Sequencing matters because resources are finite and the regulatory clock — including supervisory expectations under DORA for operational resilience — is running. A realistic roadmap front-loads the unglamorous discovery work, because every later phase depends on it.
A Phased, Risk-Based Roadmap
A phased migration roadmap toward crypto-agility, 2026–2031
Prioritize by Data Longevity
Not all systems deserve equal urgency. The right lens is two-dimensional: how sensitive is the data, and how long must it stay confidential? A public marketing API protected by TLS that rotates keys hourly is low-risk; a repository of customer identity data that must remain private for twenty years is exactly what harvest-now-decrypt-later targets.
Mapping systems onto this grid turns an overwhelming estate-wide problem into a ranked queue. Long-lived, highly sensitive data migrates first; short-lived or low-sensitivity workloads can follow as part of routine lifecycle upgrades.
Prioritize by Data Longevity
Migration priority by data sensitivity and required confidentiality lifetime
Crypto-Agility Is the Real Deliverable
It is worth naming the strategic prize. The goal of this programme is not merely to replace RSA with ML-KEM; it is to build an organization that can change cryptographic algorithms as a routine, low-drama operation. Quantum computing is the forcing function, but the capability you build — discoverable, abstracted, swappable cryptography — is what protects you against the threats that come after it.
Banks that treat post-quantum readiness as a one-off compliance exercise will do this painfully, once. Banks that treat it as the moment to invest in crypto-agility will be ready for Q-Day, for the next standard, and for whatever follows. The clock has started; the advantage goes to whoever inventories first.