← Guide overview

Vendors and third parties

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. Why suppliers are central, not peripheral
2. Step 1: Tier your suppliers
3. Step 2: Ask the right questions
4. Step 3: Judge the answers
5. Step 4: Put it in the contracts
6. Payment networks are different
7. Look one level further
8. Five questions for your next steering committee
9. Sources and further reading

When Larkfield finished its pilot inventory, one number stood out: more than half the vulnerable items were partly or wholly controlled by someone else. The core banking platform, the card processor, the HSM manufacturer, cloud services, network appliances, file-transfer services and the payment networks all run cryptography Larkfield depends on but can't change. For most banks, the quantum programme is as much a supplier programme as an engineering one. This chapter is about managing that.

Why suppliers are central, not peripheral

A bank can't be quantum-safe faster than the products and networks it relies on. Three things make suppliers especially important here.

• You can't see inside. The cryptography in a supplier's product is often invisible to your scanning tools. You depend on what they tell you.
• Their timetable becomes yours. If your HSM vendor's post-quantum firmware arrives in 2028, nothing that depends on those HSMs moves before 2028.
• Their weak link is your weak link. A quantum-safe connection to a supplier whose own systems remain vulnerable protects less than it appears to.

The good news is that this fits a discipline banks already have. Canadian banks manage supplier risk under OSFI's Guideline B-10 on third-party risk management, and quantum readiness can be folded into existing due diligence, contracts and monitoring rather than invented from scratch.

Step 1: Tier your suppliers

Larkfield's inventory named more than 60 suppliers whose products clearly use cryptography. Asking all of them everything at once would have produced a pile of unread questionnaires. Instead, the team sorted them into three tiers using the scores from Chapter 4.

Tier 1: CriticalSuppliers behind high-scoring items or blocking others: HSMs, core platform, card processing, payment network connectivity. About 15 at Larkfield. Detailed questions, named contacts, quarterly follow-up.

Tier 2: ImportantSuppliers handling sensitive data with moderate blast radius, such as file-transfer and document services. Standard questionnaire, annual follow-up.

Tier 3: WatchLower-exposure products. Track public roadmaps and ask at renewal.

Step 2: Ask the right questions

Vague questions get vague answers. "Are you quantum-ready?" invites a marketing reply. Larkfield's Tier 1 questionnaire asked for specifics, with dates and evidence.

1. Which public-key algorithms does your product use today, and for which functions (key agreement, signatures, certificates, key storage)?
2. Which of the NIST post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) do you support now, in which software or firmware version (and, for HSMs, which validated module version), and which are on your roadmap, with dates?
3. Will support come through a software or firmware update, or will it require new hardware or a new version? Has it been tested in an architecture like ours?
4. Do you support hybrid operation, running current and post-quantum algorithms together?
5. Can algorithms be changed by configuration, or does each change need a new release from you?
6. How do the larger post-quantum keys and signatures affect performance, storage or message sizes in your product?
7. How are you managing post-quantum readiness in your own suppliers and in the libraries your product uses?
8. Can you provide a cryptographic inventory, or a CBOM, for the product?
9. Who is your named contact for post-quantum questions, and how will you notify us of roadmap changes?
10. Are your stated dates committed, planned or aspirational?

The last question matters more than it looks. Supplier roadmaps have a way of slipping, and a date described as "planned" is a different planning input from one that's contractually committed. Record capability in four distinct states, because each is a different planning input: announced (on a roadmap), released (available in a shipping version), tested in your architecture, and approved for production.

Step 3: Judge the answers

Larkfield rated each Tier 1 response with a simple scale that the third-party risk team could own.

Rating	What it looks like	What Larkfield does
Ready	Support released in a shipping version, or a committed date with evidence; algorithms configurable; named contact	Plan migration around the supplier's dates
On track	Credible roadmap with planned dates, some detail missing	Follow up quarterly; ask for commitments in the next contract change
Unclear	General statements, no dates, no named contact	Escalate to the relationship owner; set a deadline for a real answer
At risk	No plan, or support only through a hardware replacement nobody has budgeted for	Record as a risk; begin evaluating alternatives

Of Larkfield's 15 critical suppliers, the first round came back as four Ready, six On track, four Unclear and one At risk: an older network appliance whose vendor had no post-quantum plan. That single answer started a replacement discussion two years earlier than the normal refresh cycle would have.

Step 4: Put it in the contracts

Questionnaires capture intentions; contracts make them enforceable. Larkfield added standard wording to new contracts and renewals for suppliers whose products use cryptography. The clauses covered five points:

• Roadmap and notification. The supplier maintains a post-quantum roadmap and notifies the bank of material changes.
• Standards support. The product will support NIST-standardised post-quantum algorithms by an agreed date, or by a date set relative to the bank's own plan.
• Agility. Algorithms can be changed by configuration where technically feasible, without a new major version.
• Transparency. The supplier provides cryptographic inventory information on request.
• Exit support. If the supplier can't meet the requirement, it supports transition to an alternative.

Not every supplier will accept every clause, and smaller suppliers may push back. The goal is to make quantum readiness a normal procurement expectation, not an exotic request.

Payment networks are different

Payment networks and market infrastructures, such as SWIFT, national payment systems and card networks, aren't ordinary suppliers. You can't renegotiate their contracts or replace them. Their cryptography, especially their certificate infrastructure, changes as a community, on a timetable they set in consultation with members.

For these, the bank's job is different: follow the network's published guidance closely, take part in consultations and working groups, make sure your own systems can move as soon as the network does, and record the network's plan as a dependency in the inventory, with the date you last checked it. Central banks have already tested post-quantum cryptography on real payment-system communications. The BIS Innovation Hub's Project Leap is the best-known example, and it shows the direction of travel.

Look one level further

Your suppliers have suppliers too. A card processor relies on its own HSMs, software libraries and cloud providers. You can't manage those relationships directly, but you can ask your critical suppliers how they manage them (question 7 above) and treat a weak answer as a risk in its own right.

Five questions for your next steering committee

1. Which of our suppliers control cryptography on our highest-priority items?
2. Have our Tier 1 suppliers given us post-quantum dates, and are they committed or aspirational?
3. Is quantum readiness part of our standard third-party due diligence and contract templates?
4. Which supplier answers are Unclear or At risk, and who owns the follow-up?
5. How do we track payment-network plans, and who represents us in those discussions?

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 guidanceGuideline B-10: Third-Party Risk ManagementOffice of the Superintendent of Financial Institutions (OSFI), 2023
2. ExperimentProject LeapBIS Innovation Hub
3. StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP
4. StandardNIST releases first 3 finalized post-quantum encryption standardsNIST, 2024
5. Government guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023