← Guide overview

Building a cryptographic inventory

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. One rule before you start
2. Step 1: Set the scope and the rules
3. Step 2: Decide what each record captures
4. Step 3: Find the assets
5. Step 4: Record what you can't see
6. Worked example: Larkfield's cross-border wires
7. Six mistakes that sink inventories
8. What good looks like after 90 days
9. Sources and further reading

Every serious post-quantum roadmap, from NIST to the Canadian Centre for Cyber Security to the EU, starts in the same place: find out what cryptography you have. The EU's roadmap expects inventories to be in place by the end of 2026, which means for many institutions this first deliverable is effectively due now. This chapter explains how to build an inventory that a bank can actually plan from, and how to avoid the mistakes that turn it into an expensive spreadsheet nobody trusts.

One rule before you start

The inventory is an input, not the deliverable. The deliverable is a prioritised, defensible migration plan. An inventory that isn't kept up to date is a liability, not an asset.

The industry name for this inventory is a cryptographic bill of materials, or CBOM: a structured list of every cryptographic asset, what it does, what it protects and what depends on it. There's an open standard for recording it (CycloneDX), which helps when you want tools and suppliers to exchange the information. For a governance lead, the format matters less than the discipline: a single, owned, regularly refreshed source of truth.

Step 1: Set the scope and the rules

Most inventory projects that fail, fail here. Before anyone scans anything, agree five things.

1. Scope by business process, not by system list. Pick one end-to-end flow, such as cross-border wires from customer instruction to archived record, and cover every stage. A system list misses the connections between systems, which is exactly where much of the cryptography lives.
2. Include non-production. Test and development environments use real cryptography and are often the weakest part of the estate.
3. Name an owner and a refresh rhythm. One accountable person, and a rule that the inventory is updated with every release or at least quarterly.
4. Agree one source of truth. One place where records are maintained, from which reports are produced. Never let five teams keep five copies.
5. Agree a confidence label. Every record is marked documented (confirmed by its owner or a scan) or inferred (deduced, not yet confirmed), with a note on why. Record how each item was found too: a scan, a code review and a supplier's statement are different kinds of evidence. Inferred is perfectly acceptable as long as it's labelled honestly.

That last rule does more for credibility than any tool. A risk committee can work with "we're confident about 60% of this and here's the plan for the rest". It can't work with a number that later turns out to be guesswork.

Step 2: Decide what each record captures

An inventory that only lists algorithm names answers "what do we have?" but not "what should we fix first?". Each record needs enough business context to support prioritisation later. This is the record template Larkfield adopted. The fields marked core are the minimum for a business-led pilot; the others can be added as technical teams get involved.

Field	What it means	Larkfield example
Asset core	A name people recognise	Payments hub to messaging interface connection
Where it lives	System and which of the eight surfaces	Data in transit, payments platform
Job core	Key agreement, signature, key custody, encryption or integrity	Key agreement and machine identity
Algorithm	What it uses today	Elliptic-curve key exchange, RSA certificates
Quantum status core	Broken, weakened or fine	Broken
What it protects core	The data or process at stake	Outgoing payment instructions
How long it must stay secret core	From data classification and retention policy	Seven years or more
Depends on / depended on by	Upstream and downstream links	Payments hub, messaging interface, internal certificate authority
Owner core	A named team, not "IT"	Payments platform team
Third party? core	Who controls it, if not us	Partly: messaging interface vendor
Ease of change	Configurable, pinned in settings, or hard-coded	Pinned in configuration
Confidence core	Documented or inferred, with a note	Inferred: from a network scan, owner to confirm
Discovery method	How it was found: network scan, code scan, configuration review or supplier statement	Network scan
Last confirmed	Date and by whom	Not yet confirmed
Disposition	Planned response: migrate, upgrade, replace, isolate, accept temporarily with risk approval, or investigate	Investigate, then migrate (target and dependency owner to be set)

Step 3: Find the assets

Discovery has two halves, and you need both.

Tools find the visible half. Certificate management platforms export certificate details. Network scans show which algorithms connections actually negotiate, which isn't always what the configuration says. Code scanners find cryptographic libraries in software. Key-management systems and HSMs can report key types. These sources are fast and repeatable, and they're the right first pass.

