---
title: "Cryptographic bill of materials"
---
<!-- licenses: platform -->

The **((Cryptographic bill of materials))** (CBOM) report is available on the [Reports page](https://console.runzero.com/reports/) and gives you an inventory of cryptographic algorithms, protocol versions, certificates, public keys, and reused key material observed in your organization. It helps you identify cryptography that is already weak, find classical public-key cryptography that will require a post-quantum migration, and prioritize remediation.

The cryptographic inventory can also be exported 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 either quantum-safe or quantum-unsafe. It considers 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 currently classically strong 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 actual 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 similarly assessed using 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** remains an explicit uncertainty state rather than being 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 first because they represent 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 determine whether additional scanning, service evidence, or algorithm identification is needed.