Notifications
Clear all
Topic starter
18/08/2026 2:49 pm
TL;DR: A CBOM closes the visibility gap between software inventory and cryptographic dependencies, and Cycode argues the new federal directive makes that gap actionable now, not later. The practical issue is crypto agility: without it, discovering RSA, ECC, TLS, and certificate use only creates a longer migration backlog.
NHIMG editorial — based on content published by Cycode: What Is a Cryptographic Bill of Materials (CBOM)?
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should organisations build a cryptographic inventory without starting from scratch?
A: Start with the software inventory you already trust, then identify where cryptography appears in libraries, services, certificates, and build pipelines.
Q: Why do CBOMs matter for identity and trust governance?
A: Identity programmes rely on cryptography for authentication, signing, certificate validation, and workload trust.
Q: What breaks when cryptography is hard-coded into identity platforms?
A: Hard-coded cryptography breaks migration because the organisation cannot replace algorithms, keys, or signing methods without redesigning applications and trust flows.
Practitioner guidance
- Map cryptography to runtime dependencies Extend your software inventory to capture which libraries, services, and cloud components actually invoke cryptography, then tie each item to an owner and system boundary.
- Prioritise long-lived trust paths Rank certificates, signatures, and key establishment mechanisms by data sensitivity and retention horizon, then focus first on systems protecting information that must remain confidential for years.
- Test crypto agility before migration deadlines Validate whether algorithms, key lengths, and protocol versions can be changed through configuration or whether they require code changes, rebuilds, or vendor intervention.
What's in the full article
Cycode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for mapping cryptographic libraries to specific code paths and runtime services.
- A practical six-step CBOM build process, including how to classify quantum-vulnerable algorithms.
- The relationship between SBOM and CBOM implementation in real engineering workflows.
- The article's discussion of post-quantum replacement priorities and crypto agility constraints.
👉 Read Cycode's guide to CBOMs and cryptographic inventory for post-quantum planning →
CBOMs and crypto agility: what IAM and security teams need now?
Explore further
18/08/2026 3:31 pm
Cryptographic inventory is becoming a governance baseline, not a niche architecture task. CBOMs shift crypto from an invisible implementation detail into a managed control surface. That matters because identity systems, signed workloads, and service-to-service trust all depend on cryptography that must be auditable before it can be replaced. Practitioners should treat CBOM readiness as part of identity trust governance, not only application security.
A question worth separating out:
Q: Who should own CBOM readiness in an enterprise?
A: Ownership should sit across application security, platform engineering, IAM or PKI teams, and the service owners who rely on the cryptography. The control only works when inventory, replacement decisions, and lifecycle accountability are connected. If no team can prove who rotates, replaces, or retires a cryptographic dependency, the inventory is not operational.
👉 Read our full editorial: CBOMs turn cryptographic inventory into a compliance priority
