A Quantum Bill of Materials is an inventory of the cryptographic components an organisation uses, including algorithms, certificates, keys, libraries and protocols. It helps security teams identify where quantum exposure exists and which dependencies must be modernised first.
What a Quantum Bill of Materials captures
A Quantum Bill of Materials is not just a list of assets. It is a structured inventory of the cryptographic dependencies that matter for post-quantum migration, so teams can see where quantum exposure exists across algorithms, certificates, keys, libraries and protocols.
The practical value is prioritisation. Organisations rarely modernise every cryptographic dependency at once, so the inventory helps separate low-risk components from the parts of the stack that carry long-lived exposure, external trust dependencies or broad reuse across systems.
Used well, the document becomes a decision aid for crypto-agility. It tells security, platform and architecture teams which components may need replacement, which can be wrapped or isolated temporarily, and where downstream systems inherit the same quantum risk through shared libraries or shared trust anchors.
Why quantum exposure is different from ordinary crypto inventory work
Quantum risk is different because the issue is not only whether a control is current today, but whether it remains safe against future cryptanalytic capability. That makes the inventory forward-looking, especially for assets that protect data with long confidentiality lifetimes or support high-value trust relationships.
The inventory also needs to distinguish between visible cryptography and embedded cryptography. A system may appear modern at the application layer while still depending on older algorithms, certificate chains, or protocol choices underneath, so the real exposure is often hidden in libraries, middleware, SDKs, appliances and integrations.
This is why the bill of materials has to describe dependencies at a level of detail that supports migration planning. A vague list of “uses encryption” is not enough when the objective is to understand where quantum-sensitive mechanisms are actually deployed and reused.
How organisations use it to prioritise migration
The inventory is most useful when it supports sequencing. Teams can rank cryptographic components by business criticality, data sensitivity, external exposure, replacement complexity and the likelihood that the component will still be in service when quantum-safe changes become necessary.
That prioritisation often reveals a mismatch between technical age and business risk. A relatively small number of certificates, libraries or protocols may control large parts of the trust fabric, which means those items should move first even if they are not the most visible systems in the environment.
For many programmes, the inventory is also the bridge between architecture and operations. It turns a broad “prepare for post-quantum” directive into a concrete map of where migration work belongs, which teams own the dependency, and which applications or services inherit the same cryptographic constraint.
What belongs in the inventory and what it is for
A useful Quantum Bill of Materials records the cryptographic building blocks that affect exposure, not just the presence of encryption. That includes the algorithm choice, the certificate or key format, the protocol in use, the library implementing it, and the systems that depend on it.
The best inventories are maintained as living documents, because quantum readiness changes when libraries are upgraded, certificate paths are reissued, vendors alter defaults, or protocols are retired. Static spreadsheets age quickly in environments where cryptography is embedded in many layers of the stack.
For security teams, the purpose is not documentation for its own sake. It is to give migration planners, architects and procurement teams enough visibility to make defensible choices about modernisation order, compatibility risk and where compensating controls are needed while work is underway.
How it relates to cryptographic modernisation and governance
A Quantum Bill of Materials sits alongside broader cryptographic inventory and crypto-agility work, but its focus is narrower: where quantum-sensitive cryptography exists and how urgently it should be addressed. That makes it especially useful for long-lived systems, regulated environments and platforms with many inherited dependencies.
It also creates governance value. Once cryptographic dependencies are visible, organisations can assign ownership, define migration deadlines, and track which products or services still rely on legacy choices. Without that visibility, post-quantum planning tends to stall at policy level and never reaches implementation.
For readers who want the broader inventory model, NHIMG’s Post-Quantum Readiness for Identity and PKI explains how certificates, signing, authentication and crypto-agility fit into migration planning. For the adjacent software-supply-chain view, the SBOM Guide is a useful companion because many quantum-sensitive dependencies are discovered through the same inventory discipline.
Risk and Threat Considerations
A quantum bill of materials matters because cryptographic exposure is often invisible until migration work starts. If an organisation does not know where older algorithms, certificate chains or protocol dependencies exist, it can leave long-lived data, trust paths or business-critical services exposed far longer than intended.
Failure mechanism: Hidden or undocumented cryptographic dependencies prevent timely modernisation, so the weakest component in a shared trust chain can remain in production after the organisation believes it has moved to safer cryptography.
Impact: The result is residual exposure across confidentiality, integrity and trust, especially where the same component protects sensitive data, authenticates systems, or anchors multiple downstream services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Part 1 — Key Management | Defines key lifecycle and cryptographic transition planning for quantum-sensitive dependencies. |
| Recommendation — Inventory cryptographic assets and plan key rotation, replacement and retirement around cryptoperiod and algorithm changes. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Quantum BOM is an inventory discipline for cryptographic dependencies across systems and services. |
| PR.DS-01 — Data-at-rest is protected | Quantum exposure affects the cryptography protecting data confidentiality over time. | |
| Recommendation — Extend asset inventory to cryptographic components, libraries and protocol dependencies. Review where long-lived data relies on cryptography that may need post-quantum replacement. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle management of credentials, keys and authenticators that appear in quantum BOMs. |
| Recommendation — Track and rotate cryptographic authenticators, keys and certificates as part of quantum migration. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Addresses organisational control over cryptographic use and transition decisions. |
| Recommendation — Maintain an approved cryptography inventory and manage transitions away from legacy algorithms. | ||
Practitioner Guidance
Why practitioners should care: The value of this inventory is not completeness alone, but decision quality. A Quantum Bill of Materials should be maintained as an operational asset that helps teams choose what to migrate first, what to isolate temporarily, and where the highest cryptographic concentration risk sits.
Governance implication: Treat ownership of cryptographic dependencies as part of architecture and platform governance, not as a one-time security exercise. If no team can name the component owner or the trust relationship it supports, the inventory is not yet actionable.
Related resources from NHI Mgmt Group
- How should security teams build a crypto bill of materials for post-quantum migration?
- Why do organisations need a crypto bill of materials before planning post-quantum migration?
- What do organisations get wrong about cryptographic bill of materials data?
- Why do software bill of materials controls not fully solve application risk?