SeQure AG Blog

What the central banks’ post-quantum pilots tell Swiss banks about lead time

amit.agarwal@sequre.ch (Amit Agarwal) — Fri, 12 Jun 2026 13:40:00 GMT

There is a comfortable way to talk about quantum risk, and an uncomfortable one. The comfortable version debates when Q-Day will arrive and treats migration as a problem for the institution you will be in 2030. The uncomfortable version watches what happens when someone actually runs post-quantum cryptography through a payment system — and asks how long it would take you to do the same.

In December 2025, the Bank for International Settlements gave us the uncomfortable version. The second phase of BIS Project Leap put post-quantum signatures through wholesale-payment flows modelled on systems such as TARGET2 — not in a white paper, but in working infrastructure. For Swiss banks, it is the most useful thing published on this subject in some time, because it replaces speculation with engineering.

What Leap actually found

The headline finding is unglamorous, which is exactly why it matters. A CRYSTALS-Dilithium signature is roughly 3’293 bytes (NIS Security Level 3); an RSA-2048 signature is about 256. That is close to a thirteenfold (13x) increase, in a domain where message formats, buffers and connectors were never designed to absorb it. In the pilot, that size delta strained message buffers and the connectors between systems. Verification of the post-quantum signatures ran slower than RSA. None of these were fatal. All of them required engineering work, configuration changes and careful testing.

Read in isolation, that sounds like a manageable list. Read correctly, it is a warning about time. I made a similar experience with my Payments FinTech teams as we were aiming to migrate our hosted financial messaging customers to SWIFT ISO messages. That was with 2.5x increase in storage, expensive and needed a lot of time in negotiations with all stakeholders to ensure cross border payments kept flowing without service disruptions. The quantum security migration is far more complex, far more demanding, far more time-consuming, and needs far more coordination with vendors and 3rd party partner stakeholders.

Why your estate is harder than theirs

Project Leap had three advantages no commercial bank enjoys. It ran on infrastructure that central banks largely govern. It was executed by specialist teams who chose the scope and the schedule. And it was a contained experiment, not a live production cut-over with customers, counterparties and regulators watching.

A Swiss universal or private bank faces the same physics on a far less forgiving estate. Cryptography is scattered across heterogeneous applications, third-party connectors, hardware security modules, certificates with their own expiry cycles, and protocols stood up years ago by people who have since moved on. Much of it is undocumented. Some of it is owned by vendors. And the migration cannot be scheduled for a quiet weekend, because in a payments business there are no quiet weekends (ours, I talked about earlier regarding SWIFT MX ISO migration, needed 28 well-in-advance scheduled and negotiated weekends!).

The simple inequality that governs all of this is worth stating plainly:

data lifetime + migration time > time to Q-Day → you are already exposed.

If the data you protect today must stay confidential for ten years, and your migration will itself take several years, then the relevant deadline is not Q-Day. It is Q-Day minus your migration time minus your data’s required lifetime. For most Swiss institutions, once you do that subtraction honestly, the comfortable timeline disappears.

Lead time is the asset — and it is being spent

This is the real lesson of Leap. The binding constraint on post-quantum readiness is not the availability of algorithms — NIST finalised FIPS 203, 204 and 205 in 2024. It is not even budget. It is lead time: the months and years of inventory, dependency-mapping, vendor coordination, testing and phased cut-over that integration on a complex estate demands. Lead time cannot be bought back at the end. It can only be spent early, or lost.

Harvest Now, Decrypt Later sharpens the point in a way specific to Switzerland. A financial sector built on long-lived confidentiality is, by definition, among the most attractive targets for an adversary willing to store encrypted traffic now and decrypt it once a cryptographically relevant quantum computer exists. The data harvested today does not wait for your migration plan.

What to do with the time you still have

The honest response is not to panic, and not to wait for a mandate. It is to convert an open-ended threat into a managed programme — and that is a sequence, not a single project.

It begins with knowing where your cryptography actually lives. You cannot prioritise, cost or evidence a migration for an estate you have not inventoried. From there, the work is prioritisation: not everything is equally exposed, and not everything is equally critical. This is the problem we built QuRisc Atlas to solve — it ingests a cryptographic inventory, network topology and Q-Day forecasts, then applies three industry-standard risk models and an extensive rule set to separate the handful of genuine hotspots from the thousands of findings that can wait. The output is a prioritised migration roadmap a board can fund and a CISO can execute.

The point of that machinery is not sophistication for its own sake. It is to give you back the one thing Project Leap proved you cannot manufacture under pressure: lead time, spent deliberately, on the things that matter most.

Central banks ran the experiment so the rest of us would not have to learn these lessons live, in production, against a deadline set by an adversary. The findings are not frightening. They are clarifying. The institutions that read Leap correctly will not ask whether they have until 2030. They will ask how much of their lead time they have already spent — and start treating what remains as the scarce asset it is.

