Cryptographic Bill of Materials (CBOM) as a discipline is still finding its shape. Standards are maturing, tooling is evolving and regulations are being refined as adoption grows. CERT-In v2.0 requires government, public sector and essential services organisations to maintain CBOMs and obtain them from suppliers, and RBI’s advisory directs regulated entities to maintain a CBOM for quantum-safe preparedness.
The practices below reflect the current state of the field; as the landscape develops, so will what good looks like. We will keep this guidance current as that happens.
What is already clear: a CBOM built without structure becomes a liability. Incomplete coverage, stale entries and no ownership create the illusion of governance without the substance of it. These nine CBOM best practices address the gaps that matter most right now.
1. Generate continuously, not periodically
A CBOM updated quarterly is outdated before it is reviewed. Every code commit, deployment and infrastructure change introduces or modifies cryptographic assets. Automate CBOM generation and it needs to be tied to these events not to a calendar. Treat your CBOM the way you treat a vulnerability scanner: always running, always current.
2. Cover every cryptographic surface
Source code is the starting point, not the finish line. A complete CBOM tool pulls from network endpoints, container images, build artifacts, cloud KMS platforms, HSMs, CI/CD configurations and third-party dependencies. Cryptography embedded in vendor-supplied components and open-source libraries sits outside your direct control – which is exactly why it needs to be in your inventory.
3. Assign ownership to every asset
An asset with no owner is an asset no one is responsible for. Every certificate, key and algorithm entry in your CBOM needs an explicit owner – a team or service account – with clear escalation paths for expirations, policy violations and revocation events. Ownerless assets are the ones that expire unnoticed and surface during audits.
4. Use standard machine-readable formats
Output in CycloneDX 1.6/1.7 or SPDX. Both are referenced by CERT-In, NIST and OWASP. Proprietary formats create friction with vulnerability feeds, audit workflows and downstream DevSecOps tooling. CycloneDX has native cryptographic asset support – it is the right format for CBOM specifically.
5. Link your CBOM to your SBOM
A CBOM entry for OpenSSL is incomplete without knowing which applications depend on it. Linking cryptographic asset entries to their parent SBOM components gives you full traceability – from algorithm to library to application to business function. This linkage is what makes impact assessment fast when a vulnerability is disclosed. Read our blog: The Complete Bill of Materials Stack Every CISO Needs in 2026
6. Enforce policy at the pipeline, not after deployment
Define your approved algorithm list and run automated checks at build time. A deprecated algorithm caught at commit is a quick fix. The same finding surfaced during a regulatory audit is a remediation project. Policy gates in the CI/CD pipeline are the difference between prevention and reaction.
7. Prioritise findings by exploitability
Not every deprecated algorithm carries the same risk. RSA-1024 protecting a live payment system is a different priority from SHA-1 in an internal logging tool. Prioritise by actual exploitability, data sensitivity and regulatory exposure – a flat, unranked list of findings does not give security teams a usable action plan.
8. Track quantum-vulnerable algorithms as a separate view
Maintain a dedicated inventory of assets using RSA, ECC, Diffie-Hellman and DSA – the algorithms NIST has identified as quantum-vulnerable. This sub-inventory defines your post-quantum cryptography (PQC) migration scope. Without it, estimating migration effort and planning algorithm transitions across hundreds of applications is guesswork.
Before you scope that migration, test where you stand today. Our CBOM checklist of 12 cryptographic readiness questions is a quick way to surface the gaps.
9. Generate audit-ready output on demand
Your CBOM should produce compliance-mapped reports at any point, aligned to CERT-In v2.0, RBI Advisory 11/2024 and NIST standards from live data. If building that evidence requires manual assembly before every audit cycle, the operational cost of compliance stays unnecessarily high.
A CBOM does not replace a cryptographic audit, though. The CBOM keeps your evidence current between audits, while the audit tests whether the controls behind it actually work. Here’s how a CBOM and a cryptographic audit fit into one governance framework.
Conclusion
CBOM governance is not a project with an end date. It is an operational capability that needs to be built into how your environment is run not bolted on ahead of audits. The practices above represent the current baseline: continuous generation, complete coverage, clear ownership, standard formats and policy enforcement at the source.
CyberNX’s CBOM solutions put these practices into operation, combining multi-source scanning across code, cloud, HSMs and third-party dependencies into a continuously maintained CBOM per application, with CycloneDX-compliant output mapped to CERT-In, RBI and NIST frameworks. Findings are prioritised by exploitability and delivered as a clear action plan. Plus, it lays down the foundation for PQC readiness.
To learn how our CBOM solutions manage generation and monitoring across your application estate, talk to us today.
CBOM best practices FAQs
What are CBOM best practices?
CBOM best practices cover continuous generation, multi-surface coverage, asset ownership, standard output formats, SBOM linkage, pipeline-level policy enforcement, exploitability-based prioritisation, quantum-vulnerable algorithm tracking and on-demand audit output.
How often should a CBOM be updated?
Continuously – triggered by code commits, deployments and infrastructure changes. Scheduled updates are insufficient for environments where cryptographic assets change with every release cycle.
Should a CBOM separate cryptographic libraries from the applications that use them?
CERT-In recommends documenting both the implementation and the usage of cryptographic assets. It asks you to clearly distinguish libraries that implement algorithms from applications that use them, so impact analysis is accurate when there’s a vulnerability or update. This is the main reason CBOMs overflow with irrelevant findings, and the post doesn’t mention it.
What should vendor contracts require for CBOM and PQC readiness?
CERT-In recommends tiered PQC requirements in vendor contracts:
- documentation of all cryptographic implementations
- quarterly migration progress reports with C-level attestation
- penalty clauses for non-compliance
- proofs of concept for quantum-safe alternatives before contract renewal
