Cryptographic bill of materials exposes the gap in cryptographic management

At a glance

What this is: This is an analysis of the cryptographic bill of materials and its limits, with the key finding that CBOM is only a starting point for cryptographic visibility.

Why it matters: It matters because identity, secrets, certificates, and cryptographic keys are operational controls, not static artifacts, and IAM teams need continuous governance across their lifecycle.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.

👉 Read Keyfactor's analysis of the cryptographic bill of materials and inventory gap

Context

Cryptographic bill of materials, or CBOM, is a structured inventory of the cryptographic elements built into software. Keyfactor frames it as a way to expose algorithms, libraries, keys, and supported key sizes, but the important governance point is that build-time visibility does not tell you how cryptography is actually configured or used in production.

That gap matters for IAM and NHI programmes because keys, certificates, and secrets are operational identities with their own lifecycle, ownership, and rotation requirements. A software package can advertise cryptographic support and still be deployed with weak algorithms, stale keys, or inconsistent policy enforcement across environments.

For practitioners, CBOM is useful only if it feeds a broader cryptographic inventory that tracks runtime usage, provisioning, rotation, and dependencies. Without that, teams are left with a static bill of capabilities rather than a governable security posture. That starting position is typical in organisations that have focused on software composition but not identity and secret lifecycle control.

Key questions

Q: How should teams govern cryptographic assets across software and production environments?

A: Teams should govern cryptographic assets as a lifecycle problem, not a software inventory problem. Start with CBOM for discovery, then extend it into a living register that tracks ownership, enabled algorithms, key rotation, certificate expiry, revocation, and dependencies. That gives IAM, PKI, and security teams one shared view of cryptographic risk.

Q: Why does a static cryptographic inventory fail to reduce real risk?

A: A static inventory fails because real cryptographic risk comes from configuration drift and operational use, not just from what a package can support. A system may compile with strong algorithms and still run with weak settings, stale keys, or unmanaged certificates. Continuous validation is needed to keep inventory aligned with reality.

Q: What signals show that cryptographic governance is out of control?

A: The clearest signals are outdated rotation records, unknown key owners, certificate expiry close to production use, and inconsistent algorithm settings across environments. If the organisation cannot map cryptographic assets to a lifecycle owner and an enforced renewal path, control is already fragmented.

Q: How do cryptographic inventories support IAM and machine identity governance?

A: They turn cryptographic artifacts into governed identity assets. Keys, certificates, and secrets all need issuance, monitoring, rotation, and retirement, just like other non-human identities. When these assets are tracked in the same governance model, teams can reduce trust gaps and improve auditability.

Technical breakdown

Why a CBOM is only a static cryptographic snapshot

A CBOM lists the cryptographic primitives a software component contains, such as algorithms, libraries, and key sizes. That is useful for release review, but it is not an operational record. It does not show whether SHA-1 or SHA-256 is enabled, whether keys are protected by an HSM, or whether a deployed service has drifted from the approved configuration. In practice, the same build can be secure in one environment and non-compliant in another because runtime policy, not source inventory, determines real exposure.

Practical implication: treat CBOM as intake data, then validate runtime configuration before declaring a cryptographic control in place.

Cryptographic inventory as a lifecycle control for keys and certificates

A cryptographic inventory goes beyond software capabilities and tracks how cryptographic assets are used across the enterprise. That includes keys, certificates, secrets, protocols, keystores, dependencies, ownership, and rotation policy. This is fundamentally an identity lifecycle problem because cryptographic material is issued, trusted, renewed, and retired. If the inventory does not connect these assets to the systems and teams that govern them, the organisation cannot answer basic questions about privilege, exposure, or accountability.

Practical implication: map every key and certificate to an owner, rotation rule, and retirement path.

Why posture management depends on continuous cryptographic telemetry

The article’s central point is that cryptographic posture changes as environments change. A CBOM is tied to a software release, but cryptographic risk shifts with configuration drift, certificate expiry, secret sprawl, and dependency updates. That is why continuous inventory matters more than periodic documentation. In identity terms, the control surface is not the library alone. It is the combination of algorithm choice, provisioning process, usage context, and revocation readiness across the full lifecycle of machine credentials.

Practical implication: feed cryptographic asset data into ongoing monitoring so drift, expiry, and policy violations are visible before they become incidents.

NHI Mgmt Group analysis

CBOM is not governance, it is metadata. A cryptographic bill of materials describes what cryptographic capabilities a package contains, but it does not prove how those capabilities are configured or enforced in production. That distinction matters because security failures usually arise in the operational layer, where keys, certificates, and secrets are actually issued, stored, rotated, and retired. Practitioners should treat CBOM as a discovery input, not as evidence of control.

