> ## Documentation Index
> Fetch the complete documentation index at: https://docs.celum.io/llms.txt
> Use this file to discover all available pages before exploring further.

# PQC Readiness

> Which TLS handshakes on a supervisor already use a post-quantum key exchange, which servers and clients hold them back, what the gateways offer, and the certificates a later migration replaces.

**Security → PQC Readiness** answers one question: how much of a supervisor's TLS already negotiates a **post-quantum key exchange** (a hybrid with ML-KEM), and what keeps the rest classical. Data harvested today can be decrypted later by a quantum computer only if its key exchange was classical, so this is the part worth moving first.

It reads the whole supervisor, so it is not offered at a project address.

## The tiles

| Tile | What it counts (last 24 hours) |
| - | - |
| **Post-quantum handshakes** | the share of handshakes served in the cluster that agreed on a post-quantum group |
| **Servers negotiating ML-KEM** | workloads and ports that negotiated one at least once, out of all that served TLS |
| **Clients offering ML-KEM** | workloads that sent an ML-KEM key share, out of all TLS clients |
| **TLS 1.3** | the share of handshakes at TLS 1.3. A hybrid key exchange needs 1.3 |
| **Gateways offering ML-KEM** | the gateways whose Envoy offers it, and how many more cannot be read from here |
| **Served certificates** | the certificates the gateways serve, by key type |

Above the tables, a notice names the servers that negotiated **no** post-quantum key exchange at all in the window, busiest first.

## Servers in the cluster

Every ServerHello a pod, a VM or a node sent, recorded by the cluster agent on the node that sent it: one row per workload and port, and a row without a workload is the node itself. Classical first, busiest first. Each row shows its clients, handshakes, the key-exchange group and TLS version mix, the post-quantum share and a verdict:

| Verdict | Meaning |
| - | - |
| **post-quantum** | every handshake used a post-quantum group |
| **mixed** | the server supports ML-KEM, but some of its clients did not offer it |
| **classical only** | no handshake used one: the server does not support a hybrid, or none of its clients offered one |

## Clients in the cluster

Every ClientHello a pod, a VM or a node sent, and whether it carried a post-quantum key share. A client that offers none gets a classical session from every server, however ready the server is — so for a mixed server, this table says which clients to upgrade. A client's verdict is **offers ML-KEM** (every hello did), **mixed** (some did — often several programs behind one name) or **classical only**.

Each client lists its destinations: the SNI, or the address the socket dialled (a Service IP before translation). **+N more** opens the full list, up to 200 destinations per client, with the destinations reached classically first, so a client at 60% says which of its connections are the other 40%.

## Gateways

* **Gateways — negotiated key exchange:** Envoy's own handshake counters, cumulative since each proxy started. The supervisor's proxies are read live; guest-cluster gateways come from the counters their agents remote-write to this supervisor's Prometheus. A gateway is **post-quantum** (clients have negotiated a hybrid with it), **offered, unused** (it offers ML-KEM but no client has negotiated it since its proxies started) or **classical only**.
* **Gateway clients by host:** from the Envoy Gateway access log, per published host, the TLS version clients use. A client below TLS 1.3 cannot negotiate a hybrid even once the gateway offers one. It fills once a published host is used, and needs the Gateway access log dispatcher (Onboarding → Flow Telemetry).

## Certificates the gateways serve

The leaf certificate in every Secret a Gateway listener references. A post-quantum **signature** (ML-DSA) needs certificate authorities and clients that do not ship it yet, so this is the inventory a later migration replaces; only certificates below today's classical floor are flagged.

## Where the data comes from

| Part | Source |
| - | - |
| Servers, clients | the cluster agent's TLS handshake sniffer on every node, written to ClickHouse ([Flow telemetry](https://docs.celum.io/platform-health/flow-telemetry.md)) |
| Gateway counters | Envoy's statistics, read live or from Prometheus |
| Gateway clients by host | the Envoy Gateway access log |
| Certificates | the Secrets the Gateway listeners reference |

## API and MCP

`GET /api/supervisors/{name}/security/pqc` (`security:Read`) returns all of it; `?destinations=all` returns every destination of each client. Over MCP: `get_pqc_readiness`, whose `destinationBreakdown` holds only the destinations reached classically.

## Related

> [card] [Gateways & Routes](https://docs.celum.io/networking/gateways-and-routes.md)
>
> The gateways whose key exchange this page reads.

> [card] [Flow telemetry](https://docs.celum.io/platform-health/flow-telemetry.md)
>
> The dispatchers that record the handshakes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.