Every post-quantum roadmap in banking assumes an inventory that does not exist. The plans are written, the steering committees meet, the scorecards are amber. Underneath all of it sits an assumption that someone, somewhere, can produce a list of every place the bank performs a cryptographic operation — which algorithm, which key length, which library, which certificate, expiring when. Almost no institution can. The NCSC's first milestone is not a migration milestone: it is a discovery milestone, due 2028, and it is the one nobody costed.
Executive Summary
- The sequence is discovery, then agility, then migration. Guidance from the NCSC sets a defined discovery milestone in 2028, highest-priority migration in 2031 and completion by 2035. An institution that starts migrating before it has enumerated will migrate the systems it happens to know about.
- The register you have does not answer the question you now face. DORA Article 8 requires financial entities to identify, classify and document ICT assets and map their interdependencies. It does not require a single cryptographic property, so an Article 8-compliant register can be complete and still useless for crypto-agility planning.
- The standard already exists. Cryptographic assets — algorithms with key size, mode and curve; keys; certificates; protocols — are representable in CycloneDX, which is published as ECMA-424. This is a schema question, not a procurement question.
- The hardest quartile is not yours to scan. Hardware security modules, payment appliances, vendor-embedded libraries and SaaS providers cannot be enumerated by pointing a scanner at them. That part of the inventory is built from contractual attestation, and the clause has to exist before the roadmap can.
The Deadline Nobody Costed #
Read the published migration timelines carefully and the sequencing is unambiguous. The National Cyber Security Centre's roadmap places discovery — a full picture of which systems and services depend on cryptography — at 2028, the highest-priority migration work at 2031, and completion across all systems, services and products at 2035. NIST's transition report, IR 8547, runs on a compatible track: quantum-vulnerable public-key algorithms including RSA and ECC are deprecated after 2030 and disallowed after 2035.
Most banking programmes have internalised 2035 as the date. That is the wrong end of the schedule to plan from.
Two dates matter far more. The first is 2028, because discovery is the input to everything downstream — you cannot scope, cost or sequence a migration against an unknown denominator. The second is 2030, because "deprecated" is not a soft word in a regulated institution: it is the point at which continuing to rely on an algorithm becomes a decision someone has to sign.
Between now and 2028 there are fewer than thirty months. That is one, perhaps two, budget cycles to build a capability most institutions have not started.
Your DORA Register Records Everything Except the Cryptography #
Here is the part that surprises people. Most large European banks already maintain a detailed, regularly reviewed inventory of ICT assets, because DORA obliges them to.
Article 8 of Regulation (EU) 2022/2554 requires financial entities to identify, classify and adequately document all ICT-supported business functions, the information and ICT assets supporting them, and their roles and dependencies in relation to ICT risk — and to map the configuration of those assets and the links between them, kept under review.
That is a serious inventory. It is also the wrong shape for this problem.
Table 1: The register you have, and the register the 2028 milestone needs #
| Question | ICT asset register (DORA Article 8) | Cryptographic inventory (CBOM) |
|---|---|---|
| What is this asset and who owns it? | Yes — this is the core of the register | Not its purpose |
| How critical is it, and what does it depend on? | Yes — classification and interdependency mapping | Inherited from the asset register |
| Which algorithms does it use, and where? | No | Yes — per component, with key size, mode and curve |
| Which library implements them, at which version? | Partially, via the SBOM if one exists | Yes, as an explicit relationship |
| Which certificates does it present, expiring when? | Rarely, and usually in a separate PKI tool | Yes |
| Where do the keys live, and how are they protected? | No | Yes — including whether an HSM is in the path |
| Is this asset quantum-vulnerable? | Cannot be derived | Directly answerable |
The last row is the whole argument. An institution can be fully compliant with Article 8, pass its examination, and still be unable to answer "how many of our systems will break in 2030" without commissioning a discovery project from scratch.
This is not a criticism of DORA. Article 8 was written to answer resilience and concentration questions, and it answers them well. It simply was not written to answer a cryptographic-agility question, and the two registers need to be joined rather than run as separate spreadsheets owned by separate teams.
What a CBOM Actually Contains #
A Cryptography Bill of Materials is a formal inventory of the cryptographic assets in a system — the algorithms, keys, certificates and protocols, and their relationships to the software components that use them.
The important structural point is that it is not a new file format. Cryptographic asset support was contributed into CycloneDX, the OWASP-backed bill-of-materials specification, which is published as an Ecma International standard, ECMA-424. A CBOM is therefore a CycloneDX document with cryptography fields populated. It validates with the same schema, moves through the same pipelines, and lands in the same artefact registry as the SBOMs an institution already produces for supply-chain purposes.
That matters more than it sounds. The difference between a standard that ships and a standard that stalls is usually whether it requires new plumbing. This one does not.
Table 2: CBOM asset classes and the migration question each answers #
| Asset class | What is recorded | The question it answers |
|---|---|---|
| Algorithm | Primitive, key size, mode, curve, padding, and the function it performs | Which of our operations are quantum-vulnerable, and at what parameter strength? |
| Key | Type, size, format, state, and where the material resides | Which keys are protected by an HSM and which sit in application memory? |
| Certificate | Subject, issuer, signature algorithm, validity window | What expires before the migration window, and what is signed with a deprecated algorithm? |
| Protocol | Protocol and version, with the cipher suites offered | What is actually negotiated on the wire, as opposed to what the configuration file claims? |
| Related component | The library, version and code location implementing the above | If this library is replaced, what else moves with it? |
The last row is the one that turns an inventory into a plan. A list of algorithms tells you the size of the problem. A list of algorithms joined to the components that implement them tells you the shape of the work — which is what a migration sequence is actually built from.
Discovery Is Four Problems, Not One #
Treating discovery as a single workstream is the most common way these programmes fail. It is four distinct problems with four different tools, four different owners, and very different confidence levels.
1. Source code — what the code asks for. Static analysis over your own repositories finds cryptographic calls, hard-coded parameters and the libraries invoked. Open tooling exists: the CBOMkit project and its SonarQube plugin detect cryptographic assets in source and emit CycloneDX. Highest confidence, narrowest coverage — it only sees code you wrote and still build.
2. Binaries and containers — what actually ships. Source analysis misses everything pulled in as a compiled dependency or baked into a base image. Container and filesystem scanning closes part of that gap. Expect the two views to disagree; the disagreement is itself a finding.
3. The network — what is genuinely negotiated. Configuration is an intention, not an observation. Passive observation of live TLS negotiation across the estate is the only way to learn that a service which documents TLS 1.3 still accepts something older with an internal counterparty that never upgraded. In a payments estate, that counterparty is often the one that matters.
4. The vendor and hardware estate — what you cannot scan at all. Hardware security modules, payment terminals, network appliances, mainframe subsystems, and every SaaS provider in the chain. No scanner reaches these. This quartile is enumerated by asking, under contract, and it is where wholesale banking's genuine exposure concentrates, because the systems that clear and settle are disproportionately vendor-supplied.
The fourth is the one to start now, because it has the longest lead time and it is not an engineering task. It is a procurement task: getting a cryptographic-disclosure and crypto-agility clause into the contract, and into the renewal template, so that by 2028 the answer arrives as a supplier obligation rather than a favour. Every quarter that clause is not in the template is a quarter of renewals that will have to be reopened later.
Making It a Control Rather Than a Project #
The failure mode I would bet on is not that banks skip the inventory. It is that they commission it as a one-off, deliver a defensible snapshot in 2028, and let it decay — because it was funded as a post-quantum project deliverable rather than built as a maintained control.
A cryptographic inventory decays faster than an asset register. Certificates rotate. Libraries are bumped by dependency automation. A base image changes and a whole service silently acquires a different TLS stack. A snapshot taken in 2028 will be materially wrong by 2029, which is precisely when the 2031 prioritisation work depends on it.
Three commitments prevent that.
Generate it in the pipeline, not in a survey. A CBOM should be emitted by the build, alongside the SBOM, and stored as a versioned artefact against the release. An inventory assembled by emailing application owners a questionnaire is out of date on arrival and cannot be diffed.
Diff it, and alert on the diff. The valuable signal is not the inventory; it is the change to the inventory. A service that acquired a new cryptographic dependency, a certificate that shortened, an algorithm that appeared where it was not before — those are the events worth a control. This is the same reasoning that makes SBOM diffing more useful than SBOM archiving.
Join it to the register you already keep. The CBOM answers "which cryptography"; the Article 8 register answers "how critical, whose, and what depends on it". Neither is a prioritisation on its own. Joined, they produce the only ranking that matters: quantum-vulnerable operations sorted by the criticality of the business function sitting on top of them. That join is the actual deliverable of a discovery programme, and it is worth naming as such in the plan.
The Operating Playbook #
- Reframe the 2028 milestone as a capability, not a report. The deliverable is a maintained, machine-readable inventory that regenerates itself, not a document produced once for a supervisor.
- Emit CBOMs from the build now, on new services first. Do not attempt the estate in one pass. Wire it into the pipeline for anything being built or materially changed this year, so coverage accretes rather than requiring a campaign.
- Put the contractual clause in the renewal template this quarter. Cryptographic disclosure and a crypto-agility commitment. This has the longest lead time of anything on the list and it does not depend on any tooling decision.
- Run network observation against the payment and settlement paths first. That is where the configuration-versus-reality gap does the most damage and where legacy counterparties concentrate.
- Join the CBOM to the Article 8 register and rank on the join. Publish the ranked list. It is the artefact that converts an engineering inventory into a board conversation about sequencing and money.
- Diff every regeneration and alert on new quantum-vulnerable dependencies. An inventory without a diff is an archive.
The institutions that will make 2031 comfortably are not the ones with the most advanced view of ML-KEM. They are the ones that can answer, on any given morning and without commissioning a project, the question of where their cryptography actually is.
Frequently Asked Questions #
Is a CBOM a different thing from an SBOM?
It is the same document type with different fields populated. Cryptographic asset support was upstreamed into CycloneDX, which is published as ECMA-424, so a CBOM validates against the same schema and moves through the same tooling as an SBOM. Institutions that already generate SBOMs are closer to this than they usually assume.
Does DORA require a cryptographic inventory?
Not in those terms. Article 8 of Regulation (EU) 2022/2554 requires identification, classification and documentation of ICT assets and the mapping of their configuration and interdependencies. Cryptographic properties are not among the attributes it obliges you to record, which is why an Article 8-compliant register cannot answer a quantum-vulnerability question without being extended.
Why does discovery need to finish so far ahead of migration?
Because it is the input to prioritisation. NCSC guidance sets discovery at 2028 and highest-priority migration at 2031 precisely so there is a defined interval in which to rank the estate and sequence the work. Compressing the two means migrating whatever is best understood rather than whatever matters most.
How do we inventory cryptography inside vendor hardware and SaaS?
You do not scan it; you require disclosure. Hardware security modules, payment appliances and service providers must be covered by a contractual cryptographic-disclosure and crypto-agility obligation. Because this depends on renewal cycles rather than engineering effort, it has the longest lead time on the whole programme and should start first.
Should we wait for tooling to mature before starting?
No, and the tooling argument is usually a proxy for the budget argument. Open implementations already emit CycloneDX cryptographic inventories from source and from container images, and the specification is a ratified standard. The constraint on a 2028 milestone is coverage and contractual reach, not tool availability.
References #
- European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2022..
- National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. London: NCSC. Available at: National Cyber Security Centre, 2025..
- National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Gaithersburg: U.S. Department of Commerce. Available at: National Institute of Standards and Technology, 2024..
- National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg: U.S. Department of Commerce. Available at: National Institute of Standards and Technology, 2024..
- OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Available at: OWASP Foundation, 2026..
- OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Available at: OWASP CycloneDX, 2026..
- IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Available at: IBM Research, 2026..
Last reviewed .