About the author. Amit Agarwal is CEO and Co-Founder of SeQure AG, a Swiss quantum cybersecurity company helping banks and financial institutions migrate to quantum-secure operations. He holds a quantum computing qualification from MIT’s executive education and brings 25+ years across software, SaaS, payments and FinTech.

Quantum Risk for Swiss Banks: Why Mosca’s Inequality Matters More Than Q-Day’s Date

amit.agarwal@sequre.ch (Amit Agarwal) — Fri, 12 Jun 2026 11:05:13 GMT

Article

Most conversations about quantum risk get stuck on a single question: when will a quantum computer be able to break the encryption we use today? It is an understandable place to start. It is also, in my experience, the least productive one — because nobody can answer it with confidence, and the argument tends to consume the energy that should go into preparation.

There is a better question. And it has been sitting in plain sight, in the work of the cryptographer Michele Mosca, for more than a decade.

What Mosca’s inequality actually says

The idea is almost arithmetic, which is part of its power. It rests on three numbers.

The first is how long your data must remain confidential — call it X. The second is how long it will take your institution to migrate its systems to quantum-safe cryptography — call it Y. The third is how long until a cryptographically relevant quantum computer exists — call it Z.

Mosca’s observation is simply this: if X + Y > Z, you are already exposed. By the time encryption can be broken, you will neither have finished migrating, nor will your data have aged out of sensitivity. The protection runs out before the secret does.

Read it once more and notice what it does. It removes the need to win the argument about Z.

Why this reframing helps a Swiss banking audience

The Swiss regulatory environment has trained institutions to move carefully, deliberately, and in step with their supervisor. That discipline has served the industry well. For quantum security, however, the regulatory timeline and the threat timeline are not aligned — and the gap between them is where the real risk lives.

Mosca’s inequality is useful precisely because it is supervisor-friendly. It does not ask a board to accept a speculative date. It asks two questions an institution can actually answer about itself: how long must this data stay secret, and how long will we take to migrate? This boils down to one important question: by when can we be quantum-safe?

For a Swiss bank, the first number is often uncomfortably large. Wealth structures, custody records, M&A advisory instructions, correspondent banking flows — these carry legal and fiduciary weight not for three years but for decades. That is the heart of the “Harvest Now, Decrypt Later” problem: an adversary does not need Q-Day to begin. They can copy encrypted data today and simply wait for the decryption window to open, whenever it does. For an institution whose confidentiality obligations span a generation, harvested data loses none of its weight in the interval.

Where institutions underestimate Y

If X is large and largely fixed, the variable an institution can actually influence is Y — the time to migrate. And Y is almost always underestimated.

The reason is rarely the cryptography itself. The finalised NIST standards — FIPS 203, 204 and 205, published in August 2024 — give engineers well-defined algorithms to work with. The difficulty is everywhere else: in not knowing where cryptography lives across a sprawling estate, in third-party and vendor dependencies, in protocols that cannot simply be swapped without breaking interoperability with counterparties and market infrastructure.

The recent BIS Project Leap work is instructive here. When central banks and SWIFT tested post-quantum cryptography in a real payment-system setting, the algorithms worked — but they also surfaced performance and message-size issues that required meaningful redevelopment. That is Y in the real world. Migration is an operating programme, not a configuration change.

Y also cannot begin in earnest until an institution can see its own cryptographic estate. You cannot migrate what you cannot find. This is why a credible cryptographic inventory — the kind QuRisc Scout is built to produce — is not the glamorous part of the work, but it is the part that makes every later step possible.

What good looks like

Good, in my experience, is not a heroic sprint. It is an honest sum, calculated early. It is then a prudent appraisal of migration priority within budget constraints, followed by speedy execution.

It begins with X: a clear-eyed view, by data class, of how long confidentiality genuinely matters — a question the business, not only IT, must answer.

It continues with Y, grounded in an actual inventory rather than an optimistic estimate. Finding what to migrate, how, when, and to which new algorithm across your cryptographic asset estate is akin to finding needles in a haystack. Legacy, correlations and third-party dependencies further fog up decision-making. On top of it all, you need to convince stakeholders across business, finance and IT to align around a common objective view. This is exactly why we built QuRisc Atlas with our secret sauce: AI, hundreds of rules, and three industry-standard risk models.

And it treats Z not as a single date to be guessed, but as a forecast with a range — which is exactly how it should be modelled, with confidence intervals rather than false precision, and different estimates for different encryption types and strengths. QuRisc Augur exists to put discipline around that third number, so the first two can be weighed against something better than a headline.

None of this requires alarm. It requires arithmetic, done sooner rather than later.

The case for doing the sum now

The cost of waiting is accumulating — often faster than anticipated. Not because Q-Day has a confirmed date, but because X is long, Y is longer than most assume, and the harvesting that makes the whole equation urgent does not wait for permission.

FINMA expects institutions to manage their technological risks proactively, and the EU’s DORA framework now expects financial entities to monitor cryptographic threats, including those arising from quantum advances. Neither prescribes a precise quantum deadline. Mosca’s inequality offers something more useful than a deadline: a way to work out your own.

