Building Crypto-Agility into Banking Systems Before Quantum
Replacing an Algorithm Should Not Require Replacing the System
Ask a bank how long it would take to replace one cryptographic algorithm across the estate. Not to design a migration, not to write a policy, just to change from one algorithm to another everywhere it is used. In most institutions nobody can answer, because nobody knows everywhere it is used, and the honest estimate for the parts that are known is measured in years.
That is the real finding behind crypto agility banking systems work. The quantum threat supplies the deadline, but the underlying weakness is that cryptographic choices were made once, hardcoded, and distributed through the estate in ways that make any change a programme rather than a setting.
What problem is agility actually solving?
The cost of change, which today is high enough that transitions take a decade.
Every previous cryptographic transition in banking has taken far longer than expected, for the same reasons each time: the algorithm is named directly in application code, key material carries no indication of what produced it, protocols negotiate from fixed lists, hardware supports a fixed set, and every counterparty has to move together. Agility means designing so that the next change is a configuration decision and a coordinated rollout rather than a rewrite. That is valuable regardless of quantum computing, because algorithms get deprecated for ordinary reasons too.
Why does harvest now, decrypt later create a real deadline?
Because the interception happens today and the decryption happens later.
The BIS Innovation Hub's Project Leap, run from the Eurosystem Centre, is explicit about this: malicious actors can intercept and store confidential, classically encrypted data with the intention of decrypting it once quantum computers become powerful enough. The consequence for a bank is that the deadline is not the arrival of a capable quantum computer. It is the arrival of that machine minus the confidentiality lifetime of the data being transmitted now. For payment instructions the useful life is short. For customer identity documents, medical underwriting data, long-dated contracts, and legal records, it is decades, and that data is being transmitted today.
How long does your most sensitive transmitted data need to stay confidential?
What is in the cryptographic inventory?
More than the estate documents, and much of it outside your control.
| Where cryptography lives | Typical visibility | Difficulty of change |
|---|---|---|
| TLS termination and internal service traffic | Good | Moderate, mostly configuration |
| Application code calling crypto libraries directly | Poor | High, requires code change |
| Database and storage encryption | Moderate | Moderate, plus re-encryption of data at rest |
| Hardware security modules | Good | Constrained by firmware and certification |
| Code signing and artefact verification | Moderate | Moderate, plus toolchain change |
| Message signing with counterparties | Good | Very high, requires bilateral coordination |
| Certificates and the issuing hierarchy | Good | High, whole chains must move together |
| Vendor products and appliances | Poor | Entirely dependent on the vendor |
| Firmware in cards, terminals, and devices | Very poor | Longest lead time of all |
| Embedded libraries pulled in transitively | Very poor | Requires dependency analysis |
Building this inventory is the first deliverable of any credible programme, and it should record not just where cryptography is used but who controls the decision to change it. That second column is what turns an inventory into a plan.
Why do the hardest instances sit outside your control?
Because vendor products, firmware, and shared protocols move on someone else's schedule.
A payment terminal fleet, a card estate, an appliance with a five-year support cycle, or a vendor platform with no published post-quantum roadmap all represent exposure that no amount of internal engineering resolves. The practical response is to make it a procurement question now: ask every critical supplier for their cryptographic inventory and transition roadmap, and make agility a contractual requirement for new agreements, which fits into the assessment discipline described in technology vendor due diligence and exit testing. A vendor with no answer today will have no answer when it matters.
What has actually been standardised?
Two algorithms directly relevant to banking, published together in August 2024.
NIST published FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, on 13 August 2024. It standardises ML-KEM, which allows two parties to establish a shared secret key over a public channel, with security resting on the difficulty of the Module Learning with Errors problem and believed to hold even against adversaries in possession of a quantum computer. It defines three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, with increasing security strength and decreasing performance.
On the same date NIST published FIPS 204, the Module-Lattice-Based Digital Signature Standard, standardising ML-DSA. It is used to detect unauthorised modification of data, to authenticate the identity of the signatory, and to support non-repudiation, and is likewise believed secure against a large-scale quantum computer. It forms part of NIST's post-quantum standardisation project alongside FIPS 203 and FIPS 205.
| Use in a bank | Traditional approach | Standardised replacement |
|---|---|---|
| Session key establishment | Classical key exchange | ML-KEM (FIPS 203) |
| Signing messages and documents | Classical digital signatures | ML-DSA (FIPS 204) |
| Code and artefact signing | Classical digital signatures | ML-DSA (FIPS 204) |
| Symmetric encryption of data | Symmetric ciphers | Unchanged approach, key sizes reviewed |
| Key derivation and hashing | Hash-based constructions | Unchanged approach, strength reviewed |
The parameter set choice in ML-KEM is a genuine engineering decision rather than a default, since the standard's own framing is that strength increases and performance decreases across the three sets. That trade-off has to be made per use case, informed by the confidentiality lifetime of the data involved.
What does agility look like architecturally?
Five properties, none of which most estates currently have.
First, no algorithm names in business logic: application code requests an operation such as sign, verify, or establish a session, and a cryptographic service decides how. Second, key material that carries its own metadata, so any stored or transmitted key identifies the algorithm, parameters, and version that produced it. Third, negotiated rather than fixed algorithms in protocols, with the acceptable set expressed as policy. Fourth, cryptographic policy as versioned configuration that can be changed and rolled out without a code release. Fifth, the ability to run two algorithms concurrently during transition, since no realistic migration is instantaneous.
Why does abstraction fail without algorithm metadata on keys?
Because you cannot decrypt or verify what you cannot identify.
An abstraction layer routes new operations correctly and then meets a key stored five years ago with no record of what created it. At that point the layer has to guess, try each in turn, or fail, and in an estate holding decades of encrypted archives that problem is large. Retrofitting metadata onto existing key material is unglamorous work that has to happen early, because it gates everything else. The custody and lifecycle side of this belongs with the design set out in HSM and key management for financial workloads.
What do the performance findings mean?
That post-quantum algorithms cost measurably more, and latency-sensitive paths need designing around it.
Project Leap's results are the most directly relevant evidence available to a bank. Phase 1 successfully tested post-quantum cryptography between two central banks using hybrid encryption combining traditional and quantum-resistant algorithms, proving feasibility while identifying performance impacts requiring further testing. Phase 2, completed in December 2025, demonstrated that replacing traditional digital signatures with post-quantum cryptography works in operational payment systems, while showing that the post-quantum algorithms require significantly higher processing time than traditional algorithms. The project involves the Bank of France and Deutsche Bundesbank, with the Bank of Italy joining in Phase 2, alongside partners including Swift.
For an institution that matters most where time budgets are tight. Instant payment rails with end-to-end targets measured in seconds, high-volume authorisation paths, and card transaction flows all have latency budgets that a slower signature operation consumes. Model the impact per path rather than estimating across the estate, since the answer differs enormously between an overnight batch and an authorisation decision. Where a hub sits on the critical path, its throughput assumptions need revisiting explicitly, as covered in payment hub architecture.
Have you modelled what a slower signature operation does to your authorisation latency budget?
Why use hybrid modes during transition?
Because they stay secure if either algorithm holds.
A hybrid construction combines a traditional algorithm with a quantum-resistant one so that breaking the exchange requires breaking both. That is the prudent posture while operational confidence in the newer algorithms accumulates, and it is the approach Project Leap tested in its first phase. The cost is additional computation and larger messages, which returns to the performance question above. The design decision is where hybrid is worth the overhead, which is usually anywhere the data has a long confidentiality life and anywhere a counterparty requires it.
What about certificates and hardware?
Both have lead times longer than the software work, so both start earlier.
Certificate hierarchies have to migrate as chains rather than as individual certificates, which means the issuing infrastructure moves first and every dependent system must trust the new chain before anything is reissued. Shorter certificate lifetimes help considerably, because they mean the estate cycles through renewal more often and a transition can ride on the renewal cycle rather than requiring a separate campaign. Hardware is the harder constraint: modules need firmware support, that firmware needs certification, and certification lags standardisation. Ask the supplier for dates in writing, plan replacement cycles around them, and treat any device with a long field life and no upgrade path as a scheduled replacement rather than an open question. Authentication estates carry the same shape of problem, as discussed in passkey authentication in banking.
How do you coordinate with schemes and counterparties?
By tracking their roadmaps and accepting that shared paths move together.
No bank migrates a scheme connection unilaterally. Message signing with counterparties, network connectivity, card scheme interfaces, and settlement links all move at the pace of the network, which means the institution's job is readiness rather than initiative: be able to support the new algorithms when the scheme enables them, and have the internal work done so the external step is a configuration change. Maintain a register of external cryptographic dependencies with each party's published position, and escalate the ones with no position. Connectivity paths such as those described in SWIFT gpi and API connectivity belong in that register, as do settlement and tokenisation platforms of the kind covered in tokenised deposits and stablecoin infrastructure.
How should the programme be sequenced?
Inventory, then abstraction, then the long-lead items, then transition by data lifetime.
| Phase | Duration | Deliverable |
|---|---|---|
| Cryptographic inventory | 3 to 4 months | Every use, with the party who controls the change decision |
| Data confidentiality lifetime analysis | 1 month | Which flows carry data needing protection for decades |
| Key metadata retrofit | 3 to 6 months | Stored and transmitted keys identify their own algorithm |
| Cryptographic abstraction layer | 4 to 6 months | Business code requests operations, not algorithms |
| Policy as configuration | 2 months | Acceptable algorithm sets deployable without code release |
| Vendor and hardware roadmaps | 2 months, then ongoing | Written positions from every critical supplier |
| Certificate hierarchy readiness | 4 to 6 months | Chains able to migrate, lifetimes shortened |
| Hybrid deployment on long-lifetime flows | 6 to 12 months | Highest-value confidentiality paths protected first |
| Scheme and counterparty readiness | Ongoing | Able to enable new algorithms when the network does |
Sequencing by data confidentiality lifetime rather than by system criticality is the point most programmes get wrong. A less critical system transmitting data that must stay confidential for thirty years is more urgent than a critical system whose data is worthless in a week.
Which metrics matter?
Inventory completeness, abstraction coverage, key metadata coverage, long-lifetime flow protection, vendor roadmap coverage, and time to change an algorithm.
Report inventory completeness including the proportion where the controlling party is identified. Report how much of the estate calls cryptography through the abstraction rather than directly, since that number predicts the cost of every future transition. Report key metadata coverage, because it gates the rest. Report the share of long-confidentiality-lifetime flows already protected. Report vendor roadmap coverage across critical suppliers. And measure the thing the programme exists to change: how long it would now take to replace one algorithm across the estate. If that figure is not falling, the work is producing migration rather than agility, and the next transition will cost the same as this one. The wider exposure framing for institutions carrying this risk is covered in quantum migration delays.
The quantum timeline is uncertain and the agility work is not wasted under any version of it. An estate that can change an algorithm in months instead of years is better off whatever the physics turns out to allow.
Frequently Asked Questions
What is crypto-agility actually solving?
The problem that changing a cryptographic algorithm currently requires changing application code, protocols, hardware, and partner agreements, which makes any transition take years.
Why does harvest now, decrypt later create a deadline?
Because an adversary can intercept and store encrypted data today and decrypt it once a capable quantum computer exists, so data with a long confidentiality life is already exposed.
Which post-quantum algorithms have been standardised?
NIST published FIPS 203 standardising ML-KEM for key establishment and FIPS 204 standardising ML-DSA for digital signatures, both on 13 August 2024, alongside FIPS 205.
Why is the cryptographic inventory never complete?
Because cryptography is embedded in libraries, vendor products, firmware, protocols, and hardware that the institution does not control and often cannot inspect.
What does crypto-agility look like architecturally?
No algorithm names in business logic, key material that carries its own algorithm identity, negotiated rather than hardcoded algorithms, and cryptographic policy expressed as configuration.
Do post-quantum algorithms cost performance?
Yes. Central bank experiments replacing traditional digital signatures with post-quantum cryptography in operational payment systems found significantly higher processing time than traditional algorithms.
Why use hybrid modes during transition?
Because combining a traditional and a quantum-resistant algorithm means the exchange stays secure if either one holds, which is the prudent position while confidence in new algorithms builds.
Can a bank migrate on its own timetable?
Only for internal systems. Anything crossing a scheme, network, or counterparty boundary moves at the pace of the slowest participant and requires coordination.
