CBOM management: ownership, policy, certificate lifecycle and drift

Generating a CBOM is a project; managing one is a practice. This guide covers the operating model that keeps a cryptographic inventory accurate and useful.

From inventory to operating model

CERT-In's Version 2.0 guidelines treat the CBOM as a living record. Organisations "must maintain an accurate and up-to-date CBOM/QBOM" (rec. 8.4.1.3), established workflows must update it as algorithms or components are introduced, modified or deprecated (8.4.1.13), and security teams should incorporate it into vulnerability management (8.4.1.9) ^[1]. Meeting those expectations needs four things: ownership, policy, lifecycle tracking and drift detection.

Ownership

Cryptography is usually shared between application teams, infrastructure, network, PKI and security. Assign responsibility explicitly:

CERT-In's best practices also call for cross-functional collaboration across security, engineering, legal and compliance ^[1]. An asset without an owner should itself be treated as a finding.

Policy as testable rules

A policy that says "use strong cryptography" cannot be tested. Write rules that the CBOM can be checked against automatically:

• Protocols: TLS 1.0 and 1.1 not permitted, reflecting RFC 8996 ^[4].
• Key sizes: no keys below 112-bit security strength, reflecting NIST SP 800-131A Rev. 2, for example RSA below 2048 bits ^[3].
• Hashes: no SHA-1 for digital signature generation except where specifically allowed ^[3].
• Modes: no ECB for data encryption.
• Your own choices, such as preferred cipher suites or minimum key sizes for new deployments.

Record exceptions with an owner, reason, compensating control and expiry date. Exceptions without expiry become permanent.

Key lifecycle

NIST SP 800-57 Part 1 Rev. 5 defines key states, pre-activation, active, suspended, deactivated, compromised and destroyed, and the cryptoperiod, "the time span during which a specific key is authorized for use" ^[2]. CERT-In's minimum key fields include state, creation date and activation date ^[1]. Use them to spot keys past their cryptoperiod, keys still active after the service they protected was retired, and compromised keys that remain in use.

Certificate lifecycle

Certificates have the most visible failure mode: expiry causes outages. The CBOM should hold every certificate's Not Valid After date and owner, and alert well before expiry. The pace is increasing. The CA/Browser Forum's Ballot SC081v3 reduces the maximum validity of publicly trusted TLS certificates in stages from 398 days to 47 days, starting in March 2026 and concluding in March 2029 ^[5]. At that cadence manual renewal is impractical, and automation through protocols such as ACME (RFC 8555) becomes necessary ^[6]. The CBOM's role is to confirm that every certificate is covered by automation and to flag those that are not. See CBOM vs certificate management.

Drift detection

Compare each new CBOM version with the previous one. Changes to watch:

• A protocol version or cipher suite reappearing after it was removed.
• New algorithm assets that break policy, often from a new library or a copied code snippet.
• Certificates issued outside the approved CAs.
• Assets disappearing without a change record, a sign that discovery coverage dropped, not that the risk went away.

CERT-In recommends version control and change management for CBOMs, and scheduled reviews "at least quarterly" ^[1].

Suppliers

Request an updated CBOM with each major release of a supplied product and on disclosure of vulnerabilities in its cryptographic components. See CBOM procurement requirements.

Measuring the practice

• Coverage: share of in-scope applications with a CBOM newer than the review period.
• Ownership: share of assets with a named owner.
• Policy: open violations by severity and age; exceptions past expiry.
• Lifecycle: certificates expiring within 30 days without automated renewal.
• Agility: time to replace an algorithm across a service, the capability NIST CSWP 39 describes as crypto agility ^[7].

How IntelliXBOM helps

IntelliXBOM keeps version history and diffs for every CBOM, so drift between scans is visible. It correlates cryptographic assets with vulnerabilities, end-of-life data and business services, records decisions such as VEX statements, and maps the inventory to framework controls with timestamped evidence for periodic reviews.