Post-quantum migration for financial institutions: costs, suppliers and milestones

Post-quantum migration is a technology change programme that replaces vulnerable cryptographic dependencies across systems, services and counterparties. A financial institution should start with ownership, an inventory and risk priorities, then connect supplier roadmaps to testing and migration budgets. It does not require purchasing a quantum computer. Current international statements and national guidance provide planning signals, but their legal status differs. The January 2026 G7 roadmap expressly does not establish regulatory expectations; institutions must map obligations to the jurisdictions and services concerned.

What is being migrated, and why does scope matter?

NIST finalised its first three post-quantum cryptography standards in August 2024: ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. These are cryptographic tools for conventional computing environments. An algorithm standard is not a complete implementation or a declaration that an existing banking application has been migrated. Software, protocols, certificates, hardware and operational processes still have to work together.

Begin with business services rather than a catalogue of algorithms. A payment connection may depend on endpoint software, an authentication chain, a hardware security module and counterparties outside the bank. Changing one library leaves the service incomplete if another dependency cannot interoperate. Scope should also include long-lived information whose confidentiality matters beyond the immediate transaction. The inventory needs to connect technical assets with the business owner who can decide how and when each dependency changes.

Which dates are planning targets and which are obligations?

The G7 Cyber Expert Group's January 2026 statement is a non-prescriptive coordination framework. It discusses 2035 as an overall target and earlier treatment of critical systems, while explicitly disclaiming guidance or regulatory expectations. Its value is a common language for programme planning across interconnected institutions; it is not a universal legal deadline or a guaranteed date for the arrival of a cryptographically relevant quantum computer.

In the UK, the NCSC's migration guidance sets targets of discovery and initial planning by 2028, early high-priority migration by 2031 and completion by 2035. These are national technical planning milestones. A multinational group should maintain a jurisdiction register linking each applicable rule, supervisory communication and technical recommendation to its proper status. An internal target can be earlier than an external date where long replacement cycles or data lifetimes justify it.

What should the discovery phase deliver?

The useful deliverable is a maintained dependency map with named owners and evidence quality. Record which service uses the cryptography, what information it protects, who operates it and which third party controls its replacement. An automatically discovered certificate and a supplier questionnaire answer are different kinds of evidence. Unresolved or inaccessible assets should remain visible, with a plan for investigating them. A reassuring count of discovered assets is not enough if the most important service is poorly understood.

Discovery should end with a prioritised work programme, not an indefinitely growing spreadsheet. For each service, distinguish routine vendor updates from applications needing bespoke engineering or replacement. Identify systems already due for retirement so the programme does not fund unnecessary duplication. Conversely, a planned replacement should not be treated as completed risk reduction until its timing and ownership are credible. The NCSC guidance supports this service-oriented assessment; the commercial task is to attach cost, responsibility and a decision date to the resulting gaps.

How should suppliers be assessed and contracted?

Ask suppliers for product-specific evidence. A corporate quantum-safe statement is weaker than a supported software version, protocol configuration, test record and release commitment relevant to your estate. Distinguish a development roadmap from an available feature and an available feature from an implementation validated in your architecture. Request the dependencies behind any milestone: another vendor's component, a standards decision, a hardware refresh or the customer's own configuration work can all change the delivery sequence.

Contracts should turn important claims into reviewable obligations. Define the evidence expected at design, test and acceptance stages; agree how changes to supported algorithms will be handled; and establish responsibility for integration defects. Require a practical exit route for unsupported legacy products. These are proposed purchasing criteria, not standard terms promised by any supplier. The finance team should understand which costs are included in an existing support agreement and which require a new licence, professional-services engagement or infrastructure purchase.

What does realistic interoperability testing involve?

The Bank for International Settlements' Project Leap phase 2 report examines applying post-quantum cryptography in payment-system infrastructure. Its relevance is the operational migration problem, not evidence of a quantum-computing speed-up. Testing a cryptographic mechanism in a financial workflow asks whether messages, implementations and institutions can continue to work together. An institution should treat published experiments as design evidence, then validate its own particular configuration.

A local acceptance plan should measure throughput, latency, resource consumption and failure behaviour under representative load. Include certificate renewal, key rotation, disaster recovery and counterparties running different software versions. Specify what happens when one side cannot use the intended mechanism and who can approve any temporary fallback. A laboratory demonstration that succeeds once is useful, but the operating team needs repeatability and an observable failure mode. Keep the rollback plan under the same change-control discipline as the migration itself.

How can finance and risk teams govern the budget?

Separate discovery, engineering, replacement, testing and ongoing assurance costs. This prevents a modest tooling purchase from being mistaken for the whole programme. Assign shared infrastructure costs once, while preserving the dependency of each business service on that work. Use staged funding when supplier timing remains uncertain: discovery can establish the size of the problem before an institution commits to a particular implementation route. The budget should include internal operational staff whose contribution may be more constrained than the external consultancy allowance.

Report progress through completed service outcomes. Useful measures include ownership coverage, validated supplier dependencies, priority services with approved designs and migrations that passed operational acceptance. A count of workshops or products labelled quantum-safe measures activity more than readiness. Quantum key distribution may be relevant to particular network links, but it does not remove the wider cryptographic migration programme. The network supplier guide explains that separate buying decision and the evidence required for a proposed service.