Perspective

Post-Quantum Cryptography

How global financial institutions can meet regulators' post-quantum expectations across every jurisdiction they operate in, without a budget-breaking programme. The short version: discover once, prioritise by risk, migrate with the refresh cycle, and automate the lifecycle.

New to this? Start with the plain-language version.

1. Why this matters now

Almost every secure connection, digital signature and encrypted record in a bank today depends on public-key cryptography, mainly RSA and elliptic-curve algorithms. They protect online banking sessions, interbank messaging, card payments, code signing, VPNs, API traffic between services, and the certificates that let systems trust each other.

A sufficiently powerful quantum computer would break those algorithms. No one can say exactly when one will exist, but the financial sector cannot wait to find out, for three reasons.

Harvest now, decrypt later

An adversary can record encrypted traffic today and store it until it can be decrypted. Anything that must stay confidential for years, such as customer records, account data, trading strategies, merger documents and long-dated contracts, is already exposed to this risk if it crosses a network protected by quantum-vulnerable key exchange.

Forged signatures and broken trust

Once signature algorithms can be broken, an attacker could forge transaction approvals, software updates or certificates. For institutions whose business is trust in transactions, this is an existential risk, not an IT issue.

Migration takes a decade

Large banks run thousands of applications across mainframes, data centres, clouds, branches, ATMs, trading venues and third parties. Previous cryptographic migrations, such as retiring older hash functions, took many years with far smaller scope. A widely used rule of thumb puts it simply: if the time your data must stay secret, plus the time it takes you to migrate, is longer than the time until a capable quantum computer exists, you are already late.

The new standards are ready

The United States National Institute of Standards and Technology published the first post-quantum standards in August 2024: ML-KEM for key establishment (FIPS 203), and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. Further algorithms are following. Mainstream browsers, operating systems and cryptographic libraries already support hybrid key exchange that combines a classical and a post-quantum algorithm. The excuse that "the standards aren't finished" has gone.

2. What regulators expect

Regulators and national cyber authorities across major financial centres have moved from awareness to expectation. Their language differs, but the themes are strikingly consistent:

• Know your cryptography: a complete, maintained inventory of where and how cryptography is used.
• Assess the risk: identify which systems and data are most exposed, including to harvest-now-decrypt-later.
• Have a plan: a funded, time-bound migration roadmap with board-level oversight.
• Be crypto-agile: the ability to change algorithms, keys and certificates quickly without redesigning systems.
• Manage third parties: understand and influence vendors' and service providers' post-quantum readiness.
• Show evidence: demonstrate progress with records, not slides.

The table below summarises key signals relevant to global financial institutions as of 2026. It is a starting point, not legal advice; requirements are evolving and should be confirmed for each entity and jurisdiction.

3. How institutions overspend

Post-quantum migration can easily become one of the most expensive technology programmes an institution has ever run. The overspending usually comes from a handful of predictable mistakes.

• Manual inventories. Teams of consultants interview application owners and fill in spreadsheets. The result is incomplete on the day it is finished and stale within months, and it has to be done again for the next audit.
• One inventory per regulator. Different regions produce separate inventories and reports for their local supervisors, duplicating effort and producing numbers that do not reconcile.
• Big-bang replacement. Programmes that try to change everything at once, on a fixed date, pay premium rates for scarce skills and disrupt change calendars.
• Replacing hardware early. Hardware security modules, network appliances and payment devices are replaced before end of life when a firmware upgrade, a later refresh or a protective wrapper would have done.
• Rewriting legacy applications. Core systems that are hard to change are rewritten for cryptography alone, when the traffic could have been protected around them.
• Treating it as a one-off project. The programme ends, the team disbands, and the next algorithm change starts from zero.

4. Principles of a frugal programme

1. Automate discovery. Let tools find cryptography continuously; reserve people for decisions.
2. Inventory once, report many times. One global source of truth, mapped to every regulator's requirements.
3. Spend in order of risk. Protect long-lived confidential data and critical trust anchors first; let low-risk items wait for natural change.
4. Ride the refresh cycle. Make post-quantum support a condition of every purchase and upgrade, so most migration happens through change that is already funded.
5. Wrap what you cannot change. Protect legacy systems at the network layer rather than rewriting them.
6. Build agility, not just compliance. Centralise the lifecycle of keys and certificates so the next change is cheap.
7. Make evidence a by-product. If the tooling produces audit evidence automatically, compliance reporting costs almost nothing extra.

