← Guide overview

Deciding what to fix first

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. Start with the two buckets
2. Mosca's test, applied item by item
3. Five things that decide the order
4. A simple scoring worksheet
5. Scores rank; lead times schedule
6. Five pitfalls
7. Taking it to committee
8. Five questions for your next steering committee
9. Sources and further reading

By the end of Chapter 3, Larkfield's pilot inventory held 140 records for a single payment flow. Across the whole bank there will be thousands. Nobody can fix them all at once, and the order matters: get it wrong and the bank spends years on easy items while the exposures that can't be undone keep growing. This chapter gives governance and programme leads a way to rank the work that a risk committee can follow and challenge.

Start with the two buckets

Chapter 1 introduced the two clocks. They become the first and most important sorting step.

Bucket 1: ConfidentialityKey agreement protecting data that must stay secret for years. Exposure builds up from today through harvesting, and it can't be reversed. No grace period.

Bucket 2: AuthenticitySignatures and certificates. Forgery, including backdated forgery, becomes possible only once a capable quantum computer exists, so this bucket is driven by deadlines and lead times, not by harm already accruing.

The principle behind the buckets is simple enough to say in a board meeting: fix the harm you can't undo first. Data captured today can never be un-captured, so confidentiality exposure on long-lived data usually leads. Signature work isn't less important, but its damage starts later, which gives the bank time to coordinate with suppliers and networks.

Mosca's test, applied item by item

For the confidentiality bucket, the University of Waterloo researcher Michele Mosca's simple inequality is the best tool there is. For any item, estimate three numbers:

• X: how long the data it protects must stay secret;
• Y: how long it will take to migrate that item;
• Z: how long until a quantum computer could break it.

If X plus Y is larger than Z, the data is at risk under that timeline: anything recorded today could still be sensitive when an attacker becomes able to decrypt it. The useful trick for governance is that you don't need to know Z. Nobody does. Instead, ask whether X plus Y exceeds the more optimistic end of credible estimates. For Larkfield's wire records, X is seven years and Y for a complex connection might be three or four. That's ten years or more: long enough that no prudent risk committee would bet the data stays safe. The item goes near the top of the list without anyone having to forecast a date.

You don't need to predict when quantum computers will arrive. You need to show that your data must stay secret longer than you'd be comfortable betting on.

Five things that decide the order

Within each bucket, five factors separate what goes first from what can wait. They come straight from the inventory fields in Chapter 3, which is why those fields matter.

1. Exposure. How sensitive is what's being protected, and for how long? This is Mosca's X.
2. Blast radius. How much depends on this item? A certificate authority that thousands of systems trust has a far larger blast radius than one application's connection.
3. Dependency order. Does anything else have to change first? You can't issue post-quantum certificates until the issuing authority supports them, and you can't use new keys in HSMs that don't support the new algorithms. Items that unblock others go early.
4. Lead time. How long will it take, including coordination with suppliers, payment networks and counterparties? Long-lead items have to start early even if they finish late.
5. Ease of change. Is the algorithm a configuration setting, pinned across several systems, or hard-coded? This mostly affects lead time and cost.

A simple scoring worksheet

Scoring doesn't need to be sophisticated. It needs to be consistent, explained and easy to challenge. Larkfield used this worksheet, scoring each factor from 1 (low) to 3 (high) and doubling exposure because it carries the irreversible harm:

Priority score = (2 × exposure) + blast radius + dependency order + lead time. Maximum 15.

Item	Exposure	Blast radius	Dependency order	Lead time	Score
HSM support for new algorithms	2	3	3	3	13
Internal certificate authority	2	3	3	2	12
Online banking connection	3	3	1	1	11
Archive key protection	3	2	1	2	11
SWIFT network certificate	2	3	1	3	11
Payments hub to messaging interface	3	2	1	2	11
Corporate client file transfers	3	1	1	3	11
Core platform software updates	2	3	1	3	11

Ease of change isn't scored separately. It's already reflected in lead time, and counting it twice would push hard-to-change items up the list for the same reason. Larkfield noted it alongside each score instead. The score ranks items; it doesn't replace dependency analysis or a formal decision to accept a risk.

Look at the result. The two highest scores aren't the most exposed items at all. They're the HSMs and the internal certificate authority, because almost everything else depends on them. And six items tie at 11. That's normal, and it leads to the most useful lesson in this chapter.

Scores rank; lead times schedule

A ranked list isn't a plan. Larkfield turned its scores into a sequence by asking a second question of each item: when do we need to start for this to finish in time?

• Start now, because others depend on them: HSM vendor readiness and the internal certificate authority. Neither protects customer data directly, but nothing else can move without them.
• Start now, because they're quick and highly exposed: the online banking connection. Its algorithm is a configuration setting at the load balancer, so hybrid key agreement can be switched on early and starts reducing harvesting exposure straight away.
• Start now, because they're slow: the SWIFT certificate, corporate file transfers and core platform updates. Larkfield can't change these alone, so the work begins as engagement: asking suppliers and the network for plans and dates.
• Next: the payments hub connection and the archive key protection. Both are highly exposed but need internal engineering, so they're scheduled once the HSM and certificate authority work makes them possible.

Notice that "start now" covers a lot. Starting doesn't mean finishing. For long-lead items it means opening conversations, adding requirements to contracts and getting dates on record.

Five pitfalls

1. Ranking by ease. Doing the easy items first feels productive and produces good-looking progress reports, while the hard, exposed items wait.
2. Ranking by algorithm. "All RSA first" ignores what the cryptography protects. The same algorithm can guard a public web page or a decade of payment records.
3. Borrowing someone else's deadline. US national-security dates, such as the NSA's CNSA 2.0 milestones, don't apply to a Canadian commercial bank. Anchor to guidance that's actually relevant: your regulator's expectations, NIST's draft transition plan and your sector's roadmap.
4. False precision. A score of 11.4 suggests more certainty than anyone has. Use simple bands, write down the reasoning, and label inferred inputs as inferred.
5. Scoring once. Re-score when inputs change: a new inventory flow, a supplier's new roadmap, revised guidance or a credible change in quantum estimates.

Taking it to committee

When Larkfield's programme lead first presented the ranking, the slide that landed wasn't the scoring formula. It was one sentence and one table: "Our wire records must stay confidential for seven years, migration of the connections that carry them takes up to four, and nobody can promise a quantum computer is more than eleven years away. These eight items are where we start, and here's why each is on the list." The committee could challenge every input, and that's exactly what made the plan credible.

Five questions for your next steering committee

1. Have we separated confidentiality exposure from signature exposure in our planning?
2. For our most sensitive data, what are X and Y, and are we comfortable with the bet that implies?
3. Which items are blocking others, and have they started?
4. Which items depend on suppliers or networks, and have we asked them for dates?
5. Can someone outside the security team follow and challenge our ranking?

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. Peer-reviewed paperCybersecurity in an era with quantum computers: will we be ready?Michele Mosca, IEEE Security & Privacy, 2018
2. Government guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023
3. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024
4. Government guidanceNSA releases future quantum-resistant algorithm requirements for national security systems (CNSA 2.0)US National Security Agency, 2022
5. Government guidanceRoadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)Canadian Centre for Cyber Security, 2025
6. 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