Cryptographic inventory is the real control plane for machine trust. Once cryptography is tied to certificates, keys, and secrets, the problem stops being software composition and becomes identity lifecycle management. That lifecycle spans provisioning, ownership, rotation, revocation, and dependency tracking, which are the same governance questions IAM teams already face for other non-human identities. Practitioners should align cryptographic inventory with existing identity processes rather than build a parallel catalogue that nobody owns.

Long-lived cryptographic material creates identity debt. The article implies a familiar failure mode: organisations can document supported algorithms while leaving stale keys, weak ciphers, and misaligned configurations untouched. That is not a visibility issue alone. It is unresolved identity and secret governance, and the practical conclusion is that cryptographic assets need the same continuous control discipline as service accounts and tokens.

Cryptographic posture must be measured against runtime reality, not release intent. A software release may support strong algorithms, but the deployed estate can still operate on weaker settings or unmanaged certificates. This is where cross-domain identity governance matters, because the same drift patterns that affect NHI sprawl also affect cryptographic trust. Practitioners should expect audit and risk conversations to move from static inventory to living assurance.

Named concept: cryptographic identity drift. The useful concept here is the gap between declared cryptographic capability and actual production use. That drift becomes visible when inventories are static, ownership is unclear, and rotation is not continuously enforced. The implication is that cryptography should be governed as a changing identity state, not a one-time software attribute.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to NHI Mgmt Group research on non-human identity exposure.
• For lifecycle context, the NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding need to be governed together.

What this signals

Cryptographic identity drift: the new operational risk is not simply that software supports multiple algorithms, but that production environments drift away from the cryptographic state documented at build time. When that happens, audit evidence and runtime reality diverge, and assurance becomes speculative. Teams should expect cryptographic governance to converge with PKI, secrets, and machine identity management rather than stay isolated in application security.

The practical signal for IAM and security leaders is that lifecycle control will matter more than static documentation. If ownership, renewal, and revocation are not attached to each cryptographic asset, the inventory will age faster than the estate it describes. That is why identity programmes should pair cryptographic review with existing governance routines, including NIST Cybersecurity Framework 2.0 and internal lifecycle controls.

This is also a reminder that machine identity governance is broader than service accounts. The same control failure pattern appears when keys, certificates, and secrets are left outside formal renewal and retirement paths. If your programme already struggles to see non-human identity sprawl, cryptographic posture will fail in the same place unless inventory, ownership, and policy enforcement are unified.

For practitioners

• Separate cryptographic capability from cryptographic control Use CBOM data to identify what software can do, then verify which algorithms, key sizes, and protocols are actually enabled in production. Tie that check to configuration baselines so release documentation does not get mistaken for runtime assurance.
• Build a cryptographic inventory that includes ownership and lifecycle states Track keys, certificates, secrets, keystores, and dependent systems in one register with named owners, issue dates, rotation rules, and retirement criteria. Connect the inventory to the same lifecycle governance used for other machine identities.
• Align cryptographic refresh with identity review and renewal cycles Review certificate expiry, secret rotation, and algorithm deprecation together so cryptographic change is treated as a governed lifecycle event, not a one-off technical task. Link the inventory to review cadences that can detect drift before it becomes exposure.
• Use posture reporting to surface drift, not just presence Report on weak algorithms, stale certificates, unmanaged keys, and unsupported libraries as exceptions in the same dashboard. That gives security, platform, and IAM teams a common view of where cryptographic trust has outgrown the approved control model.

Key takeaways

• CBOM improves software visibility, but it does not prove how cryptography is actually governed in production.
• The core control gap is lifecycle failure, because keys, certificates, and secrets need ownership, rotation, and revocation to stay trustworthy.
• Practitioners should extend CBOM into a living cryptographic inventory that tracks runtime configuration, drift, and accountability.

Key terms

• Cryptographic Bill Of Materials: A cryptographic bill of materials is a structured inventory of the cryptographic capabilities embedded in a software component. It lists algorithms, libraries, key sizes, and related elements, but it does not describe how those capabilities are configured or used in production.
• Cryptographic Inventory: A cryptographic inventory is a living register of the cryptographic assets and controls used across an organisation. It includes keys, certificates, secrets, protocols, ownership, rotation status, dependencies, and runtime usage, which makes it a governance tool rather than a software manifest.
• Cryptographic Identity Drift: Cryptographic identity drift is the gap between declared cryptographic capability and actual production state. It appears when documented algorithms, key handling, and policy settings no longer match the live environment, creating exposure that static inventories cannot see.
• Machine Identity Lifecycle: Machine identity lifecycle is the governed sequence of issuing, using, monitoring, rotating, and retiring non-human trust material such as keys, certificates, and secrets. In cryptographic environments, lifecycle discipline determines whether identity remains trustworthy after deployment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Introducing the Cryptographic Bill of Materials (CBOM): A Foundation for Modern Cryptographic Management. Read the original.