The Dashboard Says You Are Ready. Your Traffic Disagrees.
A team finishes its first wave of post-quantum work. The load balancers are upgraded, the TLS configuration lists X25519MLKEM768, and the scanner comes back green. The quarterly report says post-quantum key exchange is enabled on the external estate.
Then someone looks at what the connections actually negotiated. Every session that week established its keys with X25519. Classical. Quantum-vulnerable. Nothing was misconfigured, and nobody lied. The server offered a post-quantum group, no client asked for it, and the handshake settled on the strongest option both sides shared.
This is the gap between capability and use, and it is the single most common way a post-quantum migration reports success it has not earned. A server that supports ML-KEM and never negotiates it provides exactly as much protection against harvest-now-decrypt-later as a server that never heard of it.
What makes this hard is that the reassuring answer and the correct answer come from different measurements. Almost every tool on the market takes the first one.
The Two Questions that Sound Alike
There are two ways to ask whether a system uses post-quantum cryptography, and they don’t return the same answer.
The first is: can it? You answer that by connecting to the system and asking what it supports. This is what nearly every discovery tool does, and it is worth doing — it is the only way to learn what a system is configured to accept, which is what you need before you can change anything.
The second is: does it? You answer that by watching real traffic and recording what actual connections agreed on. Different measurements, different instrumentation, and often a different answer.
Capability is what gets reported. Use is what protects you. A system that could negotiate post-quantum key exchange and never does offers exactly as much protection against harvest-now-decrypt-later as one that cannot do it at all.
Put both readings side by side and the estate sorts into four states:
| What you find | What it means |
| Capable, and observed using it | Done. |
| Capable, but observed using classical crypto | Configured and never used |
| Not capable | Quantum-vulnerable |
| Capable, no traffic observed | Unproven. Not yet a claim you can make |
The second row is the one a capability-only tool cannot produce, and the one a migration program most needs, because it is the only state that looks like success and is not.
A coverage question sits underneath this as well. A scan reaches the systems someone thought to point it at, and only the connections coming in. The connections your systems make outbound—to payment processors, partner APIs, and your own internal services—are harder to scan, and an asset nobody added to a target list never appears in the inventory at all.
Four Questions for Your Current Tooling
- When a report says an endpoint is post-quantum ready, is that based on what the server offered a probe, or on a session that actually negotiated a post-quantum group?
- Can we tell the difference between an endpoint that offers no post-quantum group and one the tool could not read? If those produce the same output, one of them is wrong.
- What covers the outbound connections our systems make?
- How would an asset nobody installed an agent on, and nobody added to a scan target list, ever appear in our inventory?
The fourth one is usually the quietest and the hardest. Most estates have more of those than anyone expects, and they skew toward appliances, OT, and acquired infrastructure — exactly the assets that end up tiered most critical.
None of this makes active scanning wrong. A prober is the only thing that can enumerate a server’s preference list, and you need that list to know what to change. The point is that capability and use are two different measurements, and a program that reports only the first will keep declaring victory halfway through the work.
Where SafeLogic CPM Fits
SafeLogic CPM takes both measurements and correlates them onto the same asset. An active prober enumerates what an endpoint is configured to accept; passive observation records what production traffic actually negotiated. Because both readings attach to one record, an endpoint resolves to ready, fallback, or vulnerable — and fallback is shown as its own state rather than folded into ready, which is the entire point.
Coverage comes from multiple vantage points for the same reason. Agents on hosts, CI/CD pipelines, repository scans, imported SBOMs and CBOMs, third-party discovery feeds, and the passive sensor all feed one pipeline and collapse onto one asset record. An appliance nobody can install an agent on, and nobody thought to add to a scan list, still lands in the inventory when the sensor sees traffic to it.
With the deadlines in CNSA 2.0 and the federal guidance now close enough to plan against, the gap between “configured” and “in use” will start showing up in audits. It is worth finding it yourself first.
If you want to talk through what your current discovery can and cannot prove, our team is available for a PQC consultation.
