Marin Ivezic
A migration lead asks four suppliers for a cryptographic bill of materials. Three of them send back a list of Transport Layer Security (TLS) certificates with expiry dates. The fourth sends a software component list that does not contain the word cryptography anywhere in it. None of the four was being evasive. They had each read the request against the inventory they already knew how to produce, and there are at least four of those now.
This is the practical problem with the bills of materials. The acronyms arrived faster than the shared definitions, and a request that is not scoped precisely comes back as whatever the supplier had on the shelf. So this piece does the boring, useful thing: it separates the four inventories by the question each one answers, shows what a usable cryptographic bill of materials actually contains, and sets out how to scope the work so that the inventory feeds the migration instead of replacing it.
What a Bill of Materials Is Doing
The term comes from manufacturing. A bill of materials is the parts list for a product: every component, every quantity, every supplier, structured so that a change in one part can be traced to every product that contains it. Security borrowed the idea because the tracing property is the valuable one. When a component turns out to be broken, you want to know which of your systems contain it, without a three-week survey.
Four of these lists now circulate in post-quantum work, and each answers a different question.
| Inventory | The question it answers |
|---|---|
| Software bill of materials | What components are inside this software? |
| Cryptographic bill of materials | What cryptography runs, where, and under whose control? |
| Data inventory | What has to stay confidential, and for how long? |
| Hardware bill of materials | What devices carry cryptography we cannot easily change? |
They overlap, and the overlaps are useful rather than wasteful. But they are not substitutes for one another, and asking for the wrong one is how a migration program spends a quarter collecting data it cannot act on.
SBOM: What Is Inside the Software
A software bill of materials, or SBOM, is a nested list of the components, libraries and modules that make up an application, with their versions and their origins. It is normally generated automatically at build time and expressed in one of two machine-readable formats, SPDX or CycloneDX. Most organizations already produce them somewhere, because United States Executive Order 14028 pushed SBOMs into federal software procurement in 2021 and the practice spread outward from there.
For post-quantum cryptography, or PQC, the SBOM is the map you start from rather than the answer you need. Cryptography in modern software is almost never written locally. It arrives inside OpenSSL, BouncyCastle, a language runtime, a JSON Web Token library, a database driver. When you know which builds contain which library at which version, you can do two things quickly. You can find every deployment that will be affected when a library ships PQC support, and you can find the deployments running a cryptographic library so old that it will never ship PQC support at all.
That second case is the one we see teams underestimate. A component pinned at a version from 2017 is not going to receive ML-KEM support. Somebody has to plan an upgrade, and that work sits with an application team who currently has no reason to know the deadline exists.
An SBOM will not tell you which algorithms a system actually uses at runtime. A library can support twelve algorithms and a given service can be configured to use one of them. That gap between what is present and what is invoked is the reason the next inventory exists.
CBOM: What Cryptography Runs, and Where
A cryptographic bill of materials, or CBOM, is a structured inventory of the cryptographic assets in a system: the algorithms in use, their parameters, the protocols that carry them, the certificates and keys involved, and the place in the codebase or configuration where each one is invoked. CycloneDX formalized elements for cryptographic assets in version 1.6, so the concept has a schema rather than a spreadsheet convention.
The CBOM is the inventory that carries a migration, because it is the only one that answers the question the migration is built on. Quantum attacks are algorithm-specific. Shor’s algorithm breaks RSA, elliptic curve cryptography, finite-field Diffie-Hellman and DSA. Grover’s algorithm weakens symmetric ciphers and hashes by a smaller factor that is generally handled by choosing larger key sizes. Nothing about that risk profile is visible in a component list. It becomes visible when you record what runs.
A row in a usable CBOM carries at least these fields:
- The algorithm and its parameters, written precisely: RSA-2048 rather than RSA, P-256 rather than ECC.
- The purpose: key establishment, digital signature, data-at-rest encryption, integrity.
- The location: the service, the configuration file, the certificate, the hardware module.
- The dependency chain: which library provides it, at which version.
- The owner: the team that can change it.
- The constraint: a certificate expiry, a protocol version pinned by a partner, a vendor product that offers no configuration at all.
That last pair of fields is where a CBOM stops being documentation and starts being a plan. An algorithm with no named owner will not get migrated. An algorithm with an external constraint needs a conversation with a supplier, and that conversation has a lead time measured in quarters.
Here’s what a fragment looks like for one payments gateway:
| Asset | Purpose | Location | Owner | Constraint |
|---|---|---|---|---|
| ECDHE P-256 | Key establishment | Edge load balancer, TLS 1.3 profile | Platform networking | Vendor appliance, no hybrid key exchange in current firmware |
| RSA-2048 | Signature on the server certificate | Same appliance | PKI team | Certificate valid to 2028 |
| RSA-4096 | Code signing for gateway releases | Build pipeline, hardware module | Release engineering | Hardware module firmware supports RSA and ECDSA only |
| AES-256-GCM | Card data at rest | Gateway datastore | Payments engineering | None |
| HMAC-SHA-256 | Partner message integrity | Partner API | Partner integrations | Contractually specified with three partners |
Five rows, and the migration sequence has already written itself. The AES row needs nothing. The two RSA rows and the elliptic curve row need different work by different teams on different timelines, and two of them depend on a vendor firmware release nobody has yet asked about. TLS is the layer where most of this becomes negotiable first, because hybrid key establishment can be enabled at the edge without touching application code.
A large share of what is currently sold as CBOM tooling is certificate discovery with a new label on it. Certificate discovery is genuinely useful, and it is roughly one column of the table above. When you evaluate a tool, ask it to show you an algorithm invoked from application code with no certificate attached, and see what comes back.
Two other things the CBOM buys you, both of them before any quantum computer exists. It surfaces cryptography that is already weak, such as SHA-1 signatures or 1024-bit keys that nobody remembered were still in a legacy path. And it turns a cryptographic library advisory into a same-day impact assessment rather than a same-month one.
The Data Inventory: What Has to Stay Secret, and Until When
Not every system needs to migrate at the same speed, and the variable that sets the speed is data lifetime. Encrypted traffic captured today can be stored and decrypted later, once the capability exists. That pattern has a name, harvest now decrypt later, and it means the exposure clock on long-lived confidential data started some time ago rather than on the day a quantum computer is announced.
A data inventory, sometimes called a data bill of materials, records the major data stores, what they hold, how sensitive it is, how long it must remain confidential, and what cryptography currently protects it in transit and at rest. Most organizations have the first three columns already, inside a data classification or records retention program. The fourth column is usually the new work, and it is where the data inventory meets the CBOM.
The arithmetic that follows is straightforward. Michele Mosca’s formulation puts it as a comparison: add the number of years your data must stay confidential to the number of years your migration will take, and compare that sum to the time until a cryptographically relevant quantum computer exists. You cannot know the third number precisely. You can know the first two, and knowing them tells you which systems have no slack.
Practically, that means an archive of clinical records with a thirty-year retention obligation is a different migration priority from a session cache that expires in fifteen minutes, even if both currently use the same key exchange. United States guidance under National Security Memorandum 10 makes the same distinction explicitly, prioritizing systems holding data that must remain sensitive beyond 2035.
We recommend running this as a short workshop with data owners rather than as a survey. The question to put to each owner is narrow: if the contents of this store were readable by an adversary in twelve years, what happens? The answers sort quickly into three groups, and only one of them needs urgent attention.
HBOM: What You Cannot Patch
A hardware bill of materials, or HBOM, inventories physical devices and their components, including firmware versions and cryptographic capability. It matters for the same reason a mortgage matters more than a rental: some cryptography is embedded in a device you own for a decade and cannot reconfigure.
The devices worth listing first are the ones that sit under something else. A hardware security module, an HSM, is a tamper-resistant appliance that generates and stores private keys, and it typically anchors a certificate authority. If it supports RSA and ECDSA only, then everything above it inherits that limit, and a firmware upgrade or a procurement cycle becomes a dependency for the whole public key infrastructure. A Trusted Platform Module, or TPM, is the equivalent chip inside a laptop or server, and the deployed specification covers RSA and elliptic curve algorithms. Programmable logic controllers on a plant floor may authenticate with ECC and may have a fifteen-year service life with no update path. Smart cards and hardware tokens issued to staff are the same problem in a different form factor.
Most organizations do not need to build an HBOM from nothing. They need to extend the configuration management database, the CMDB, that already lists their assets. Add two fields to the records for security-relevant device classes: cryptographic algorithms supported, and whether the vendor has published a PQC roadmap. The second field is a procurement question, and asking it early has a useful side effect. Suppliers respond to demand signals, and a written question from a named customer is a demand signal.
For devices that will never support PQC, the options are replacement on the normal refresh cycle, or a compensating control such as tunnelling the device’s traffic through a gateway that does support quantum-safe key establishment. Both are decisions you can make calmly with two years of notice and badly with two months.
One System, Four Inventories
Take the payments gateway above and walk it through all four.
The SBOM shows the gateway service bundles a TLS library at a version two releases behind current, and that the same library version appears in six other services. That is one upgrade with seven beneficiaries, and it belongs to the platform team.
The CBOM shows the gateway’s own edge termination uses P-256 key establishment and an RSA-2048 server certificate, and that code signing runs through a hardware module. Three owners, three timelines, one vendor dependency.
The data inventory shows the gateway writes card data to a store with a seven-year retention obligation, and that partner message logs are kept for the same period. Seven years of confidentiality requirement, on transport currently protected by classical key establishment. This moves the gateway up the priority list.
The HBOM shows the load balancer appliance model and firmware version, and the hardware module model. Both go on the vendor question list this quarter, because both may need a procurement decision rather than a configuration change.
Four inventories, one system, and a work plan with named owners and a sequence. No single inventory would have produced that.
Scoping Without Stalling
The common failure in this work is not incomplete inventory. It is complete inventory that arrives after the window in which it would have been useful, produced by a team that felt unable to begin migrating until the picture was finished. Enterprise cryptography does not hold still long enough to be fully inventoried, so treating completeness as a precondition guarantees that nothing else starts.
Now, this is the decision that sets your scope: you are not inventorying the estate, you are inventorying the systems whose migration you intend to fund in the next eighteen months. Everything else can be sampled.
Four rules we teach for keeping the work moving.
Scope by consequence, not by coverage. Pick the systems that protect long-lived data or that other systems depend on, and build complete inventories for those. Ten thorough CBOMs beat two hundred partial ones, because the ten produce decisions.
Harvest what already exists. Certificate management systems hold much of the certificate layer already. Application security scanning holds much of the component layer. Network scanning will enumerate TLS endpoints and their negotiated cipher suites in an afternoon. Start from those and fill gaps, rather than starting from a blank template.
Attach an action to every finding, immediately. A CBOM row without an owner and a next step is a row that will be rediscovered next year. If the next step is “ask the vendor”, that is a legitimate next step, and it needs a date.
Make the inventory a by-product. Requiring an SBOM and a CBOM as a condition of production deployment grows the inventory as the estate changes, which is the only way it stays current. A one-off audit is stale within a quarter.
Standards Worth Tracking
Citing an external requirement that applies to you is often what moves internal budget.
On formats, SPDX and CycloneDX are the two SBOM standards in wide use, both now published through formal standards bodies, and CycloneDX is where the cryptographic and hardware models live. Pairing an SBOM with a VEX document, a vulnerability exploitability exchange record stating whether a known vulnerability in a component is actually reachable in your product, is becoming normal practice, and the same logic will apply when an algorithm rather than an implementation is the thing that breaks.
On requirements, the United States set the pace. National Security Memorandum 10 in 2022 established the 2035 horizon and the priority on long-lived data. OMB Memorandum M-23-02 turned that into a reporting obligation, requiring federal agencies to produce and maintain prioritized cryptographic inventories. The Quantum Computing Cybersecurity Preparedness Act put the inventory duty into statute. In Europe, the Cyber Resilience Act attaches software component obligations to products with digital elements, and the Commission’s post-quantum recommendation has member states working to national migration roadmaps.
On method, the NIST National Cybersecurity Center of Excellence project on migration to post-quantum cryptography includes a volume specifically on cryptographic discovery, and it is the most detailed public treatment of how to find cryptography in an estate rather than why you should. Sector groups have added their own, and telecommunications operators working through the GSMA post-quantum taskforce have published guidance that assumes inventory data will be exchanged between operators and their suppliers.
Read the requirements that apply to you, then read one that does not. Federal guidance tends to arrive first and get copied into commercial contracts eighteen months later.
Where to Build the Skill
Producing a CBOM that a migration program can act on is a specific competence. It combines reading configuration and code for cryptographic invocations, knowing which parameters make an algorithm quantum-vulnerable, and structuring findings so that ownership and constraints travel with them. Teams generally have parts of this distributed across three or four people and no single person who can run the exercise end to end.
That is the gap our post-quantum training is built to close, alongside the migration planning work that the inventory feeds. Our programs are listed at quantumacademy.com/. For migration methodology and the sequencing that follows an inventory, the PQC Framework sets out the phased approach in full, and PostQuantum.com carries the deeper technical analysis behind most of the standards referenced here.