So I would gently put the same question to you that I put to the boards I speak with. Forget Q-Day’s date for a moment. What are you doing to compress your Y in the most cost- and time-efficient manner?

Author bio

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 — including 10+ years in global banking and financial services — and holds a quantum computing qualification from MIT’s executive education.

Call to action

If you would like to discuss your institution’s quantum security posture, we would welcome the conversation. Contact us at info@sequre.ch or visit www.sequre.ch.

Why Q-Day Is Different For Every Algorithm ?

amit.agarwal@sequre.ch (Amit Agarwal) — Fri, 05 Jun 2026 13:39:36 GMT

There is a comforting fiction in boardrooms: that somewhere ahead lies a single date when quantum computers switch on, encryption breaks, and the industry deals with it together. It is a tidy story. It is also wrong.

That tidy story will leave your most sensitive assets exposed for years longer than they need to be. Q-Day is not one date. It is a spectrum. Different cryptographic algorithms fall at different times, for different reasons, and the gap between the first and the last is measured in years. Treating it as a single calendar event is the fastest way to migrate the wrong things first.

What “breaking encryption” actually means

Two quantum algorithms drive the threat, and they behave very differently. The headline “quantum breaks encryption” conflates two very different fates: your asymmetric cryptography is in existential danger, while your strong symmetric cryptography is largely fine.

Shor versus Grover — two algorithms, two very different consequences for a bank’s cryptography.

Shor’s algorithm (Peter Shor, 1994) attacks the mathematics underneath public-key cryptography — the factoring and discrete-logarithm problems behind RSA and elliptic-curve cryptography (ECC). Against these, a sufficiently large, fault-tolerant quantum computer is not incrementally faster; it is catastrophic. RSA and ECC do not weaken gracefully. They fail.

Grover’s algorithm (Lov Grover, 1996) is the milder threat. It speeds up brute-force search quadratically, which matters for symmetric ciphers such as AES. But quadratic is not exponential: Grover effectively halves the security level, so AES-256 retains roughly 128 bits of security — still comfortably out of reach. AES-128 is weakened but not trivially broken.

Why the timelines diverge

Even within the vulnerable algorithms, exposure is not uniform.

RSA-1024 falls well before RSA-2048 — smaller keys require fewer logical qubits to break.
ECC is acutely exposed. Its compact key sizes, prized for efficiency, mean it requires comparatively fewer quantum resources than RSA of equivalent classical strength.
AES-256 is, on current understanding, resilient against the known quantum attacks for the foreseeable horizon.
The NIST post-quantum standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), finalised by NIST in August 2024 and derived from CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+ — are the replacements built to withstand both Shor and Grover.

The timing itself remains a genuine forecast, not a fact. The Global Risk Institute’s Quantum Threat Timeline Report 2025 places expert median estimates for a cryptographically relevant quantum computer broadly in the early-to-mid 2030s, with meaningful probability mass earlier. Resource estimates are also moving: in 2025, Google researcher Craig Gidney published academic research suggesting RSA-2048 could in principle be broken with under one million qubits — a sharp reduction from his own 2019 figure. That is a research estimate of what may become possible, not a deployed capability — but the direction of travel is one way.

Why a single date is the wrong planning unit

If RSA-1024, RSA-2048, ECC and AES all carry different risk on different horizons, then a single migration deadline forces a false choice. You either over-invest early on assets that are not yet at risk, or you under-protect the ones that are — including data already being harvested today under Harvest Now, Decrypt Later, where the relevant clock started years ago.

The intelligent unit of planning is not the calendar. It is the algorithm, weighted by the criticality and shelf-life of the data it protects.

This is precisely what SeQure’s QuRisc is built to do: forecast a separate Q-Day per algorithm class, identify cluster risk hotspots using correlation, forecast risks 5–10 years into the future and their corresponding CHF value impact, so migration can be sequenced by genuine exposure and risk in CHF rather than by a single, misleading headline year. Visibility first, then prioritisation: which algorithms, protecting which data, need to move first.

What this means for a Swiss bank

For institutions under FINMA supervision and within scope of DORA, the obligation is not “be quantum-safe by date X.” It is to demonstrate that you understand your cryptographic risk, have prioritised it sensibly, and are managing it. A per-algorithm view is what makes that demonstrable — and what turns an unbounded anxiety into a finite, sequenced, defensible roadmap.

The single date was always a fiction. The sooner it is retired, the sooner the real work — visibility, prioritisation, migration, crypto-agility — can begin.

See your bank’s per-algorithm Q-Day forecast → book a 30-minute discovery call at www.sequre.ch

Amit Agarwal is CEO and Co-Founder of SeQure AG, a Swiss quantum-security company for banks and financial institutions. He brings 25+ years across software, SaaS, payments and FinTech, and holds a quantum computing qualification from MIT’s executive education.

#SeQureAG #QuantumSecurity #PostQuantumCryptography #FINMA #DORA #SwissBanking #QDay #PQC #CryptographicInventory #CryptoAgility #AI #ArtificialIntelligence #Cybersecurity