A CBOM tells you what software can do, not how it is configured in a specific environment. Organisations get into trouble when they treat component visibility as operational visibility. Real governance requires runtime state, actual usage and ownership, otherwise the inventory cannot support rotation, replacement or compliance decisions.
Why This Matters for Security Teams
Cryptographic bill of materials data is useful, but it is not an operational control plane. Teams often mistake a list of libraries, certificates, keys or signing components for proof that those assets are governed, rotated or even actively used. The real risk is not just incomplete inventory; it is false confidence. A CBOM may show what exists, yet it cannot tell whether a secret is embedded in code, duplicated across CI/CD, or still valid after offboarding.
That gap matters because identity and secret exposure usually becomes visible only after something breaks. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations including code, config files and CI/CD tools. Those findings align with the broader guidance in the NIST SP 800-63 Digital Identity Guidelines: identity evidence must support assurance decisions, not just documentation.
In practice, many security teams encounter the failure only after a leaked token, failed rotation or audit finding has already exposed the gap between cryptographic inventory and real-world control.
How It Works in Practice
A CBOM should be treated as one input to governance, not the answer itself. The useful question is not simply “what cryptographic material exists?” but “where is it deployed, who owns it, what depends on it, and what happens if it is revoked?” That means enriching CBOM records with runtime state, ownership metadata, usage telemetry and lifecycle status. Without those fields, replacement planning becomes guesswork and compliance evidence stays superficial.
Practitioners usually get further by linking CBOM data to secrets management, workload identity and access policy systems. For example, a certificate entry should be tied to the service account or workload identity that presents it, the environment where it is valid, and the policy that governs renewal or expiry. The Ultimate Guide to NHIs — Key Research and Survey Results shows why this matters: 71% of NHIs are not rotated within recommended time frames, and 91.6% of secrets remain valid five days after notification, which means data about cryptographic assets loses value quickly if it is not connected to operational action.
- Track ownership for every secret, key and certificate, not just the component name.
- Record where the asset is used: code, pipeline, container, workload or external integration.
- Link each item to rotation, revocation and replacement workflows.
- Validate whether the asset is still active by checking runtime usage, not only inventory records.
Current guidance suggests pairing CBOM with secrets discovery and workload telemetry so that inventory can support incident response, offboarding and audit evidence. These controls tend to break down in highly automated CI/CD environments because credentials are copied, reissued and consumed faster than manual records can be updated.
Common Variations and Edge Cases
Tighter cryptographic inventory often increases operational overhead, requiring organisations to balance visibility against change velocity. That tradeoff is especially sharp in containerised platforms, ephemeral workloads and multi-team DevOps environments where one secret may be referenced by many services and rotated by different owners.
There is no universal standard for this yet, so best practice is evolving. Some teams treat CBOM as a dependency map for compliance, while others use it as an enrichment layer for secrets governance and incident response. The difference is important: a compliance-first CBOM may satisfy audit questions, but it still may not tell operators which runtime identities will fail if a key is removed.
This is where NIST SP 800-63 Digital Identity Guidelines and the NHI research are complementary. NIST helps frame assurance and identity proofing, while NHIMG data shows the scale of the practical problem, including excessive privileges and widespread secret leakage. Use the Ultimate Guide to NHIs — Key Research and Survey Results when arguing for ownership, rotation and visibility controls that go beyond static component reporting.
CBOM data is most reliable when paired with runtime checks, because static artefacts can remain accurate long after their operational meaning has changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses rotation and lifecycle gaps that CBOM data alone cannot prove. |
| NIST CSF 2.0 | PR.AC-1 | Supports identity and access governance for secrets and workloads. |
| NIST SP 800-63 | IAL2 | Highlights that identity evidence must support assurance, not just inventory. |
Treat cryptographic inventory as supporting evidence and pair it with assurance-grade identity controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
