Two of NIST's post-quantum candidates were broken during standardisation itself — Rainbow in February 2022, on a laptop over a weekend, and SIKE that July, in about an hour on a single-core processor. Neither attack needed a quantum computer.
That history is why FINMA's Guidance 05/2026 asks Swiss institutions for something broader than post-quantum cryptography. Section 3.4 states it plainly: "It must be anticipated that even in the future, (PQC) algorithms currently regarded as secure will need to be replaced. For example, certain PQC algorithms might, unexpectedly, prove ineffective."
The regulator's answer is crypto-agility — "the ability of IT systems to replace their cryptographic algorithms flexibly and without making major changes to the software architecture."
That is a clear definition. What it is not is an implementation guide, a budget, or an owner. This article is an attempt at the missing half: what agility looks like inside a bank's architecture, what it costs to specify against what it costs to skip, who should own it, and what to do first.
What crypto-agility is not
It is not a product. There is no module to license and no vendor — including us — that can sell an institution agility as a component. Any supplier claiming otherwise is describing something narrower than the word implies.
It is also not a project that finishes. An institution that migrates to ML-KEM in 2028 by hard-coding it in place has completed a migration and acquired no agility whatsoever.
Agility is an architectural property. Like resilience or auditability, a system either has it structurally or does not — and it is far cheaper to specify than to retrofit.
The four properties that make an estate agile
1. Cryptography sits behind interfaces, not inside applications.
An application should request an operation — encrypt this, sign that, establish a session — from a service that decides which algorithm to use. Changing an algorithm then becomes a change in one place rather than in every application that happens to need it.
The test: if you replaced one algorithm tomorrow, how many places would have to change?
2. Certificates and key material are managed centrally.
Distributed key management is the most common reason a migration stalls. If certificates are issued and renewed per system, by whichever team built that system, nobody can say how many exist or what algorithms they use — and no change can be coordinated.
The test: could you produce a list of every certificate in use, with its algorithm and expiry, this week?
3. Algorithm choice is configuration, not code.
The test: is changing an algorithm a configuration change and a controlled restart — or a code change, a build, a regression cycle and a release window? The distance between those two answers, multiplied by the number of systems, is the true cost of your next migration.
4. You can test and roll back an algorithm change safely.
Agility that cannot be exercised is theoretical. Teams will not use flexibility they cannot reverse.
The test: have you ever actually reversed a cryptographic change in production?
Where it breaks in a real bank
The obstacles are rarely conceptual. They are specific, and several of them are sharper in Switzerland than elsewhere.
Vendor packages you cannot modify. A meaningful share of a Swiss bank's cryptography sits inside software it did not write and cannot change. This is where the Swiss market structure matters: a comparatively small number of core banking, payments and custody providers serve much of the sector. That cuts both ways. It means an individual institution's agility is partly determined by decisions taken elsewhere — and it means that coordinated demand from a handful of serious institutions can move the whole market faster than any single migration programme could.
Both ends must agree. Cryptography at an interface is a negotiation, not a setting. You can be entirely agile and still unable to change an algorithm because the counterparty, the scheme or the market infrastructure at the other end is not.
Hardware and embedded estates. Cryptography in hardware security modules, payment terminals, cards or network appliances moves on hardware refresh cycles, not software release cycles. These have the longest lead times and should be identified earliest.
Data with a very long confidentiality horizon. This is the Swiss point that matters most. An institution holding multi-generational wealth structures, client documentation and identity records is protecting data whose confidentiality requirement is measured in decades. For that data, an algorithm you cannot replace is not an operational inconvenience; it is a commitment you may be unable to honour. Re-encrypting a live database is one problem. Re-encrypting decades of archives, backups and immutable records is the problem that usually determines when a migration actually completes.
What it costs to specify — and what it costs to skip
FINMA does not put a price on any of this, and neither can we with any honesty. But the shape of the arithmetic is clear enough to take to a board, because it is structural rather than empirical.
There are three ways to arrive at a new algorithm.
Specify agility at procurement. The marginal cost is a clause in a requirements schedule and the negotiation that follows. It is measured in drafting hours, and it is incurred once per contract — during a process the institution is running anyway.
Retrofit agility into a system you already own. This is a project: analysis, design, change, test, release. Incurred per system, and repeated for every system in scope.
Skip agility and migrate anyway. You pay the retrofit cost for every affected system — and then pay it again at the next algorithm change, because nothing about the estate has become easier to change.
The multiplier that matters is therefore not the cost of one migration. It is (systems carrying vulnerable algorithms) × (cost per system) × (number of future algorithm changes). Agility does not reduce the first two terms. It drives the third toward one.
Which leads to the honest admission that makes this argument credible rather than promotional: agility does not make your first migration cheaper. It may make it slightly more expensive. What it does is make the second and third migrations dramatically cheaper — and on the evidence of 2022, there will be a second and a third.
And in practice, time is the binding constraint rather than money. FINMA's own survey found that institutions which already hold roadmaps allow four to five years to reach quantum-safe for critical data and processes. The units of that timeline are release cycles, hardware refresh cycles and contract renewals — none of which accelerate because a budget increases.
Who owns it
FINMA answers this more clearly than most institutions do. Section 3.1 asks for a strategy adopted by the board of directors, with an implementation plan derived from it.
That matters because crypto-agility has no natural owner. Architecture owns system design but not contracts. Procurement owns contracts but not architecture. Operational risk owns the register but neither of the other two. Each reasonably assumes one of the others is handling it, and the result is a requirement everybody agrees with and nobody specifies.
Two practical consequences. First, agility needs a single named owner with authority over procurement standards, not only over design standards — because most of the estate is bought rather than built. Second, board adoption is what converts a good intention into a budget line, which is precisely why FINMA places it in the strategy section rather than the technology section.
The test: if a supervisor asked tomorrow who owns crypto-agility at your institution, is there one name — and would that person's remit actually reach the contracts?
There is also a distinctly Swiss dimension to this. FINMA supervises on principles rather than checklists, which means an institution is expected to justify its own choices rather than demonstrate compliance with a prescribed list. That is a greater degree of freedom and a greater burden of reasoning — and reasoning has to belong to someone.
The procurement lever
For everything the institution does not build itself, FINMA points at a specific moment: the point of purchase. It recommends crypto-agility as a requirement for systems "to be procured or developed", and in Section 3.5 that crypto-agility "be made a prerequisite for all new outsourcing arrangements in the software and data sectors", with existing arrangements addressed "at the earliest opportunity".
In practice this reduces to two sentences in a requirements schedule:
Negotiated at contract stage, that costs a drafting session. Discovered in 2031, it costs a renewal cycle the institution does not control — and renewal cycles in this market run one, three or five years.
The honest cost of agility itself
Abstraction is not free. A crypto service layer is another component to operate, monitor and secure. It can introduce latency. Built badly, it becomes a single point of failure protecting everything.
Two mitigations are worth stating plainly. Prefer standard interfaces and established providers over a bespoke internal crypto layer; institutions that write their own cryptographic plumbing tend to discover why that is difficult. And scope agility by risk rather than applying it uniformly — systems carrying decades-long confidential data justify the investment far more readily than those whose data is worthless within a week.
73% of the institutions FINMA surveyed rated crypto-agility important or very important. The gap between that number and the number who have built it is not, in most cases, a disagreement about value. It is the absence of a moment at which someone with authority decided to specify it.
What to do first
Inventory before abstraction. You cannot put cryptography behind an interface until you know where it currently sits. FINMA sequences it this way for good reason.
Start where data lives longest. Ranking by system criticality is the instinctive move and the wrong one. For quantum risk the relevant ranking is how long the data must remain confidential — the exposure that "harvest now, decrypt later" creates.
Fix the procurement language now. It is the only item on this list that costs a drafting session and applies to every future system.
Name an owner, and take it to the board. Without both, the rest stays advisory.
Identify the hardware. Longest lead times, least flexibility, and most likely to set the true completion date.
The question worth putting to your architects is not whether the estate is agile. It is narrower and more useful: if the algorithm you standardise on in 2027 were withdrawn in 2031, how much of the estate would you have to open up to replace it — and what would that cost, in money and in months?
The answer, expressed in systems rather than in principle, is your agility position.
References
1. FINMA, Guidance 05/2026, Quantum computing, 9 July 2026 — in particular §3.1 (strategy), §3.4 (crypto-agility) and §3.5 (external service providers).
2. FINMA, Circular 2018/3 Outsourcing — banks and insurers.
3. NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), August 2024.
4. W. Beullens, "Breaking Rainbow takes a weekend on a laptop", 2022.
5. W. Castryck and T. Decru, "An efficient key recovery attack on SIDH", 2022 — the classical attack that ended SIKE's candidacy.
Survey figures are FINMA's own results (60 institutions, November 2025 – January 2026) as published in Guidance 05/2026.
About the author. Amit Agarwal is CEO and Co-Founder of SeQure AG, a Swiss quantum cybersecurity company helping banks and financial institutions identify, prioritise, and remediate cryptographic vulnerabilities before Q-Day. He brings 25+ years across software, SaaS, payments and FinTech and holds a BTech (Computer Science), an MBA, an MAS, and a Quantum Computing qualification from MIT's executive education.