← Guide overview

Crypto-agility first

Quantum Readiness for Banking Professionals: all chapters

• 1. What quantum threatens in a bank, and what it doesn't
• 2. Where cryptography lives in a payments estate
• 3. Building a cryptographic inventory
• 4. Deciding what to fix first
• 5. Crypto-agility first
• 6. Vendors and third parties
• 7. Governance and the regulatory map
• 8. A phased roadmap
• Readiness self-assessment
• Glossary

On this page

1. What crypto-agility means
2. Why agility comes first, not later
3. Six disciplines that make a bank agile
4. Bigger keys need room
5. Making the case for funding
6. Questions to ask your architects
7. Sources and further reading

The previous chapter kept running into the same obstacle. Items that should be quick to fix weren't, because the cryptography was pinned in configuration across several systems, hard-coded in software, or locked inside a supplier's product. That obstacle has a name: a lack of crypto-agility. This chapter argues that building agility is one of the most durable early investments in the programme, and among the easiest to justify, because it pays off whatever happens with quantum computing.

What crypto-agility means

NIST describes crypto-agility as the ability to replace cryptographic algorithms in systems and applications without significant disruption to their operation. The plain-English test is this:

If changing an algorithm means changing application code, re-issuing certificates by hand or coordinating a release across several teams, you aren't crypto-agile. If it means changing a setting or a policy, you are.

A setting change is the test, not the whole job. Real agility also needs interoperability testing, performance checks, key and certificate lifecycle management, and operational controls behind each change.

Most banks are somewhere in between. Larkfield's pilot items show the whole range:

Larkfield item	How the algorithm is set	What a change involves
Online banking connection	A setting on the load balancer	A tested configuration change
Payments hub to messaging interface	Pinned in the configuration of several systems	Coordinated change across three teams and a vendor
Archive key protection	Written into the archive software's code	A software change, then re-protecting every stored key
Network appliances	Fixed by the device firmware	Waiting for, testing and rolling out a vendor update

Why agility comes first, not later

It's tempting to think of the quantum programme as a one-time swap from old algorithms to new ones. It won't be, for at least four reasons.

1. The standards are still arriving. NIST published its first three post-quantum standards in 2024, but a compact signature standard (FN-DSA) is still in progress, and a backup key-agreement algorithm (HQC) selected in 2025 is expected to be standardised around 2027.
2. The transition has two steps. Most organisations will run hybrid cryptography first, old and new together, and later remove the old half. Without agility, that's two migrations instead of one migration and a setting change.
3. New algorithms can fail. During NIST's selection process, two promising candidates were broken by researchers using ordinary computers, one of them over a weekend on a laptop. The algorithms chosen have survived years of scrutiny, but prudent planning assumes surprises remain possible.
4. Requirements differ. Different regulators, partners and networks may require different strengths or combinations. Agility lets one estate meet several requirements without rebuilding.

An estate that hard-codes today's post-quantum choices will face the same problem again in a few years. An agile estate turns each future change into routine work.

Six disciplines that make a bank agile

Crypto-agility isn't a product you can buy. It's a set of engineering and governance habits. For a programme lead, each one translates into a requirement, a standard or a procurement rule.

Discipline	What it means	How governance can enforce it
No hard-coded algorithms	Algorithm choices live in configuration or policy, not in code	Architecture standards and code review checks
A common cryptography service	Applications ask a shared service to "encrypt" or "sign", rather than choosing algorithms themselves	Reference architecture; new systems must use it
One inventory and policy	The inventory from Chapter 3 is the single source of truth for what's used where	Inventory updates as a release requirement
Automated certificates and keys	Certificates and keys are issued, renewed and replaced by tooling, not by hand	Fund automation; set targets for coverage
Suppliers that can change	HSMs, libraries and products are chosen for their ability to add new algorithms	Post-quantum roadmaps as a procurement requirement
Hybrid-ready	Systems can run old and new algorithms together during the transition, then drop the old	Design standards for new and replacement systems

Certificate automation deserves a special mention. Larkfield has around 9,000 certificates. Replacing them by hand, possibly more than once, isn't realistic. Banks that have automated certificate renewal also tend to suffer fewer outages from expired certificates, a benefit that arrives long before any quantum computer.

Bigger keys need room

There's one dimension of agility that generic advice often misses and payments people should care about: size. Post-quantum keys and signatures are much larger than today's. A typical elliptic-curve signature is about 64 bytes; ML-DSA signatures run from about 2,400 to 4,600 bytes, depending on the strength chosen.

In most places that's harmless. But some parts of a payments estate have tight limits: fixed-size fields in older message formats, the small memory of payment card chips, protocols with strict packet sizes, and storage designed around small signatures. For these, agility means leaving headroom: designing formats, fields and hardware choices made today so they can carry larger signatures later.

This matters now, not in 2030. Banks are modernising payment messaging and replacing systems today. A design decision taken this year that assumes small signatures may force another round of change within the decade. A useful habit is to ask, in every relevant design review: "Would this still work if the signatures were fifty times larger?"

Making the case for funding

Agility is the easiest part of the quantum programme to fund, because the case doesn't depend on any prediction about quantum computers.

• It reduces outages. Automated certificate management cuts expired-certificate incidents.
• It speeds up responses to ordinary vulnerabilities. When an algorithm or library weakness is announced, an agile bank changes a setting; a brittle one launches a project. The industry's slow retirement of the SHA-1 algorithm in the 2010s is the cautionary example.
• It lowers the cost of the quantum migration itself. Every hard-coded item fixed now is one less engineering project later.
• It's what supervisors and standard setters are asking for. The G7 Cyber Expert Group's roadmap for the financial sector explicitly calls for crypto-agility.

Larkfield's committee approved three agility measures before any post-quantum algorithm was deployed: a certificate automation project, a design standard banning hard-coded algorithms in new systems, and a procurement clause requiring suppliers to publish post-quantum roadmaps.

Questions to ask your architects

1. For our ten most important systems, is the algorithm set by configuration, pinned across systems, or hard-coded?
2. What share of our certificates are renewed automatically?
3. Do new systems have to use a common cryptography service, or can each team choose its own?
4. Can our HSMs and key libraries add new algorithms through updates, or would they need replacing?
5. In current design work, where would signatures fifty times larger cause a problem?

Sources and further reading

Larkfield Bank is fictional and its figures are illustrative. Everything else is drawn from the public sources below. Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account. Checked on 11 October 2026. Spotted an error? Email hello@plainquantum.com.

1. Government guidanceConsiderations for Achieving Cryptographic Agility (CSWP 39)NIST
2. StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024
3. StandardNIST selects HQC as fifth algorithm for post-quantum encryptionNIST, 2025
4. StandardFIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)NIST, 2024
5. Peer-reviewed paperBreaking Rainbow takes a weekend on a laptopWard Beullens, CRYPTO, 2022
6. Peer-reviewed paperAn efficient key recovery attack on SIDH (the SIKE break)Wouter Castryck and Thomas Decru, EUROCRYPT, 2023
7. Industry guidanceG7 Cyber Expert Group: coordinated roadmap for the transition to post-quantum cryptography in the financial sectorG7 Cyber Expert Group (via US Treasury), 2026