Cryptographic agility: swapping an algorithm without rebuilding the bank

Cryptographic agility is the ability to change the cryptography a system uses without redesigning the system around it. In an agile design the algorithm is a configuration decision behind an interface; in a rigid one it is spread through the code, hard-coded in a protocol version, baked into a stored record format, or sitting in a vendor appliance you cannot change at all.

The FS-ISAC Post Quantum Cryptography Working Group frames the goal plainly: to enable business continuity if or when existing cryptography is compromised or weakened. That framing is deliberate, because it puts the subject in front of a management audience that will not fund a cryptography project but will fund continuity. NIST supplies the standards side, and the practical work in a bank is making the swap cheap before you need it.

The first deliverable is an inventory: which algorithms are in use, where, for what, with which key lengths, and who owns each use. It is tedious and it is the whole project, because every later decision depends on it. The hard parts are the ones nobody documented: a certificate inside a vendor product, a signing routine in a batch job written two decades ago, an algorithm choice fixed by a protocol version a counterparty insists on.

The elements described by PQShield's account of the FS-ISAC paper on building cryptographic agility in the financial sector include exactly this inventory, the handling of escrowed keys, and prioritizing by crown-jewel data instead of trying to do everything at once. That prioritization is what makes the work finishable: you order the inventory by what the data is worth and how long it stays sensitive, and you migrate in that order. The BSI technical guidelines on cryptographic mechanisms are the German reference for what counts as adequate at each point.

A bank's most sensitive keys live in hardware security modules, which is where they belong: the module holds the key, performs the operation, and does not hand the key out. The consequence for agility is that an algorithm your HSM firmware does not support is an algorithm you cannot use, however agile the application layer is.

That turns a software question into a procurement and certification one. These modules are certified, and payment HSMs carry requirements from the PCI Security Standards Council on top, with the BSI and the Common Criteria regime on the German and European side. Certification takes time, replacement cycles are measured in years, and a module in a payment path cannot be swapped on a quiet afternoon. Any migration timeline that does not start from the HSM estate's own cycle is a timeline that will slip.

An attacker who captures encrypted traffic today and stores it can decrypt it when the means arrive. That makes the relevant question not when an algorithm breaks, but how long your data has to stay confidential. Traffic whose contents are worthless in a week is not exposed to this. A mortgage file, a client's financial position, a health-related underwriting record or a long-dated contract is.

So the inventory needs a second column next to each use: the confidentiality lifetime of what it protects. Where that lifetime extends past the horizon in which the algorithm is expected to hold, the data is already at risk and the migration for that use is not optional. The BSI and ENISA both treat post-quantum readiness in these terms. Post-quantum cryptography in finance covers the algorithms and the migration timeline, which this page does not repeat.

Inside your own systems you set the schedule. The moment a cryptographic operation happens between two institutions, both ends have to support the new algorithm before either can use it, and the slowest counterparty sets the date. FS-ISAC's own guidance raises this coordination problem for financial firms, and it is the part no internal project plan can solve.

The practical consequence is that the migration has an industry-level sequencing step that has to be worked through scheme rules, message standards and bilateral agreements, and that this work starts long before the technical readiness date you would otherwise plan for. Payments in Germany covers the rails this applies to, and core banking in Germany the platforms behind them.

This is not a research topic a bank may postpone until the subject matures. DORA places encryption and cryptographic controls among the ICT protection requirements a European financial entity has to meet, together with a policy on cryptographic controls and key management, which means the inventory and the key estate are supervised ground.

For a reader who has to get this funded, that is the lever. DORA in Germany covers the regulation and how BaFin supervises it, and cybersecurity in German finance places it in the wider security picture. Certificates and keys that belong to machines, not to people, are the operational half of the same inventory, which machine identity in banking covers.

The algorithms and the timeline belong to post-quantum cryptography in finance, and the Frankfurt research and institutional scene working on quantum technologies sits on quantum finance in Frankfurt.

What belongs on this page is the capability that makes any of it executable. A bank that has done the inventory and knows its HSM cycle can act on a new standard when it lands; a bank that has not will spend that window finding out where its algorithms are. Customer key custody is a different subject, covered by crypto custody in Germany.

The ability to change an algorithm, key length or protocol without redesigning the application that uses it. In practice it means the cryptographic choice sits behind an interface as configuration instead of being spread through code, fixed in a stored record format, or locked inside a vendor appliance.

With the inventory: every place cryptography is used, with the algorithm, the key length, the purpose, the owner and the confidentiality lifetime of what it protects. Order it by what the data is worth and how long it stays sensitive, and migrate in that order. Everything else depends on this list existing.

Because the module, not the application, performs the operation on the most sensitive keys. An algorithm the HSM firmware does not support cannot be used at all, and these modules are certified, replaced on multi-year cycles and sit in payment paths that cannot be interrupted casually. The HSM estate's own cycle is therefore the realistic pace of any migration.

No. Post-quantum cryptography is the set of algorithms designed to withstand a quantum computer, and the migration to them is the current occasion for this work. Agility is the capability of changing algorithms at all, which will be needed again for reasons that have nothing to do with quantum computing.