People find the rest. Tools miss cryptography set in configuration files and middleware, inside vendor products, and in older systems nobody has scanned. They also can't tell you what data a connection carries, how long it must stay secret or who depends on it. Only the teams who run the systems know that.

The way you ask matters enormously.

Don't send teams a blank spreadsheet asking them to list their cryptography. Send them a pre-filled draft and ask them to confirm or correct it.

Nobody knows their cryptography from memory, so blank surveys come back empty or wrong. A draft built from scan results, even an imperfect one, is quick to review, and corrections are accurate. Each confirmation moves a record from inferred to documented, and recording who confirmed what and when gives you an audit trail.

Step 4: Record what you can't see

A large share of any bank's cryptography sits inside other organisations' products and services: the core banking platform, card processors, cloud providers, file-transfer services, payment networks. You can't inspect it, but you can and must record it. Note the dependency, the interface, what it protects, and the supplier's stated plan, with a date and a source.

This keeps third-party exposure visible as tracked rather than silently missing. It also gives vendor management a concrete list of questions, which Chapter 6 covers in detail.

Worked example: Larkfield's cross-border wires

Larkfield chose cross-border wires as its pilot flow, because the data is sensitive, retention is long and the flow touches external networks. After six weeks the inventory held 140 records. Here is an illustrative sample.

Asset	Job	Quantum status	Secrecy needed	Ease of change	Confidence
Online banking connection	Key agreement	Broken	7+ years	Configurable at the load balancer	Documented
Payments hub to messaging interface	Key agreement and identity	Broken	7+ years	Pinned in configuration	Inferred
SWIFT network certificate	Signature	Broken (forgery risk)	Not applicable: authenticity	Moves with the network	Documented
Message-signing keys in HSMs	Key custody	Broken	Not applicable: authenticity	Depends on HSM firmware	Inferred: vendor asked
Wire archive encryption	Encryption	Fine (AES-256)	7+ years	No change needed	Documented
Archive key protection	Key custody	Broken (RSA key wrap)	7+ years	Hard-coded in archive software	Documented
Corporate client file transfers	Key agreement	Broken	7+ years	Supplier-controlled	Inferred
Core platform software updates	Signature	Broken (forgery risk)	Not applicable	Supplier-controlled	Documented: roadmap requested

Two rows show why the business-context fields matter. The archive looked safe until the team asked how its encryption key was protected. And the payments hub connection, which an engineer might rate as a simple fix, turned out to have its algorithm pinned in configuration across several systems. That's an "ease of change" problem that would never have shown up in a list of algorithm names.

Six mistakes that sink inventories

1. The blank survey. Asking teams to list their cryptography from scratch produces little and erodes goodwill.
2. The one-off snapshot. A beautiful report that's out of date within a quarter. Build in the refresh from day one.
3. Production only. Leaving out test and development environments.
4. Algorithms without context. Recording what's used but not what it protects, how long, or how hard it is to change.
5. Over-scoping. Treating AES-256 and modern hashing as urgent problems. It wastes effort and costs credibility with engineers.
6. "It's in the HSM." Recording HSM-held RSA or elliptic-curve keys as safe. They aren't.

What good looks like after 90 days

For Larkfield, success at the end of the first quarter didn't mean a complete inventory of the whole bank. It meant:

• one end-to-end flow inventoried, with every stage accounted for;
• a named owner, an agreed template and one source of truth;
• every record labelled documented or inferred, with most of the important ones confirmed;
• supplier dependencies listed and the first questions sent;
• a refresh routine agreed with the teams involved;
• a short method note explaining how it was done, so the next flow goes faster.

That's enough to start making real decisions. Chapter 4 shows how to turn records like these into a defensible order of work.

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 guidanceA Coordinated Implementation Roadmap for the Transition to Post-Quantum CryptographyEuropean Commission / NIS Cooperation Group, 2025
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 guidanceQuantum-Readiness: Migration to Post-Quantum CryptographyCISA, NSA and NIST, 2023
4. StandardCryptography Bill of Materials (CBOM)CycloneDX / OWASP
5. Government guidanceNIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography StandardsNIST, 2024