Why SBOMs Aren't Enough: The Cryptographic Visibility Gap

The SBOM Mandate Worked

Executive Order 14028, signed in May 2021, made software bill of materials a standard practice across the federal supply chain. The impact has been substantial: organizations can now answer the fundamental question “what software do we run?” with machine-readable precision. SBOM formats like CycloneDX and SPDX have matured rapidly, tooling ecosystems have grown, and software transparency is no longer an aspiration — it’s an operational reality.

But there’s a deeper question that SBOMs can’t answer. A question that becomes more urgent with every passing month as NIST’s post-quantum deadlines approach.

What SBOMs Don’t Tell You

An SBOM tells you that your web server runs OpenSSL 3.1.4. It does not tell you:

• Which cipher suites your TLS configuration actually accepts
• Whether your server still negotiates TLS 1.0 with legacy clients
• That your Let’s Encrypt certificates use RSA-2048 signatures — quantum-vulnerable
• That your Django application hashes passwords with PBKDF2-SHA256 at 720,000 iterations
• That your database encryption uses AES-256-CBC (not GCM) with a key that hasn’t been rotated in three years
• That your SSH host keys include a 1024-bit DSA key that should have been removed a decade ago
• That your IPsec VPN tunnel still uses 3DES as a fallback cipher

An SBOM says “OpenSSL 3.1.4 is installed.” The cryptographic reality is far more complex than the software inventory suggests.

Why Crypto Is Different from Software

Cryptographic dependencies have fundamentally different characteristics than software dependencies, which is why cramming crypto into an SBOM format creates friction for both use cases.

Different update cadence. When you upgrade OpenSSL from 3.1.3 to 3.1.4, your software BOM changes but your cryptographic posture may not — you might still be using the same cipher suites, the same certificates, the same key sizes. Conversely, when NIST announces that SHA-1 is no longer acceptable for digital signatures, your cryptographic posture has changed dramatically, but your software hasn’t changed at all. Coupling these two inventories means either generating excessive updates or missing critical changes.

Different stakeholders. Software supply chain managers care about library versions, known vulnerabilities, and license compliance. Cryptographic architects care about algorithm strength, quantum vulnerability, key management practices, and migration planning. Forcing both audiences into the same document creates noise for both.

Infrastructure-layer coverage. A significant amount of cryptography lives outside the software stack entirely: HSMs and TPMs provide hardware-backed key storage and cryptographic operations. Network device configurations define VPN tunnel encryption. Certificate authorities manage trust hierarchies. DNS infrastructure uses DNSSEC. Email systems rely on S/MIME. None of these appear in an SBOM because they aren’t software components — but they’re critical cryptographic dependencies.

Protocol negotiation complexity. TLS cipher suite configuration is an ordered preference list with runtime negotiation and fallback behavior. A server may be configured to accept twelve cipher suites but only negotiate three in practice with real clients. Understanding the actual cryptographic posture requires modeling this negotiation — what’s configured, what’s preferred, what’s actually used, and what falls back to what. SBOM formats model static properties of static components. Cryptographic reality is dynamic.

The 2035 Deadline

NIST has set clear milestones for the post-quantum cryptographic transition:

• By 2030: All RSA must be replaced. Key establishment must use ML-KEM. Firmware and software signing must use ML-DSA or SLH-DSA.
• By 2033: All National Security Systems software and firmware must exclusively use CNSA 2.0 algorithms.
• By 2035: Classical asymmetric cryptography is fully deprecated for all National Security Systems.

These aren’t aspirational targets. They’re mandates with specific algorithm requirements and specific deadlines. And the scale of the problem is staggering: every RSA key, every ECDH key exchange, every ECDSA signature, every DH parameter negotiation across every system in every organization needs a replacement plan.

You cannot plan a migration for what you cannot enumerate.

Enter CBOM

The Cryptographic Bill of Materials (CBOM) is a purpose-built, machine-readable format for enumerating cryptographic dependencies. Where an SBOM tells you what software you have, a CBOM tells you what cryptography you use — and crucially, what you need to change.

A CBOM document captures every cryptographic component with full context: the algorithm and its parameters, the implementation library, the usage context (data at rest, data in transit, authentication), the deployment location (source code, configuration file, hardware, cloud service), the lifecycle status (active, deprecated, migration planned), the quantum vulnerability assessment, and the compliance mapping to regulatory frameworks.

CBOM works alongside SBOMs, not instead of them. A CBOM component can reference the SBOM component that implements it. They’re complementary layers of security inventory — SBOM for the software supply chain, CBOM for the cryptographic posture.

What’s Next

The CBOM Specification v1.0.0 is available at cbom.io/spec. The JSON Schema for validation is on GitHub. Open source scanning tooling (cbom-scan) is in development for Q3 2026.

The specification is published under CC-BY-4.0. All code is Apache 2.0. We built this because the industry needs a standard for cryptographic inventory — and the window for establishing that standard is measured in months, not years.

Read the specification. Try the schema. If your organization is planning a post-quantum migration, start with visibility. Start with CBOM.