Cryptographic bill of materials
The Cryptographic bill of materials (CBOM) report on the Reports page inventories the cryptographic algorithms, protocol versions, certificates, public keys, and reused key material observed in your organization. Use it to identify cryptography that is already weak, find classical public-key cryptography that will need a post-quantum migration, and prioritize remediation.
You can also export the cryptographic inventory as CycloneDX JSON from the asset export API:
https://console.runzero.com/api/v1.0/export/org/assets.cbom.json
Post-quantum status
The report assigns each observed cryptographic component a post-quantum status. The status is not a simple claim that an entire service is quantum-safe or quantum-unsafe. It accounts for the algorithm’s cryptographic role, protocol version, negotiated key exchange, and known classical weaknesses.
| Status | Meaning |
|---|---|
| Unsafe | The cryptography is broken or provides little or no protection today, independently of quantum computing. Examples include SSL 2.0, SSL 3.0, RC4, single DES, MD5, NULL, and export-grade cipher suites. |
| Deprecated | The cryptography is superseded and should be removed, but is not considered practically broken in the observed role. Examples include TLS 1.0 and 1.1, SHA-1, 3DES, 64-bit block ciphers such as Blowfish and CAST, RIPEMD, and severely truncated authentication tags. |
| Transitional | The cryptography is classically strong today but does not demonstrate post-quantum readiness, or it uses a classical asymmetric algorithm that a sufficiently capable quantum computer could break. Examples include classical key agreement, RSA key transport, classical public-key encryption and signatures, TLS 1.2, TLS 1.3 without a recognized post-quantum key exchange, and SSH with only classical key exchange. |
| Safe | The observation includes a recognized post-quantum or hybrid algorithm, or a symmetric or hash construction that retains useful security against quantum attacks. AES-128, AES-192, AES-256, SHA-256, and SHA-384 qualify; they are not downgraded solely because of Grover’s algorithm. |
| Unknown | Cryptographic material was observed, but the algorithm, protocol evidence, or cryptographic role could not be recognized reliably. Unknown is a visibility or classification gap, not an assumption that the cryptography is safe. |
TLS and SSH rules
For TLS, Safe requires both TLS 1.3 and a recognized post-quantum or hybrid key exchange. TLS 1.3 without that exchange is Transitional. TLS 1.0 or 1.1 is Deprecated, and SSL 2.0 or 3.0 is Unsafe, even when a service also supports TLS 1.3 and a post-quantum exchange.
For SSH, a recognized post-quantum or hybrid key-exchange algorithm advertised in the server’s KEXINIT response is Safe. A server that advertises only classical key exchange is Transitional. If no key-exchange algorithm is observed, the result is Unknown.
Combined results
When a certificate contains both a public-key algorithm and a signature algorithm, the certificate receives the worse status of the two. A cipher suite is assessed the same way from its component algorithms. For an asset, the report uses the worst status observed across its relevant TLS and SSH services.
The status severity order is:
Unsafe > Deprecated > Transitional > Safe
Unknown stays an explicit uncertainty state and is not counted as Safe.
Migration deadlines
The report shows published transition schedules alongside the inventory. For United States federal high-value assets and high-impact systems, Executive Order 14412 sets these dates:
- December 31, 2030: post-quantum cryptography for key establishment, as defined in FIPS 203.
- December 31, 2031: post-quantum cryptography for digital signatures, as defined in FIPS 186-5.
These dates are published milestones, not runZero estimates. The report keeps FIPS approval separate from post-quantum status: an algorithm can be post-quantum without being FIPS-approved, and a FIPS-approved algorithm can still be vulnerable to quantum attacks.
Interpreting the results
Prioritize Unsafe findings: they are present-day cryptographic weaknesses. Address Deprecated findings next, then use Transitional findings to build and execute your post-quantum migration plan. Investigate Unknown findings to decide whether you need more scanning, service evidence, or algorithm identification.