← Guide overview

A phased roadmap

Quantum Readiness for Banking Professionals: all chapters

• 1. What quantum threatens in a bank, and what it doesn't
• 2. Where cryptography lives in a payments estate
• 3. Building a cryptographic inventory
• 4. Deciding what to fix first
• 5. Crypto-agility first
• 6. Vendors and third parties
• 7. Governance and the regulatory map
• 8. A phased roadmap
• Readiness self-assessment
• Glossary

On this page

1. The four phases
2. Phase 1: Inventory and crypto-agility (now to 2027)
3. Phase 2: Hybrid pilots (2027 to 2029)
4. Phase 3: Production migration (2028 to 2031)
5. Phase 4: Retire the old algorithms (2030 to 2035)
6. Making milestones testable
7. The critical path
8. When to re-plan
9. Larkfield's first 100 days
10. A closing thought
11. Sources and further reading

The earlier chapters each covered one part of the work. This final chapter puts them together into a roadmap: four phases, timed against the 2030 and 2035 horizon that most guidance points to, with a clear description of what "done" looks like at each stage. It ends with Larkfield's first 100 days, because the hardest part of any long programme is the start.

The four phases

1. Inventory and agility

to 2027

2. Hybrid pilots

2027–29

3. Production migration

2028–31

4. Retire the old algorithms

2030–35

One distinction runs through every phase: readiness is not completion. A finished inventory doesn't make a system quantum-safe. A supplier's announced support doesn't mean a compatible product is installed. A successful pilot doesn't prove production readiness. Report each separately.

Phase 1: Inventory and crypto-agility (now to 2027)

Everything else depends on this phase. It's also where most banks are today.

• Inventory the highest-priority business flows (Chapter 3), and score the results (Chapter 4).
• Start the agility measures: certificate automation, a ban on hard-coding in new systems, and a common cryptography service (Chapter 5).
• Tier suppliers, send questionnaires and update contract templates (Chapter 6).
• Set up governance: owner, sponsor, risk register entry and reporting (Chapter 7).
• Confirm HSM and certificate authority readiness, because they block everything else.

Done looks like: the critical flows inventoried with most records documented; a ranked, scheduled list of work; Tier 1 supplier positions known; certificate automation under way; and post-quantum requirements written into upcoming refreshes.

Phase 2: Hybrid pilots (2027 to 2029)

This phase starts cutting real exposure. Following the "harm you can't undo first" principle, it focuses on key agreement for connections carrying long-lived sensitive data.

• Turn on hybrid key agreement, combining a current algorithm with ML-KEM, on the highest-exposure connections, starting with the easy, configurable ones.
• Pilot post-quantum certificates in a test environment, including longer certificate chains and larger signatures.
• Upgrade or replace HSMs and certificate authorities that block later work.
• Measure the effect of larger keys on performance, storage and message sizes.

Done looks like: new traffic on the most sensitive connections no longer exposed to harvesting; the blocking components ready; and evidence from pilots that the new algorithms work in Larkfield's environment.

Phase 3: Production migration (2028 to 2031)

This phase is the bulk of the engineering. It extends hybrid key agreement across the estate and moves signatures and certificates to the new standards.

• Roll hybrid or post-quantum key agreement across remaining connections, in order of priority.
• Move certificate chains to post-quantum signatures, from the authorities down. Publicly trusted certificates depend on browsers, certificate authorities and industry rules moving too, so treat those milestones as ecosystem dependencies, not dates Larkfield controls.
• Move code signing and key storage to the new algorithms.
• Migrate in step with payment networks and suppliers as their support arrives.

Done looks like: high-priority systems using post-quantum or hybrid cryptography for both key agreement and signatures, around the 2030 point that draft NIST guidance identifies for deprecating today's algorithms.

Phase 4: Retire the old algorithms (2030 to 2035)

The final phase removes RSA and elliptic-curve cryptography from the estate, including the classical half of hybrid arrangements where appropriate. If Phase 1 built agility well, much of this is configuration rather than engineering.

• Switch off the classical half of hybrid arrangements where standards and partners allow.
• Replace or isolate remaining legacy systems that can't be migrated.
• Keep the inventory current, so nothing quietly reintroduces old algorithms.

