What does PQ TLS ready mean?

It means the tested HTTPS edge accepted the RFC 10024 X25519MLKEM768 hybrid TLS 1.3 key-exchange group and its ordinary certificate path verified. It does not certify every part of the website as post-quantum.

Yes. Ten successful checks per identity are included each UTC day. Additional authenticated calls cost 5 sats.

What does the checker test?

It performs separate TLS handshakes for X25519MLKEM768, classical X25519 compatibility, and ordinary certificate verification against one public IPv4 HTTPS edge on port 443.

RFC 10024 live check

Is your website ready for post-quantum TLS?

Test a public HTTPS edge for the RFC 10024 hybrid of X25519 and ML-KEM-768. Get a verdict, grade, evidence, and next steps.

10 included checks / dayNo account requiredNo page content fetchedThen 5 sats / call

Check a domain

Three TLS handshakes · one clear report

10 FREE DAILY

Hostname only · public HTTPS on port 443 · no page content fetched · API example

—

0 / 100

WAITING

Result

Checks

Recommended next steps

What the result means

A focused TLS readiness signal.

The checker separates the part that is post-quantum today from the parts that are not. A passing result means hybrid protection for TLS 1.3 ephemeral key establishment—not a blanket claim that an entire website, certificate, database, or backend is quantum-safe.

01 · HYBRID

X25519MLKEM768

Offers only RFC 10024 group 4588. A successful handshake proves the tested edge supports hybrid X25519 plus ML-KEM-768 key establishment.

02 · VERIFY

Ordinary HTTPS

Performs a normal verified handshake to check the certificate name, chain, validity, negotiated protocol, and real client path.

03 · COMPATIBILITY

Classical X25519

Offers only X25519 to confirm current clients can still connect while the post-quantum transition rolls out.

90–100

PQ-TLS ready: hybrid, verified HTTPS, TLS 1.3, and fallback passed.

75–89

Hybrid detected with one secondary TLS or certificate gap.

60–74

Hybrid detected, but important HTTPS or compatibility work remains.

40–59

Usable classical HTTPS, but no hybrid post-quantum TLS.

0–39

No hybrid support plus other readiness gaps, or no reachable target.

Agent + developer API

The same report as structured JSON.

The first 10 successful calls per identity each UTC day are included. No Authorization header is needed. After that, funded Bearer sessions and Ark-402 signed credit continue at 5 sats per successful call.

curl -sS https://arkapi.dev/api/post-quantum-check \
  -H 'Content-Type: application/json' \
  -d '{"domain":"example.com"}' | jq

VERDICT

Machine-readable answer

pq_tls_ready, verdict, grade, and score give agents a fast decision path.

EVIDENCE

Transparent scoring

The 100-point breakdown is explicit: hybrid key exchange 60, certificate 15, TLS 1.3 15, and X25519 fallback 10.

DISCOVERY

OpenAPI + MCP

Discover the operation through OpenAPI, the live catalog, or the ArkAPI MCP client.

The standards

A new interoperable TLS building block.

Published August 2026

RFC 10024

Defines hybrid ECDHE-MLKEM key agreement groups for TLS 1.3, including X25519MLKEM768 at codepoint 4588.

NIST standard

FIPS 203

Standardizes ML-KEM, the post-quantum key-encapsulation mechanism used by the hybrid TLS group.

Important scope: Hybrid key establishment helps address “harvest now, decrypt later” risk for new TLS sessions. Most public certificate authentication remains classical today. This report is a point-in-time check of one IPv4 HTTPS edge on TCP 443; it does not test HTTP/3, every CDN edge, origin infrastructure, application code, stored data, or backups.