01 / SEE THE PRODUCT
One “ready” label
misses the difference.
A TLS result belongs to a connection, not just a server. Compare the clients, see the negotiated group, and understand the next step.
◇ Illustrative example · not a live scan
NEGOTIATED KEY EXCHANGE
Post-quantum
X25519MLKEM768
The client offers a hybrid group that this example server accepts. The connection negotiates post-quantum key exchange.
This client is covered. Check the other profiles before drawing a conclusion about your whole environment.
The same host can produce all of these outcomes. The client’s offer matters.
Inspect the methodology ↗02 / UNDERSTAND THE GAP
From a failed match
to a useful fix.
A capable server is only half the story. The client must offer a group the server accepts. When those don’t line up, Keyzra explains where to look.
- 01
Read the offer
Which groups does this client’s TLS stack and policy allow?
- 02
Compare the response
What did the server accept, refuse, or negotiate instead?
- 03
Identify the change
Find whether the next step belongs to the client, server configuration, or provider.
No shared post-quantum group. A classical connection can still succeed. The fallback may be silent.
Conceptual explanation. Group A and Group B are illustrative labels.
03 / GO BEYOND ONE HOST
The public check is
your starting point.
For an ongoing migration, follow changes across your estate, test the systems you actually run, and keep the records. These capabilities are offered through early access.
Illustrative environment · no customer data
MONITORING
Catch the change.
Follow hosts over time. Route alerts to the tools your team already uses.
Explore monitoring ↗CLIENT REPLAY
Bring your real clients.
Use the TLS offers from systems you actually run, beyond the standard scan profiles.
How client replay works ↗OUTBOUND CONNECTIONS
Look from the inside, too.
Understand what your systems negotiate when they connect to services and APIs.
Explore outbound analysis ↗
04 / KEEP THE EVIDENCE
A result you can
take apart.
A claim is more useful when someone else can check it. Keyzra signs measurement records so their integrity can be verified independently.
A valid signature verifies the record. It does not, by itself, certify that your system meets a compliance requirement.
See how to verify a record ↗05 / PUBLIC RESEARCH
The difference
is measurable.
Across the same U.S. federal hosts, the negotiated outcome changed sharply with the client profile.
Read the federal report ↗measured 9 November 2026
Source: Keyzra’s published federal measurements. 9 November 2026 · EU–Frankfurt vantage point. A dated snapshot, not a verdict on your domain.
Scope & methodology ↗06 / BEFORE YOU CHECK
The useful
distinctions.
Know exactly what a measurement can tell you—and what it cannot.
Read the full methodology ↗What does “post-quantum” mean in a result?
The tested client and server negotiated post-quantum key exchange in that TLS handshake. It does not mean every part of your system is quantum-safe, or that every client gets the same outcome.
Why might a FIPS client get a different answer?
TLS stacks and policies offer different cryptographic groups. A server might accept a browser’s hybrid group but not the one a particular FIPS configuration offers. FIPS mode alone does not determine the outcome.
What is included in the free check?
One host, four client classes, and nine handshakes. Monitoring, client replay, and audit exports are advertised as early-access capabilities. See the current plans ↗
Is signed evidence the same as compliance?
No. A signature helps verify a record’s integrity and origin. Compliance depends on your requirements and the wider system. Measurement evidence is an input to that assessment.
Can I inspect how Keyzra measures a host?
Yes. Read the published methodology and scanning policy for test scope and operational details. Read the scanning policy ↗
START WITH ONE DOMAIN
Run the check.
See the difference.
Find out what your clients actually negotiate.