5. The two-layer architecture

A frugal programme rests on two complementary capabilities, ideally from specialised platforms that integrate with each other.

Layer 1: Discovery and inventory

A specialised discovery platform scans the estate continuously and builds a cryptographic inventory, sometimes called a cryptographic bill of materials. It answers: which algorithms, key lengths, protocols, libraries and certificates are in use, on which systems, protecting which data flows, and how vulnerable each is to quantum attack. The best tools combine several techniques, because no single one sees everything, and score each finding by risk. Some also offer a way to apply post-quantum protection to traffic in transit without changing the systems at each end, which is valuable for legacy estates.

Layer 2: Lifecycle management

A lifecycle management platform governs keys and certificates from creation to retirement: issuance, renewal, rotation, revocation, policy enforcement and migration workflows, across public and private certificate authorities, cloud key services and hardware security modules. It is the layer that actually performs the change, at scale and on schedule, and it is what makes an institution crypto-agile rather than merely compliant this time.

Why two layers, not one

Discovery without lifecycle management produces an accurate list of problems and no means to fix them. Lifecycle management without discovery only manages what it already knows about, and the riskiest cryptography is usually the cryptography nobody knew was there. Integrated, the inventory feeds the lifecycle platform's work queue, and every change the lifecycle platform makes updates the inventory.

6. Step 1: Discover and inventory

Cryptography hides everywhere. A complete inventory draws on several sources:

• Network observation: passive analysis of handshakes and protocols reveals what is actually negotiated in production, including on systems no one owns any more.
• Code and dependency scanning: finds cryptographic libraries and calls in source repositories and build pipelines.
• Binary and container scanning: catches cryptography in packaged and third-party software where no source is available.
• Host and endpoint agents: find keys, certificates and configurations on servers and devices.
• Cloud and platform connectors: enumerate cloud key services, load balancers, managed databases and API gateways.
• Hardware security modules and PKI: list keys, algorithms and certificate hierarchies at the root of trust.
• Third parties: structured questionnaires and contract terms covering vendors' and service providers' cryptography and post-quantum plans.

For each finding, record the algorithm and key size, protocol, location, owning business service, data classification, how long the protected data must remain confidential, and whether the component can be changed by configuration, upgrade, replacement or only by wrapping.

Frugal tip: start with network observation and existing certificate and key repositories. They cover a large share of the estate quickly and cheaply, and show where deeper scanning is worth the effort.

7. Step 2: Prioritise by risk

Not everything needs to move first, and spending evenly across the estate wastes money. Score each item on four factors:

• Data shelf life: how long the data must stay confidential. Ten-year data on a quantum-vulnerable link today is a present risk.
• Trust impact: roots of trust, signing keys and certificate authorities affect everything beneath them.
• Exposure: internet-facing and cross-organisation links are easier to harvest than isolated internal traffic.
• Business criticality: payments, settlement, customer authentication and market infrastructure links matter most.

Combine these into three practical tiers:

8. Step 3: Migrate economically

Take the free upgrades first

Many components gain post-quantum or hybrid support through routine updates to operating systems, libraries, browsers, load balancers and cloud services. Enabling them is often a configuration change. Hybrid key exchange on external TLS is the single highest-value, lowest-cost early move for most institutions.

Write it into procurement

Require post-quantum support, or a committed roadmap, in every new contract and renewal for software, hardware, cloud and managed services. This costs nothing and moves the burden to vendors, who are spreading the cost across all their customers.

Align with the refresh cycle

Map planned hardware and software end-of-life dates against the regulatory timeline. Anything due for replacement before the deadline should be replaced with post-quantum-ready equipment as part of normal refresh, not replaced early.

Upgrade before you replace

Hardware security modules and network appliances often gain post-quantum algorithms through firmware. Check before budgeting for new hardware.

Wrap the legacy

Mainframes, core banking platforms and specialised devices may be impractical to change before the deadline. Protect their traffic with post-quantum tunnels or gateways in front of them, buying time without rewriting anything. Record the residual risk honestly and schedule the permanent fix with the system's eventual modernisation.

Use hybrid modes during transition

Combining a classical and a post-quantum algorithm protects against both today's and tomorrow's threats, and against the possibility of a weakness emerging in a newer algorithm. It also preserves interoperability with counterparties who are not ready yet.

Remember symmetric cryptography

