Every post-quantum plan starts with the same line item: inventory your cryptography. The deliverable behind that line is a CBOM, a cryptographic bill of materials, and in 2026 there is finally enough standardization and open tooling to build one systematically instead of by spreadsheet archaeology. This guide covers the format, the discovery tools that exist today, their real coverage gaps, and a workflow you can rerun every release.
What is a CBOM, and how is it different from an SBOM?
A CBOM is a machine-readable inventory of every cryptographic asset in a system, algorithms with their parameters, certificates, keys, and protocol configurations, plus the dependencies between them and the components that use them. An SBOM lists the packages you ship; a CBOM records which cryptography those packages, configs, and endpoints actually use.
The distinction matters because vulnerable cryptography rarely maps one-to-one to a package version. OpenSSL 3.x in an SBOM tells you nothing about whether a service still negotiates TLS 1.0, pins RSA-2048, or has SHA-1 hardcoded in a signing path. CycloneDX 1.6 introduced cryptographic assets as a first-class component type precisely because package-level tooling cannot express facts like: this endpoint negotiates ECDHE over P-256 and presents a certificate expiring in 2027. If SBOM fundamentals are new to your team, The Software Supply Chain in 2026: SBOMs, Provenance, and the CRA Reckoning covers that layer; this guide assumes it and goes one level deeper.
Why build a CBOM now instead of during the migration?
Because inventory is the migration's critical path. The EU coordinated post-quantum roadmap and national guidance from BSI, ANSSI, and other agencies all put cryptographic discovery first, with commonly cited milestones for beginning high-risk transitions around the end of 2026, dates you should verify against primary Commission and ENISA publications before committing plans to them.
Discovery consistently takes longer than teams expect, typically months for an estate of any size, because cryptography hides in firmware, third-party SDKs, stored file formats, and configuration defaults nobody has read since onboarding. We keep two companion pieces for the planning layer: Post-Quantum Migration Checklist Before the End-2026 CBOM Deadline sequences the migration itself, and Harvest Now, Decrypt Later: A Practical Post-Quantum Migration Roadmap covers why long-lived data makes this urgent now. This post stays on the tooling: how the inventory actually gets built.
Which format should you use for a CBOM?
Use CycloneDX 1.6 or later. It is the only widely adopted BOM format with native cryptographic modeling, added in the 1.6 release and carried forward since. SPDX has no comparable depth for cryptographic assets as of this writing, and spreadsheets fail at exactly the moment you need to diff, merge, or automate anything.
The parts of the model you will actually use:
- ▸assetType classifies each entry as an algorithm, certificate, protocol, or related-crypto-material (keys, tokens, seeds).
- ▸algorithmProperties captures the primitive (signature, key encapsulation, block cipher, hash), the parameter-set identifier such as RSA-2048 or ML-KEM-768, the mode of operation, and the field that does the post-quantum work: nistQuantumSecurityLevel.
- ▸certificateProperties and protocolProperties record validity windows, signature algorithms, TLS versions, and negotiated cipher suites per endpoint.
- ▸Object identifiers (OIDs) pin assets to exact standard identities, so RSA-PSS and PKCS#1 v1.5 signatures never blur into one line.
- ▸bom-ref cross-references link a certificate to the algorithm it uses and the service that presents it, the dependency edges you traverse later when planning replacements.
Which tools discover cryptography in source code?
For Java and Python, the open-source sonar-cryptography plugin for SonarQube (from IBM Research) detects cryptographic API usage and emits a CycloneDX CBOM directly. CBOMkit, hosted by the Post-Quantum Cryptography Alliance, wraps repository scanning, storage, and visualization. Coverage beyond those languages is thin as of this writing, so plan on custom rules plus targeted manual review.
- ▸sonar-cryptography resolves JCA, BouncyCastle, and Python cryptography-library calls into algorithm assets with concrete parameters, significantly better than string-matching on algorithm names.
- ▸CBOMkit provides the scanning service, a CBOM database, and a viewer; it is useful as the aggregation point even where its scanners do not reach.
- ▸For Go, Rust, and C/C++, write Semgrep or CodeQL rules targeting the standard crypto and TLS packages, OpenSSL EVP calls, and algorithm-name literals in configuration. Expect false negatives wherever algorithms are chosen dynamically at runtime, that gap is what network-level discovery exists to close.
- ▸Commercial platforms (SandboxAQ AQtive Guard is a known example) add binary and filesystem analysis. Evaluate any of them against a codebase you already know well before trusting coverage claims.
How do you inventory certificates, keys, and live TLS behavior?
Static analysis cannot see the expired wildcard certificate on a forgotten load balancer. Combine three runtime sources: a certificate inventory from your management platform or scripted sweeps of keystores and secrets managers, active endpoint scanning with sslyze or testssl.sh, and passive network observation with Zeek recording what actually gets negotiated.
- ▸Run sslyze or testssl.sh against every external and internal TLS endpoint; each scan becomes protocol entries with real negotiated versions and suites, not intended ones.
- ▸Zeek TLS logs capture live handshake behavior over time, catching legacy internal clients and services that scheduled scans miss.
- ▸Sweep the places keys actually live: Java keystores, PEM files baked into container images, Kubernetes TLS secrets, and cloud KMS listings, recording type, size, and rotation dates as related-crypto-material.
- ▸Monitor Certificate Transparency logs for certificates issued for your domains that your inventory does not know about; they are usually shadow infrastructure.
How do you merge findings into one CBOM and keep it current?
Normalize every scanner's output to CycloneDX JSON, merge with the cyclonedx-cli utility, and validate against the 1.6 schema. Version and sign the merged file per release alongside the SBOM, store it somewhere queryable, and wire regeneration into CI so drift shows up as a diff in review, not as a surprise in an audit.
- ▸Scope one merged CBOM per deployable service or clear system boundary; a single org-wide file becomes unmaintainable within a quarter.
- ▸In CI, regenerate on every release and alert when a new quantum-vulnerable primitive appears, the release-to-release diff answers whether the sprint added crypto debt.
- ▸Re-run network and certificate discovery on a schedule (monthly or quarterly is typical) and reconcile against the static view; disagreements between the two are findings in themselves.
- ▸Attach an owning team to every asset. An inventory without owners produces a migration plan nobody executes.
How do you turn the CBOM into a migration queue?
Classify, then rank. Flag quantum-vulnerable public-key primitives first: RSA, ECDSA and other elliptic-curve schemes, and finite-field Diffie-Hellman. Symmetric ciphers and hashes mostly need parameter increases at worst. Rank flagged assets by the lifetime of the data they protect, external reachability, and how hard the component is to change.
- ▸Replacement targets are the NIST-standardized families: ML-KEM (FIPS 203) for key encapsulation, with ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures; hybrid TLS key exchange combining X25519 with ML-KEM is already common in major browsers and CDNs.
- ▸Data with decade-scale confidentiality needs, health, legal, government, outranks short-lived session traffic even when both currently use the same RSA certificate, because of harvest-now-decrypt-later collection.
- ▸The hardest queue entries are usually the least crypto-agile: hardcoded algorithm choices, wire formats with fixed field sizes, HSM firmware limits. The refactoring patterns for those live in Crypto-Agility by Design: Engineering for the Post-Quantum Era.
What does the repeatable workflow look like end to end?
Five stages, rerun per release: scope a system boundary; discover statically and at runtime; enrich each asset with ownership and data-lifetime context; merge and validate into a signed CycloneDX 1.6 file; act by feeding classified findings into the migration backlog. A first pass on one critical service typically takes days to a few weeks, not months.
- ▸Scope: pick the crown-jewel service first, not the whole estate, a complete CBOM for one system beats a shallow one for fifty.
- ▸Discover: static scanners plus endpoint and network observation, as above.
- ▸Enrich: owners, data classification, retention horizon, external exposure.
- ▸Merge and validate: cyclonedx-cli, schema validation, signing, storage next to the SBOM.
- ▸Act: classification rules feed the backlog automatically; a CBOM that never generates tickets is shelfware.
How TuniCyberLabs helps
We run cryptographic discovery engagements for EU-regulated teams: building the first CBOM across code, endpoints, and PKI; standing up the CI regeneration pipeline; and converting findings into a sequenced post-quantum backlog with owners and dates. If crypto inventory has sat untouched on your roadmap for months, our security engineering services can deliver the first CBOM within weeks.