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 classification and confidentiality lifetime.
- External exposure: internet, partner, internal, device, or third party.
- Change difficulty: low, medium, high, or unknown.
- Evidence source and evidence date.
- Risk notes and next action.
The "unknown" value is useful. It shows where discovery needs to continue instead of hiding gaps.
Evidence collection methods
A cryptographic inventory is only as credible as its evidence. Mix automated and manual discovery methods.
Useful sources include:
- TLS and certificate scanning for public and internal endpoints.
- Cloud configuration exports for load balancers, certificate managers, KMS, and secrets systems.
- Repository searches for cryptographic libraries, hard-coded algorithms, and protocol settings.
- Container and package dependency data.
- Application configuration exports.
- HSM, KMS, and certificate authority reports.
- Vendor security questionnaires and attestations.
- Architecture diagrams and data flow maps.
- Interviews with application owners when automation cannot see enough.
Avoid treating any one source as complete. Cryptography is often spread across infrastructure, application code, third-party products, and managed services.
Step-by-step: build the first CBOM
- Select a business service with meaningful risk and cooperative owners.
- Define the cryptographic use cases to capture: TLS, storage encryption, signing, key management, application libraries, and vendor dependencies.
- Pull automated evidence from scanning, configuration exports, and repositories.
- Review the evidence with the application owner and infrastructure owner.
- Record unknowns explicitly instead of guessing.
- Identify dependencies controlled by vendors or managed platforms.
- Rate change difficulty for each cryptographic dependency.
- Add remediation actions for expired certificates, weak protocols, unsupported libraries, hard-coded algorithms, or unclear ownership.
- Repeat the process with another service and refine the schema.
- Roll the pattern into a recurring security and compliance workflow.
Practical checklist
Before calling your inventory complete enough for decision-making, verify that it includes:
- The highest-risk systems, not just the easiest systems to scan.
- Ownership fields that identify who can approve and execute changes.
- Evidence dates so stale entries are visible.
- Vendor-controlled cryptography and renewal timelines.
- Data lifetime and business criticality.
- Certificate, protocol, library, and key management details where available.
- A risk rating or prioritization method.
- Clear next actions for unknown, high-risk, or non-agile cryptography.
Common mistakes to avoid
Making the schema too complex at the start
A complex schema can slow adoption. Start with fields that answer risk and ownership questions, then add detail as teams learn what decisions they need to make.
Confusing discovery with governance
Scanning finds evidence. Governance determines who reviews it, how often it is refreshed, and how findings become remediation work.
Ignoring non-production systems
Development and staging environments can contain sensitive data, certificates, test keys, and embedded dependencies. They may also reveal production patterns.
Forgetting vendor cryptography
Vendor systems can be critical to post-quantum readiness, certificate risk, and compliance posture. A CBOM program should ask vendors for cryptographic transparency and change plans.
Treating unknowns as low risk
Unknown cryptography should not automatically be rated low. Unknowns may represent weak visibility, missing ownership, or hard-to-change dependencies.
FAQ
Is a CBOM required for PQC readiness?
A CBOM is not the only way to prepare, but it is a practical way to document cryptographic dependencies and prioritize systems that may need algorithm, library, certificate, or protocol changes.
How often should the inventory be refreshed?
Refresh cadence should match change rate and risk. Internet-facing certificates and TLS exposure may need frequent review. Vendor attestations and deep application CBOMs may be reviewed during security reviews, major releases, or procurement cycles.
Can this be fully automated?
Automation can discover a lot, especially TLS, certificates, packages, and cloud configuration. Human validation is still needed for ownership, business criticality, data lifetime, and vendor-controlled dependencies.
Who should own the inventory?
Security usually owns the program, but the data must be maintained with engineering, infrastructure, cloud, compliance, procurement, and vendor management stakeholders.
CipherReady CTA
CipherReady helps teams create cryptographic inventories and CBOM workflows that are practical, evidence-based, and aligned with PQC readiness. If you need to find cryptographic dependencies, prioritize remediation, and improve crypto agility without overwhelming application teams, CipherReady can help structure the program and accelerate discovery.