CBOMs turn cryptographic inventory into a compliance priority

At a glance

What this is: Cycode frames CBOMs as the missing inventory layer for cryptography, with the key finding that discovery is now a compliance problem as well as a technical one.

Why it matters: This matters because IAM, PAM, and security teams increasingly need visibility into cryptographic dependencies across software, pipelines, and services before migration deadlines turn hidden crypto into operational risk.

By the numbers:

• Executive Order 14412 directs CISA and NIST to publish the minimum elements for a CBOM within 270 days.
• Federal agencies must move high-value assets and high-impact systems to post-quantum key establishment by December 31, 2030.
• Post-quantum digital signatures are due by December 31, 2031.

Context

A cryptographic bill of materials is a visibility control for the cryptographic layer of software. It tells teams which algorithms, key lengths, protocol versions, certificate configurations, and libraries are in use, so the organisation can assess where cryptography will fail future requirements.

The governance gap is not that teams lack cryptography, but that most cannot inventory it with the same discipline they apply to software components. In identity and broader security programmes, that matters because hidden crypto becomes hidden dependency risk, especially where services, APIs, and third-party software inherit long-lived credentials and trust relationships.

Cycode's article is grounded in post-quantum migration planning, but the underlying problem is broader: if you cannot map cryptographic dependencies, you cannot manage crypto agility, compliance timing, or system ownership with confidence.

Key questions

Q: What usually breaks when cryptographic inventory is incomplete?

A: Incomplete inventory breaks prioritisation. Teams cannot tell which systems use which algorithms, which suppliers depend on them, or which assets are too critical to migrate without testing. That creates blind spots in PQC planning and pushes organisations into reactive, high-risk transitions instead of sequenced change.

Q: When should organisations prioritise CBOM work over waiting for final guidance?

A: They should start now, because discovery takes longer than policy issuance and the hardest part of a CBOM is finding where cryptography actually lives. Waiting for final guidance compresses the migration window and increases cost. Early inventory work also gives teams time to identify hard-coded dependencies before replacement becomes urgent.

Q: How do teams know whether crypto-agility is actually working?

A: Crypto-agility is working when algorithms can be changed without major re-engineering and the inventory shows which systems will be affected before the change is made. Signs of failure include unknown embedded libraries, orphaned certificates, and long manual remediation cycles. If the estate cannot absorb algorithm change predictably, the architecture is not agile enough.

Q: Should identity and platform teams own CBOMs together?

A: Yes. Certificates, signing keys, and protocol choices are part of service identity and trust, so CBOM work sits at the intersection of identity governance, platform engineering, and security architecture. If the inventory lives only with a crypto specialist, ownership gaps will remain. Joint governance is the only way to keep the inventory accurate and actionable.

Technical breakdown

What a CBOM actually inventories

A CBOM is the cryptographic counterpart to an SBOM. Instead of listing software packages, it records the cryptographic primitives, protocol versions, certificate settings, and libraries that software uses. That includes RSA, ECC, TLS versions, hashing functions, and where those dependencies live in code or runtime systems. The key point is that cryptography is often embedded inside other components, so discovery has to reach into libraries, services, and platform layers rather than stopping at application manifests. Without that layer of inventory, teams can see software but still miss the cryptographic exposure inside it.

Practical implication: Build inventory workflows that identify cryptographic dependencies inside existing software and runtime assets, not just at application level.

Why SBOMs are the prerequisite layer

An SBOM and a CBOM are not parallel artefacts. The SBOM tells you which components exist, while the CBOM tells you which of those components implement cryptography. That dependency matters because a library is where most cryptographic implementation actually sits. If the component inventory is incomplete, the cryptographic inventory will be incomplete too. The article's point is operational: the path to a usable CBOM starts with a living software inventory, then extends into cryptographic inspection. Teams that treat SBOMs as static audit exports will struggle to produce a trustworthy CBOM.

Practical implication: Use the SBOM as the authoritative starting point for cryptographic discovery and keep it current as code and dependencies change.

Crypto agility as the real control objective

Crypto agility is the ability to replace one algorithm with another without redesigning the system around it. That matters because a CBOM can show every vulnerable algorithm, but it cannot on its own tell you whether replacement is a configuration change or a major refactor. The article distinguishes discovery from replaceability: inventory finds the risk, agility determines whether remediation is practical within the migration window. In practice, hard-coded cryptography creates the longest tail of exposure because it ties security decisions to application logic rather than to a governable control layer.

