With the final announcement of RFC 9964, formerly draft-ietf-cose-dilithium, ML-DSA serializations for JOSE and COSE just landed. It has raised a question whether leaf certificate in the current scan data presents any insights into classical signatures. Looking at a sample of 103K certificates with a recorded signature algorithm, none yet were ML-DSA or SLH-DSA. RSA signs roughly four out of five of them, with SHA256-RSA alone accounting for 80K, and ECDSA covers most of what remains.
| Signature algorithm | Key type | Certificates |
|---|---|---|
| SHA256-RSA | RSA | 80K |
| ECDSA-SHA384 | ECDSA | 10K |
| ECDSA-SHA256 | ECDSA | 10K |
| SHA384-RSA | RSA | 1.5K |
| SHA512-RSA | RSA | 1.5K |
| ML-DSA / SLH-DSA | post-quantum | ZERO |
The specifications being final should change all this. RFC 9881, published in October 2025, defines the X.509 algorithm identifiers that a certificate authority would use to issue an ML-DSA certificate. RFC 9964 defines ML-DSA serializations for JOSE and COSE, the token layer carrying JWTs and the COSE objects used in constrained devices and supply-chain attestation. The path from classic certificates to post-quantum is specified end to end now. Certificates should already start to show adoption.
The gap from key exchange
Key exchange migrated ahead of authentication because harvest-now-decrypt-later makes a recorded session decryptable the day a capable quantum computer lands, which gives key establishment present-tense urgency. A signature cannot be forged retroactively against traffic already sent, so the pressure to replace it isn't the same. What looking at a large dataset adds is a measure of what's about to start moving. The CDN vendors show the split cleanly.
A scan of three of them today negotiated X25519MLKEM768, the hybrid post-quantum key exchange we like to see, and then presented their leaf certificates signed without ML-DSA.
| akamai.com | cloudflare.com | fastly.com | |
|---|---|---|---|
| Cipher | AES-256-GCM | AES-128-GCM | AES-128-GCM |
| Grade | A (100/100) | F (0/100) | A (100/100) |
| Key exchange | X25519MLKEM768 | X25519MLKEM768 | X25519MLKEM768 |
| Leaf signature | ECDSA-SHA384 | ECDSA-SHA256 | SHA256-RSA |
| Legacy TLS 1.0/1.1 | rejected | accepted | rejected |
| Negotiated version | TLS 1.3 | TLS 1.3 | TLS 1.3 |
One handshake, hybrid key exchange, yet a classical signature. The edge has been the vendor area furthest along on key exchange, since it is the infrastructure behind the high client-side adoption numbers. And we can clearly see certificate signature has not moved. The KEM-side has a false floor that earlier measurements documented, and now we're watching for the same on the signature side. The Internet deserves better than zero.
Leaf certs will be first
Leafs rotate on short cycles, commonly ninety days, and the industry continues to shorten them towards 47 days. A host adopting post-quantum signatures would show the change at the leaf well before any movement in long-lived intermediate or root certificates. That makes the leaf our leading candidate, and so far we see only classical without exception. The reading reflects the leaf only, taken from the first certificate in the presented chain, so it describes the signature a host presents for itself rather than the algorithms its certificate authorities use higher in the chain. Fastest agility is the spot to keep an eye on.
Size matters
The cost of a post-quantum signature is concrete and large. An ML-DSA-65 chain entry runs 5,261 bytes against 550 for RSA-2048 and 163 for ECDSA-P256, and a two-signature chain crosses into ten kilobytes of authentication data where a classical chain carried a few hundred bytes. That weight pushes a server flight past the IW10 congestion window and the QUIC anti-amplification limit, which is the network cost the size reference covers in detail. Key exchange migration mostly avoided this because its byte cost is a fraction of the signature cost. The signature layer cannot avoid it, and the friction helps explain why the specified path and the deployed reality remain far apart. The handshake size calculator sizes a specific KEM and signature combination against those boundaries for a given stack.
Methodology
pqprobe parses the leaf certificate from each TLS handshake and records its signature algorithm, key type, and key size into the scan record. To reproduce the distribution against your own host population, scan and export the certificate inventory:
$ pqprobe scan example.com:443
$ pqprobe probe example.com # DNS fan-out across a domain
$ pqprobe export-certificates certs.csvThe CSV has one row per certificate. Group on the Signature Algorithm column in your spreadsheet or CSV tool of choice to reproduce the distribution table; filter the same column for ML-DSA or SLH-DSA to reproduce the zero.
The signature algorithm is present for roughly 90 percent of 103K sampled records. The last ten percent are scans where no certificate was parsed, such as non-TLS protocol probes. The post-quantum check remains zero as of this writing.
The specifications for post-quantum signatures rolled up inside the span of just half a year. The certificates we're seeing have not begun to use them, and all eyes now should be on the leaf, the first place that change will show.