Start with discovery across applications, services and devices, then record each key, algorithm and certificate with ownership, purpose, expiration and dependency context. The useful output is not a static list but a governed inventory that shows what cryptographic assets exist, what they protect and what breaks if they change.
How to structure a cryptography inventory that is actually usable
A useful cryptography bill of materials starts with discovery across applications, services and devices, but the real value comes from normalising what you record. Treat each cryptographic asset as an operational object, not a line item: capture the key, algorithm or certificate, who owns it, what it protects, where it is used, when it expires and what dependency chain would fail if it changed.
The inventory should also distinguish between cryptography that is merely present and cryptography that is security-critical. A certificate used for internal test traffic is not the same as a root of trust protecting production authentication, signing or transport, so the bill of materials should reflect the business and technical role of each item, not just its existence. That distinction is what turns a list into a governance tool.
For enterprise systems, the most practical structure is a governed record that can be joined to application, service, platform and device ownership. That lets teams answer questions such as which systems depend on a given signing key, which certificates are close to expiry, and which cryptographic changes would affect customer access, internal trust chains or regulated workloads.
What belongs in the cryptography bill of materials
The minimum useful fields are the ones that support ownership, lifecycle management and impact analysis. At a practical level, teams should record algorithm family and parameters, key or certificate identifier, usage context, issuer or source, owner, storage location, expiration or rotation date, and the systems or dependencies that consume it. If the object is a key, include whether it is used for encryption, signing, authentication or transport, because the response to compromise or change is different for each case.
Dependency context matters as much as the cryptographic object itself. A certificate may be harmless in isolation, but if it anchors mutual TLS across multiple services or validates software updates, its failure can cascade. That is why a cryptography bill of materials should show not only what exists, but also what would break if the item were revoked, replaced or allowed to expire.
For enterprise scope, discovery should include cloud services, secrets stores, hardware security modules, endpoint keystores, CI/CD pipelines, certificates embedded in appliances and any application that ships with a bundled trust store. If you only inventory one layer, you miss the places where the same cryptographic asset is reused, copied or exposed in ways that create hidden operational risk.
A good inventory is also versioned. Cryptographic posture changes over time as certificates are renewed, algorithms age out, keys rotate and applications migrate. Teams should keep change history so they can trace when a sensitive asset was introduced, why it was changed and whether a later incident lines up with that timeline.
How to govern it so the inventory stays accurate
The central governance question is not whether the inventory exists, but who can trust it enough to act on it. That means assigning ownership for updates, defining how new cryptographic assets are added, and making expiry, rotation and retirement part of normal service management rather than one-off remediation work. Without that operating model, the list decays into stale metadata very quickly.
Automation helps, but only if teams are explicit about source of truth. Discovery tooling can find certificates, keys and algorithm usage, but humans still need to approve ambiguous ownership, classify business criticality and decide what counts as an approved dependency. The best practice is to automate collection and correlation, then route exceptions for review instead of letting the tool silently infer governance.
It is also worth linking the inventory to vulnerability and change management so the organisation can prioritise cryptographic remediation by impact. A weak or expiring certificate on a low-value test system is not the same as a failing key that protects customer sessions or code signing, and the inventory should make that difference visible to operations, security and platform teams.
Risk and Threat Considerations
Cryptographic inventories fail when they are treated as documentation rather than control evidence. The main risks are missed expirations, untracked reuse, hidden dependencies and incomplete ownership, all of which can turn a routine certificate renewal or key rotation into an outage or a security incident.
Failure mechanism: Teams cannot see where cryptographic assets are used, so they rotate, replace or retire them without understanding downstream consumers, or they miss high-risk assets entirely until they expire or are exposed.
Impact: Systems can lose trust, authentication can fail, signing chains can break, and exposed keys or certificates can create broad compromise if they were reused across environments or 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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | NIST SP 800-57 Part 1 — Recommendation for Key Management Part 1 | Directly governs key lifecycle, cryptoperiods and algorithm selection for a cryptography inventory. |
| Recommendation — Map keys, cryptoperiods and algorithm choices so rotation and retirement are tracked by lifecycle. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cryptography inventories support control over how cryptographic mechanisms are selected and managed. |
| A.5.9 — Inventory of information and other associated assets | A cryptography bill of materials is an asset inventory for cryptographic material and dependencies. | |
| A.8.9 — Configuration management | Cryptographic assets change through configuration and need controlled update tracking. | |
| Recommendation — Record cryptographic assets and approved use cases under the cryptography control. Keep an asset inventory that includes cryptographic objects and their dependency context. Control cryptographic changes so rotations, renewals and removals are authorised and traceable. | ||
| NIST CSF 2.0 | ID.AM-02 — Software platforms and applications are inventoried | The bill of materials depends on inventorying applications and services that use cryptography. |
| PR.DS-01 — Data-at-rest is protected | Cryptographic materials are central to protecting stored data and related dependencies. | |
| Recommendation — Inventory systems that consume cryptographic assets and keep the list current. Map which cryptographic assets protect data at rest and verify they remain active and managed. | ||
Practitioner Guidance
What to prioritise: Start with assets that can stop production, such as certificate chains, signing keys, authentication keys and any cryptographic material reused across multiple services or environments. Those items create the largest blast radius, so they deserve the highest-quality metadata and the fastest remediation path.
What to verify: Before trusting the inventory, verify that every record has an accountable owner, a real dependency map and a tested rotation or replacement path. If you cannot name the system that will fail when the asset changes, the inventory is not yet operationally useful.
Common mistake: Teams often catalogue cryptographic objects without tying them to service function or change impact. That produces a report that looks complete but does not help when a certificate is nearing expiry or a key must be revoked under pressure.
Practitioner takeaway: The right cryptography bill of materials is a living control surface, not a spreadsheet, and its quality should be judged by whether it helps teams predict impact before a cryptographic change causes outage or exposure.
Related resources from NHI Mgmt Group
- How should security teams build a crypto bill of materials for post-quantum migration?
- How should data governance teams build a single source of truth for enterprise metadata across fragmented systems?
- How should security teams build an inventory for enterprise cryptography before automation efforts begin?
- How should security teams prioritise NHI remediation in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org