Is your site post-quantum yet?
Check whether your HTTPS endpoint accepts hybrid post-quantum key exchange. Four live TLS probes return a score out of 90, findings and practical next steps.
Four live TLS handshakes, one header fetch, one DNS lookup. Read-only, about two seconds, nothing stored. 20 checks per hour per visitor.
What is checked
Post-quantum key exchange
A handshake offering only X25519MLKEM768 (FIPS 203 ML-KEM in a hybrid with X25519). Success confirms hybrid support for this probe, not every visitor connection. 50 of 90 points.
Classical compatibility
A handshake offering only TLS 1.2. Acceptance means classical connections are possible. A timeout is inconclusive; TLS 1.3 can also use classical groups.
Transport hygiene
HSTS strength, certificate validity and trust chain, CAA records. Supporting transport checks, separate from post-quantum key exchange.
Agent economy angle
If the host publishes an x402 manifest, the report records its presence. Payment-header protection still depends on each client connection.
FAQ
- What does this check measure?
- It tests whether one resolved HTTPS address accepts X25519MLKEM768, a hybrid of classical X25519 and post-quantum ML-KEM, plus pure ML-KEM and classical handshakes. A successful probe establishes support on that connection. It does not prove every visitor uses it.
- What is harvest-now-decrypt-later?
- An attacker can record encrypted traffic now and try to decrypt it with a future cryptographically relevant quantum computer. Hybrid key exchange is designed to address that risk for sessions that negotiate it. The report cannot observe what other clients negotiated.
- Does TLS 1.3 mean post-quantum?
- No. TLS 1.3 also supports classical key exchange. The group actually negotiated matters. TLS 1.2 acceptance is reported separately; it is not proof that an attacker can force a modern client to downgrade.
- Does this test the origin behind my CDN?
- It tests the address reached for the hostname you enter, usually the CDN edge. The edge-to-origin connection is separate and is not assessed by this result.
- How do I enable hybrid key exchange?
- Check your CDN or TLS library documentation for X25519MLKEM768 support. OpenSSL 3.5 includes it in its default group list. For nginx built against a supporting OpenSSL version, configure ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; and verify the result after reloading.
- What does the score mean?
- It is a ForgeMesh heuristic out of 90, combining tested key-exchange support and transport hygiene. Ten additional points are reserved but not awarded because certificate signatures are not assessed. This is not a compliance rating, certification or percentage of security.
- Can an agent use it?
- POST https://x402.forgemesh.io/quantum-readiness with {"domain":"example.com"}. The Utility Grid route costs $0.05 per call and returns structured findings, per-check points and remediation. An unpaid request returns the payment challenge.
How ForgeMesh itself is set up is on the security page: our edge supports ML-KEM hybrid; each client must negotiate it.
Developers and agents
The same probe as an API: POST x402.forgemesh.io/quantum-readiness with a domain, $0.05 per call in USDC over x402 or MPP, no account or API key. Full findings, per-check points and remediation as JSON, for readiness audits and fleet sweeps.
Utility Grid routeThis check reads TLS handshake parameters and public headers only. It does not test certificate chains for revocation, scan ports, or make any claim about payments or wallets being quantum-safe. The result covers one resolved address at one moment. It does not assess other clients, other PQ groups, stored data, origin connections or compliance. Re-check after server or CDN changes.