Design crypto agility as an operating capability
Crypto agility means being able to change algorithms, key sizes, certificates and implementations without redesigning the business service. In practice, that requires abstraction layers, configuration-driven choices, versioned interfaces, dual-certificate or hybrid options where appropriate, and telemetry that identifies which cryptographic path is in use. It also requires controlled rollback. A bank should know how to reverse a migration if a product defect, interoperability failure or standards change appears.
The BIS roadmap cautions that migration is not a simple algorithm replacement and points to performance trade-offs, system integration, defence in depth, hybrid models and phased migration. The strategic value of agility is therefore broader than quantum risk. It lowers the cost of responding to future cryptographic weaknesses, certificate changes and supplier transitions.
Use pilots to test services, not demonstrations
BIS Project Leap phase 2 replaced traditional digital signatures with post-quantum cryptography in an operational payment-system experiment. The work required changes across multiple components and found meaningful performance differences between algorithms. Its most useful lesson for commercial banks is that a successful proof of cryptography is not the same as a production-ready service.
A bank pilot should include realistic transaction volumes, peak bursts, certificate rotation, failover, audit logging, exception handling and recovery. It should test both ends of a connection and the components between them. Results need business metrics: added latency, throughput headroom, message growth, operational effort, compatibility failures and total cost. Production entry should depend on agreed thresholds and a clear fallback path.
Bring suppliers and counterparties into the critical path
Banks depend on cloud services, payment processors, core platforms, network providers, certificate authorities, software vendors and financial market infrastructures. Migration can stall if a material supplier cannot expose its cryptographic dependencies, commit to supported standards or coordinate testing. Procurement should therefore make quantum readiness observable through product roadmaps, supported algorithms, validation status, upgrade terms, end-of-support dates and evidence from interoperability testing.
The Bank of England said in July 2026 that firms should seek assurance on how material third parties are preparing for post-quantum safety. Contractual rights help, but governance matters just as much. Banks should maintain a dependency calendar showing when vendors, shared platforms and counterparties will be ready, because the slowest essential connection may determine the feasible migration date.
A phased bank roadmap to 2035
The UK NCSC recommends completing discovery and an initial migration plan by 2028, migrating the highest-priority services by 2031 and completing migration by 2035. These are useful planning anchors even outside the UK because they translate a broad technology risk into investment windows. They are targets, not permission to wait. Large banks may need two or three budget cycles simply to finish discovery, supplier alignment and remediation of inventory gaps.
Now to 2028: establish control
Name an executive sponsor and accountable programme owner. Define the inventory schema, scan the estate, validate findings with service owners and identify data with long protection horizons. Publish technology standards for new systems so fresh quantum-vulnerable dependencies are not added unnecessarily. Begin supplier outreach and select pilots that represent different constraints, such as customer channels, code signing and wholesale payments.
2028 to 2031: migrate high-priority services
Move use cases where approved products, tested protocols and counterparties are ready. Combine migration with certificate renewal, platform modernisation and hardware refresh to reduce duplicate work. Track residual exposure by important business service, not only by asset count. Exercise rollback, incident response and business continuity under the new cryptographic path.
2031 to 2035: complete and simplify
Finish complex legacy and long-tail dependencies, remove temporary hybrid paths when policy allows, and retire vulnerable algorithms in a controlled sequence. The end state should be simpler to operate than the starting point: fewer unmanaged libraries, clearer ownership, better key governance and evidence that cryptographic change can be executed repeatedly.
Governance and measures that keep the programme honest
Board and executive reporting should focus on exposure and delivery confidence. Useful measures include the percentage of important services with a validated cryptographic inventory, high-priority dependencies with a funded plan, material suppliers with confirmed roadmaps, pilots that meet performance thresholds, and quantum-vulnerable uses introduced after the new-design standard took effect. An asset total without criticality or validation can create false comfort.
Risk acceptance should be time-bound and attached to a service owner. Architecture exceptions should identify the blocking dependency, interim controls, trigger for reassessment and exit date. Internal audit can test whether the inventory is complete enough to support decisions and whether evidence from suppliers and pilots is reproducible.
Fund migration through service roadmaps, not a single security pot
A central programme needs budget for discovery tooling, standards, specialist skills and shared testing, but most implementation cost will sit inside applications, infrastructure and supplier contracts. Banks should tag quantum-readiness work in service roadmaps so it can be combined with certificate renewal, operating-system upgrades, network modernisation and hardware replacement. That reduces repeat disruption and makes the true cost visible to the owners who control delivery.
Investment decisions should distinguish no-regret work from technology-dependent work. Inventory, ownership, data-longevity analysis, supplier questions and architecture standards are useful immediately. Large-scale replacement of a particular product may depend on validated modules, protocol support and counterparty readiness. This separation prevents uncertainty about future quantum capability from becoming an excuse to delay foundational control work.
Each migration wave should pass explicit gates: a verified dependency map, approved design, performance evidence, supplier and counterparty readiness, continuity testing, rollback and a plan to retire the old cryptographic path. The gate owner should be able to stop deployment when evidence is incomplete. That discipline matters because a rushed security upgrade can itself create availability, authentication or reconciliation risk in a critical financial service.
Frequently asked questions
What is post-quantum cryptography in banking?
It is the use of cryptographic algorithms designed to resist attacks from both classical and future quantum computers. In banking, it affects encryption, signatures, certificates, identity, software integrity and connections across the financial ecosystem.
Should banks wait for quantum computers to become practical?
No. Migration takes years, some data needs long-term confidentiality, and standards are already available for controlled use. Planning now reduces the chance of rushed changes later. The pace of each deployment should still reflect product maturity, standards and tested business requirements.
What should a bank inventory first?
Start with important business services and map their certificates, keys, algorithms, protocols, libraries, hardware, data-protection horizons and third-party dependencies. Include code signing, devices and legacy platforms, not just public websites.
Are hybrid cryptographic approaches always required?
No. Hybrid approaches can reduce transition risk in selected cases, but they add operational and interoperability complexity. Banks should use them where standards, risk and counterparties support a clear purpose, with an exit plan.
What is the most important board-level question?
Ask whether the bank can identify and change the cryptography supporting its most important services within a controlled timetable. That question tests inventory quality, ownership, supplier readiness, funding and operational resilience at once.
The practical conclusion
The strongest bank post-quantum cryptography migration programme will look less like a speculative science project and more like disciplined technology risk management. It will connect evidence to service criticality, align upgrades with investment cycles and force visibility into supplier dependencies. Banks that build that machinery now gain more than quantum readiness: they gain a repeatable way to change cryptography without losing control of the service it protects.
References
BIS: Quantum-readiness for the financial system - a roadmap - Financial-system framework covering inventory, agility, hybrid models and phased migration.
BIS Innovation Hub: Project Leap phase 2 - Operational payment-system experiment using post-quantum digital signatures.
NIST: Post-Quantum Cryptography project and standards - Status of FIPS 203, FIPS 204 and FIPS 205 and migration guidance.
UK NCSC: Timelines for migration to post-quantum cryptography - Discovery, priority-migration and completion milestones for large organisations.
Bank of England: Financial Stability Report, July 2026 - Current financial-sector assessment of quantum preparedness and third-party dependencies.
