Cryptographic Inventory
How to Build a Cryptographic Inventory and CBOM Without Boiling the Ocean
Learn how to build a practical cryptographic inventory and CBOM for PQC readiness, vendor risk, TLS exposure, and crypto-agility planning.
How to Build a Cryptographic Inventory and CBOM Without Boiling the Ocean A cryptographic inventory is one of the most useful artifacts a security team can build, but it often fails when teams try to make it complete before making it useful. A practical inventory starts with the systems that matter most, captures enough detail to support decisions, and improves through repeated evidence collection. A Cryptographic Bill of Materials, or CBOM, can extend that inventory by documenting the cryptographic components and dependencies inside products, applications, services, and vendor offerings. Together, a cryptographic inventory and CBOM help teams answer a simple question: when cryptographic risk changes, what exactly do we need to fix? What a cryptographic inventory should answer A good inventory does not merely list assets. It connects cryptography to risk, ownership, and change. At minimum, the inventory should help answer: Where is cryptography used across applications, infrastructure, cloud, endpoints, identity, databases, and third parties? What algorithms, protocols, keys, certificates, and libraries are in use? Which systems protect sensitive or long lived data? Who owns the system and who can change its cryptographic configuration? What evidence supports each entry? Which dependencies are internal, open source, commercial, managed service, or vendor controlled? How hard would it be to rotate, upgrade, or replace the cryptography? If the inventory cannot help prioritize action, it is probably too asset centric and not decision centric enough. CBOM vs SBOM vs asset inventory A software bill of materials identifies software components. An asset inventory identifies systems and infrastructure. A CBOM focuses on cryptographic materials and behavior. The three views are complementary: Asset inventory tells you what exists. SBOM tells you what software components are present. CBOM tells you what cryptographic mechanisms those assets and components rely on. For post quantum readiness and crypto agility, CBOM detail is especially valuable because a system may appear current from an asset perspective while still depending on hard to change cryptographic libraries, certificate chains, signing methods, or protocols. Start with a scoped inventory wave Do not begin by asking every team for a full cryptographic dependency map. Begin with a focused wave that produces usable output within a defined timebox. Good first wave scopes include: Internet facing TLS and certificate exposure. Identity and access management systems. Systems that store regulated or long retention data. Customer facing SaaS applications. Payment, healthcare, or regulated data exchange workflows. Vendor managed services connected to sensitive data. A successful first wave creates a repeatable pattern that can be expanded. Recommended inventory fields Use fields that support prioritization and remediation. The exact schema can evolve, but these fields are a strong starting point: Business service or application name. Environment: production, staging, development, SaaS, vendor managed, or embedded. Owner and technical contact. Cryptographic use case: transport, storage, signing, identity, backup, database, messaging, code signing, or key exchange. Protocol and version where applicable. Algorithm and key length where known. Certificate subject, issuer, expiration, and chain details where applicable. Library, framework, HSM, KMS, certificate authority, or secrets platform. Data cla