No Q-Day Countdown: A Banking Migration Plan for Post-Quantum Cryptography

Map the cryptographic job before naming the algorithm

RSA and elliptic-curve cryptography are public-key families used for tasks such as establishing shared secrets, authenticating endpoints and signing software or transactions. Shor’s algorithm shows that a sufficiently capable fault-tolerant quantum computer could break the mathematical problems underlying widely deployed RSA and ECC. Symmetric cryptography behaves differently. Grover’s algorithm offers a generic quadratic search speedup rather than the same structural break, so larger symmetric key sizes can retain substantial security. That distinction is why replacing every occurrence of the word encryption with one post-quantum algorithm is conceptually wrong.

A single online-banking session may use a certificate signature to authenticate a server, an asymmetric exchange or encapsulation to establish secrets, and symmetric encryption to protect the data stream. Code signing, interbank messages, hardware administration and archived documents use other combinations. The migration inventory should record purpose, algorithm, key size, certificate chain, protocol, library, hardware dependency, owner and data classification. It must also find embedded and indirect use inside appliances and managed services; a configuration screen may say TLS while concealing the public-key choices below it.

FIPS 203 establishes keys; FIPS 204 and 205 sign

FIPS 203 specifies ML-KEM, a module-lattice-based key-encapsulation mechanism derived from CRYSTALS-Kyber. A KEM lets parties establish a shared secret over an untrusted channel; applications can derive symmetric session keys from that secret. It is not a digital-signature standard and it does not directly encrypt a bank’s database row by row. Protocol designers must integrate it into handshakes, manage keys and validate implementations. ML-KEM parameter sets offer different security strengths and sizes, so interoperability depends on both sides supporting the same choices.

FIPS 204 specifies ML-DSA, derived from CRYSTALS-Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme derived from SPHINCS+. Both authenticate data and support integrity; neither replaces ML-KEM’s key-establishment role. They also have different performance and size profiles. An institution might evaluate ML-DSA for a general signing use and SLH-DSA where a different security foundation is valuable, but standards approval alone does not choose the application. Certificates, hardware, message formats and relying parties must accept the resulting keys and signatures.

Worked example one: data lifetime sets the first migration queue

Imagine a bank classifying three flows. A public market quote loses sensitivity within seconds. A mortgage application contains identity and income records with a retention and confidentiality horizon measured in years. A merger file may remain commercially sensitive for a decade. If an attacker can collect encrypted traffic now and a future capability could decrypt it later, the long-lived records deserve earlier attention even when the system that carries quotes has higher volume. This is the logic behind “harvest now, decrypt later”: prioritize by the period data must remain secret, not only by current transaction count.

Certificates create a special coordination problem because an issuer, subject, relying party, protocol library and validation service must agree on formats and algorithms. A bank cannot migrate a public certificate chain unilaterally if customer devices or partner gateways reject the signature. Internal public-key infrastructure may move sooner, but roots, enrollment, revocation, timestamping and long-term signature validation all need review. Signed records that must remain verifiable for years may require preservation evidence or re-signing strategies before an old algorithm is retired.

The bank maps the merger portal and discovers RSA-based TLS at the edge, ECC in a mobile component, a vendor-controlled document gateway, and encrypted storage using AES. The public-key handshakes and certificates enter the post-quantum migration plan. AES storage is reviewed for key strength and management but is not replaced with ML-KEM, because the cryptographic role differs. The vendor gateway receives a dated readiness request. Meanwhile, the bank reduces unnecessary retention and narrows access, controls that lower exposure regardless of when quantum hardware advances.

Build a cryptographic inventory that vendors cannot answer for you

A cryptographic bill of materials should cover internet-facing services, internal service meshes, virtual private networks, payment interfaces, identity systems, email, file transfer, databases, backup, code signing, firmware validation, hardware security modules and third-party connections. Discovery can combine configuration scans, certificate data, source and dependency analysis, network observation, asset questionnaires and procurement records. Results need an accountable owner and confidence level. “Vendor managed” is a dependency category, not evidence that migration is solved.

Contracts and renewal cycles can accelerate or block change. Banks should ask suppliers which products will support finalized standards, whether support requires new hardware, how hybrid modes are handled, what performance testing exists and when legacy algorithms can be disabled. Answers should name versions and dates. Procurement can require crypto agility: algorithms and certificates should be replaceable without rebuilding the whole product. Institutions also need an exit plan for appliances that cannot be upgraded, including compensating controls while replacement moves through budget and certification.

Worked example two: test a hybrid connection before broad rollout

Consider an illustrative bank-to-bank file gateway. The two institutions first establish a lab connection that combines a classical exchange with ML-KEM so a defect in either component does not automatically remove all protection. Engineers measure handshake size, latency, CPU, memory, failure handling and log quality. They test certificate and signature options separately because the KEM does not authenticate the counterparty. Network teams check whether firewalls, load balancers and inspection tools tolerate larger messages. Operations deliberately mismatch parameter sets and software versions to see whether failure is clear and recoverable.

Performance tests should include more than average speed. Larger public keys, ciphertexts or signatures can affect handshake fragmentation, smart-card storage, hardware-security-module capacity and transaction-message limits. Peak signing load may matter during software release or end-of-day processing even when daily averages look small. Side-channel resistance and secure error handling also require implementation evidence. Cryptographic libraries should expose algorithm identifiers clearly so operators can distinguish a negotiation failure from a certificate, policy or network problem.

The test reveals that the new handshake works end to end, but an old monitoring appliance truncates a message and a partner’s disaster-recovery site runs an earlier library. Broad deployment pauses while those paths are corrected. That is migration progress, not failure: the purpose of interoperability testing is to discover hidden assumptions before they interrupt payments. The production plan then uses canaries, rollback, parallel telemetry and a partner schedule. Legacy support remains only for named connections and receives an expiration date, preventing a temporary compatibility mode from becoming permanent.

Run migration against evidence, not a Q-day forecast

No public method can provide a reliable date when a quantum computer will break production RSA or ECC. Hardware progress, error correction, logical qubit quality, algorithmic improvements and engineering scale all matter. A countdown invites either panic spending or complacency when the date slips. A better program tracks inventory coverage, standards support, tested applications, vendor commitments, long-lived-data exposure, cryptographic agility and retirement of unsupported systems. Regulators and sector bodies may refine expectations, but each institution still owns its architecture and third-party risk.

Governance should connect security architecture, payments, identity, legal, records, procurement, model risk where relevant, and business continuity. Migration can introduce ordinary vulnerabilities through immature libraries, poor randomness, side channels or incorrect protocol integration. Use validated implementations when required, protect keys in appropriate modules, obtain independent testing and rehearse rollback. Post-quantum does not mean post-security: phishing, credential theft, authorization errors and software flaws remain. The program succeeds when the bank can change cryptography deliberately without losing authentication, availability or evidence.

1. Inventory cryptography by function, implementation, owner, protocol, vendor and protected-data lifetime.
2. Use ML-KEM for standardized key establishment and distinguish it from ML-DSA and SLH-DSA signatures.
3. Prioritize long-lived confidential data and systems whose replacement cycles are slow.
4. Require versioned vendor road maps and design new purchases for algorithm agility.
5. Test hybrid interoperability, failure, monitoring, disaster recovery and rollback before broad migration.

Sources

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• CISA Post-Quantum Cryptography Initiative