Symmetric encryption and hashing hold up far better against quantum attack. Moving to larger key sizes, such as 256-bit symmetric keys, is usually enough, and it is cheap.

9. Step 4: Run the lifecycle

Post-quantum migration is not a single change. It is the first of many: algorithms will be refined, parameters adjusted, and certificate lifetimes across the industry are shortening sharply, towards weeks rather than years for public TLS certificates. Manual certificate management at bank scale will not survive that on its own.

A central lifecycle platform pays for itself several times over:

• Automation: certificates and keys are issued, renewed and rotated without tickets or spreadsheets, removing the outages caused by expired certificates.
• Policy as control: approved algorithms and key sizes are defined centrally and enforced at issuance, so quantum-vulnerable choices cannot creep back in.
• Bulk migration: once a system is ready, its certificates can be reissued with new algorithms in a single controlled operation.
• Agility: the next algorithm change becomes a policy update and a workflow, not a programme.

10. One body of evidence, many regulators

The single biggest saving for a global institution comes from refusing to run separate compliance efforts per jurisdiction. Build one control set from the union of requirements, and map each control to the evidence the tooling produces automatically.

Each regional compliance team then produces its local report from the same data, in the local format and language. The numbers reconcile, auditors see a living system rather than a spreadsheet, and audit preparation shrinks from weeks to days.

11. An illustrative cost comparison

The comparison below is qualitative and illustrative, based on common patterns rather than benchmark data. Actual results depend on the estate.

As a worked example with stated assumptions: if 60% of affected systems reach planned end of life before the applicable deadline, and post-quantum support is written into their replacement contracts, those systems need little or no dedicated migration budget. The programme's own spend then concentrates on the remaining 40%, and within that, on the "act now" tier. Your own proportions will come out of the inventory.

12. Running it globally

Global institutions succeed with a hub-and-region model, the same pattern that works for federated security operations:

• A central programme office owns the tooling, the global control set, the approved-algorithm policy, the risk model and board reporting.
• Regional teams own local regulatory engagement, local reporting, and coordination with local business units, vendors and counterparties.
• Platform owners such as cloud, network, mainframe and payments teams execute migrations in their domains against central priorities.
• The earliest deadline sets the pace for shared infrastructure; regional timelines are only relevant for region-specific systems.
• Data residency is respected: inventory data that reveals sensitive architecture can be held regionally and aggregated centrally as metrics.

13. A roadmap to 2035

1. Mobilise (first 3 months). Appoint an accountable executive, set up the programme office, agree the global control set, and select discovery and lifecycle platforms.
2. Discover (months 3–12). Deploy discovery across priority environments, consolidate existing certificate and key repositories, and produce the first risk-scored inventory and board report.
3. Quick wins (months 6–18). Enable hybrid key exchange on external services, update procurement standards, automate certificate lifecycle for the most outage-prone estates, and apply symmetric key upgrades.
4. Protect the crown jewels (by 2028–2030). Migrate or wrap the "act now" tier, including long-lived data flows, roots of trust and signing infrastructure, in step with the earliest applicable deadline.
5. Migrate through the cycle (2028–2033). Move the "plan" tier through scheduled upgrades, and let the "ride the cycle" tier migrate through refresh.
6. Close out (by 2035). Retire remaining quantum-vulnerable algorithms, remove wrappers as legacy systems are modernised, and keep the lifecycle platform running for the next change.

14. How to measure progress

15. Common questions

Is a quantum computer that can break today's encryption actually coming?

No one can give a date, and estimates vary. Regulators have decided that the risk, combined with harvest-now-decrypt-later and long migration times, justifies acting now. For a regulated institution, that settles the question.

Can we wait until the technology matures further?

The standards are published and supported in mainstream products. Waiting compresses the same work into less time, which is the most expensive way to do it.

Will post-quantum algorithms slow our systems down?

Post-quantum keys and signatures are larger, which can matter for constrained devices and very high-volume protocols. For most enterprise traffic the impact is modest. Testing in priority environments early is part of a sensible plan.

Do we need to replace our hardware security modules?

Not necessarily. Many can be upgraded through firmware. Confirm with each vendor before budgeting for replacement.

Why two separate platforms rather than one?

Discovery and lifecycle management are distinct disciplines, and specialised platforms tend to be stronger at each. What matters is that they integrate, so the inventory drives the work and the work updates the inventory.