Practical implication: Design cryptographic dependencies so algorithm changes can be executed through configuration or policy instead of code rewrites.

Threat narrative

Attacker objective: Exploit the long retention period of encrypted data and cryptographic dependencies so future decryption or forced migration creates operational failure.

1. Entry occurs through long-lived software and protocol dependencies that already embed RSA, ECC, TLS, and certificate configurations across systems.
2. Credential and trust exposure persists because those cryptographic dependencies remain hidden inside libraries, APIs, cloud services, and third-party tools that teams cannot easily enumerate.
3. Impact emerges when organisations need to remove vulnerable algorithms quickly but discover they lack both visibility and crypto agility, turning migration into a delayed compliance and resilience problem.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cryptographic invisibility is now a governance failure, not just a tooling gap. The article's central point is that teams can no longer treat cryptographic inventory as an informal technical exercise. Once regulators name CBOMs explicitly, absence of visibility becomes an accountability issue for security, architecture, and platform owners. Practitioners should treat cryptographic discovery as a governed control with owners, scope, and measurable coverage.

CBOMs expose a crypto agility debt that many programmes have ignored. Discovering RSA or ECC in a system is only useful if the organisation can replace it without redesigning the service. That makes crypto agility a readiness issue across IAM, PKI, application architecture, and supply chain governance. Practitioners should expect migration cost to be driven more by dependency rigidity than by the cryptographic standard itself.

Cryptographic inventory and identity governance now overlap more than many teams assume. Certificates, signing keys, and protocol choices are part of how services prove identity to one another, which means CBOMs matter to workload identity and machine trust as well as to pure cryptography. The emerging control concept is cryptographic dependency visibility: if you cannot see the trust primitives, you cannot govern the trust model. Practitioners should map CBOM work into identity and platform governance, not isolate it inside crypto specialists.

The new compliance pressure is not the mandate alone, but the lag between discovery and remediation. The article makes clear that inventory is the slow part, while replacement is where programme time gets consumed. That means organisations should budget for visibility, classification, ownership, and remediation sequencing as separate workstreams. Practitioners should start now because the backlog, not the deadline, will determine the actual risk.

CBOMs will force security teams to think in terms of replaceable trust, not permanent trust. Legacy cryptography often creates assumptions that algorithms will remain acceptable for the life of a system. That assumption is now collapsing under post-quantum planning. Practitioners should align cryptographic governance with asset lifecycles so trust mechanisms can be exchanged before they become blockers.

What this signals

Cryptographic dependency visibility: organisations now need to govern not just whether cryptography exists, but where each algorithm and certificate is embedded across the delivery chain. That shifts CBOM work into the same operational territory as identity inventory and workload trust, where ownership and lifecycle control matter as much as technical discovery.

The immediate programme risk is not lack of awareness, but lack of replaceability. A team that can name every RSA instance but cannot change it quickly has only documented its backlog, so the practical focus should be on inventory plus crypto agility together.

For practitioners

• Map cryptography at the component level Extend SBOM workflows to identify which libraries, services, and certificates actually implement cryptography across applications and pipelines.
• Classify algorithms by migration risk Tag each cryptographic primitive as quantum-vulnerable, post-quantum safe, or unclear, then use that classification to prioritise remediation.
• Prioritise long-lived data paths first Start with systems protecting records that must remain confidential for years, because harvest-now, decrypt-later risk is highest there.
• Separate discovery from remediation planning Assign ownership for inventory, dependency analysis, and replacement sequencing before guidance arrives so the work does not become a single deadline-driven backlog.
• Design for crypto agility in new builds Push algorithm selection into configuration layers where possible so future cryptographic changes do not require service re-architecture.

Key takeaways

• CBOMs move cryptography from an invisible implementation detail into a governable inventory problem.
• The article shows that discovery is the slowest part of post-quantum readiness, so delaying inventory compresses remediation time.
• The decisive control is crypto agility, because visibility alone does not reduce risk unless algorithms can be replaced without re-architecting systems.

Key terms

• Cryptographic Bill of Materials: A cryptographic bill of materials lists the cryptographic capabilities built into software components, such as supported algorithms and libraries. It is useful for component visibility, but it does not show live configuration, deployment context or actual runtime usage. That makes it a partial input, not the full governance record.
• Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
• Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
• Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity control with broader security operations. It helps security and IAM teams build a shared language for governance across human and non-human identities.