Done looks like: verified, not assumed: scans and inventory checks confirm quantum-vulnerable public-key cryptography is retired from the payment path and core systems by 2035, with any exceptions documented, risk-accepted and time-limited.

Making milestones testable

A milestone a steering committee can rely on needs more than a name and a date. Larkfield defined every milestone with four fields:

Field	What it records	Example: hybrid key agreement on online banking
Deliverable and owner	What will exist, and who is accountable	Hybrid key agreement live on the online banking load balancers; digital channels technology lead
Entry criteria and dependencies	What must be true before work starts	Approved architecture; load balancer firmware supporting the hybrid method; test environment available
Evidence of completion	How you'll know it's really done	Interoperability and security testing passed; performance results within limits; monitoring in place; rollback tested; traffic sampling shows connections actually using the approved configuration
Risks and escalation	What could go wrong, and when to escalate	Older customer browsers or devices failing to connect; escalate if connection failures exceed the agreed threshold

The critical path

Larkfield's plan has a handful of dependencies that decide its overall pace. If any of them slip, everything behind them slips too.

1. HSM support for the new algorithms, needed before new keys can be created and stored.
2. Certificate authority support, needed before post-quantum certificates can be issued.
3. Certificate automation, needed before thousands of certificates can realistically be replaced.
4. Payment network timetables, which set the pace for interbank signatures.
5. Core platform supplier support, which gates much of the internal estate.

A programme lead's most important job is to watch these five closely and escalate early.

When to re-plan

A ten-year roadmap will change. Larkfield agreed in advance on what would trigger a formal review:

• a new or revised standard or regulatory expectation;
• a credible change in expert estimates of when quantum computers could break current cryptography;
• a weakness found in one of the new algorithms;
• a critical supplier changing its roadmap;
• a major architecture change, merger or system replacement.

Agreeing triggers in advance stops the plan from being reopened every time a headline appears, and makes sure it is reopened when something material happens.

Larkfield's first 100 days

For a bank starting from zero, this is what Larkfield's programme owner committed to in the first 100 days:

1. Days 1–15: confirm sponsor and owner; add the risk register entry; form the working group.
2. Days 15–30: choose the pilot flow; agree the inventory template, confidence labels and single source of truth.
3. Days 30–60: run the first scans; send pre-filled drafts to teams to confirm or correct; send Tier 1 supplier questionnaires.
4. Days 60–80: score the pilot items; confirm HSM and certificate authority readiness; brief procurement on contract clauses.
5. Days 80–100: present the first ranked plan to the steering committee, with the six measures from Chapter 7 as its baseline.

None of that requires a single post-quantum algorithm to be deployed. It's governance, coordination and analysis, which is exactly why the people reading this guide are the ones who have to start it.

A closing thought

Quantum computing makes for alarming headlines and uncertain forecasts. The response doesn't have to be either. It's a long, methodical change programme of a kind banks have run before, from retiring old encryption standards to moving whole payment systems onto new message formats. The difference this time is the lead time, and that's the one thing a bank can't buy back later. Starting now, calmly and in the right order, is the whole strategy.

Sources and further reading

Larkfield Bank is fictional and its figures are illustrative. Everything else is drawn from the public sources below. Tags show what kind of source each one is. A standard or government guidance is an official document; a peer-reviewed paper has been checked by other experts; a preprint has not been peer-reviewed yet; an experiment reports a real-world demonstration; a company announcement is the company's own account. Checked on 11 October 2026. Spotted an error? Email hello@plainquantum.com.

1. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024
2. Government guidanceRoadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Security, 2025
3. Government guidanceA Coordinated Implementation Roadmap for the Transition to Post-Quantum CryptographyEuropean Commission / NIS Cooperation Group, 2025
4. Industry guidanceG7 Cyber Expert Group: coordinated roadmap for the transition to post-quantum cryptography in the financial sectorG7 Cyber Expert Group (via US Treasury), 2026
5. Government guidanceConsiderations for Achieving Cryptographic Agility (CSWP 39)NIST
6. StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024