Post-quantum protected connections
ML-KEM-1024 key establishment and ML-DSA-87 endpoint authentication protect traffic inside the protected boundary. If required conditions cannot be held, protected traffic stops. There is no weaker fallback.
QShield · Protect
Protect the connection. Inspect the proof.
QShield protects the connection between systems with post-quantum key establishment and no classical fallback. The evidence behind each claim is published so a reviewer can check it.
Evidence statusPublished record
Verified
- Key establishment: ML-KEM-1024 (FIPS 203)
- Endpoint authentication: ML-DSA-87 (FIPS 204)
- Classical fallback: none
- Completed endurance run · two hosts, Oregon · finished 2026-09-16
- Three days. 4,107 checks. Zero failures.
- Locked post-quantum suite: ML-KEM-1024 key establishment, ML-DSA-87 signatures, AES-256-GCM between QShield nodes; locked profile, no classical fallback.
50-location demonstration — not yet established
- Application delivery: not yet qualified
- QRNG: unknown
- 72-hour record: not complete
- ATLAS / FIPS 140-3: not held
Static summary of the published record. Not live telemetry.
The decision
Which connections carry data that must stay confidential for years, and can they be protected now, before a full migration is complete?
Harvest now, decrypt later
Intellectual property, research, financial records and government communications often need to remain confidential long after transmission. Adversaries can record encrypted traffic today and hold it for decryption by a sufficiently capable quantum computer. Every month of delay adds to what is exposed.
For traffic inside its protected boundary, QShield by Qtonic Quantum uses ML-KEM-1024 instead of RSA or elliptic-curve key exchange to address harvest-now-decrypt-later exposure.
If required security conditions cannot be held, protected traffic stops. There is no weaker fallback.
QShield addresses that exposure for traffic routed through its protected path. A full post-quantum migration takes years. QShield lets an organization protect its most sensitive connections now, on the infrastructure it already runs, while that migration proceeds.
What this does and does not do
- Protects
- Connections between enrolled Linux hosts inside QShield's protected boundary (S29SP-1 packet protocol; ML-KEM-1024 / ML-DSA-87 / AES-256-GCM).
- Requires
- Linux hosts you already run, delivered through paid, operator-led engagements. Fail-closed: if required security conditions cannot be held, protected traffic stops.
- Does not
- Protect traffic outside the protected path, prevent an adversary from recording traffic, or recover data recorded before protection began.
- Not held
- ATLAS / FIPS 140-3, Government authorization, Department PKI, Department-approved MFA.
Guided product demonstration
Inspect the decision states, not a decorative dashboard.
Every frame is labeled by evidence state, explains the decision it supports, and links to the method or public sample behind it.
Published recordQSHIELD / 01
Completed endurance record
The sealed two-host run from September 13 to 16, 2026. Every check is in the published run log.
- Checks
- 4,107
- Failed checks
- 0
- Verifier
- 11 of 11 passed
Annotation: This record covers two Oregon hosts. It is not the 50-location demonstration and not a customer deployment.
Inspect the endurance evidenceQShield outcomes
Decide which connections to protect now, before the migration is complete
Keys stay on your endpoints
Private keys are held on the endpoints. No third party, including Qtonic Quantum Corp, has access to them.
Evidence you can inspect
Run logs, state receipts, a verifier, and a SHA-256 manifest are published, so a reviewer can check the record instead of trusting the page.
Why QShield
Post-quantum protection with evidence a reviewer can rerun
A completed 72-hour endurance run
Two Linux hosts in separate Oregon availability zones ran for 259,219 seconds between September 13 and 16, 2026: 4,107 checks, zero failures, and 11 of 11 verifier checks passed.
Inspect the endurance evidenceA 50-location demonstration, labeled as it stands
The 50-location network demonstration shows what is verified and what is not yet. Unverified states stay visible instead of being rounded up.
Inspect the networkSoftware only
The demonstrated configuration runs as software on Linux hosts, with no hardware changes. Endurance results apply to the identified build.
Operating method
Three steps to a scoped evaluation
- 01
Choose one connection
Bring a confidential transfer or a link between locations that matters to the mission or the business.
- 02
Define the evaluation
Your team and ours set the scope, key custody, and success criteria before anything runs.
- 03
Inspect the result
The evaluation is judged on evidence: logs, state receipts, and checks your team can rerun.
Proof receipt
The completed endurance run and its published record, claim to limitation
Bounded product truth. No customer telemetry in this public view.
- Claim
- QShield completed a 72-hour post-quantum endurance run with published evidence a reviewer can check.
- Scope
- Two AWS Linux hosts in separate Oregon availability zones, September 13 to 16, 2026; not the 50-location demonstration and not a customer deployment.
- Method
- Download the run log, state receipts, and verifier; rerun every check and compare the SHA-256 manifest.
- Artifact
- Run log · state receipts · verifier · SHA-256 manifest
- Freshness
- Sealed record: 2026-09-13 04:28:48 UTC to 2026-09-16 04:29:04 UTC.
- Status
- completed
- Limitation
- Results apply to the identified build. QShield is not represented as FIPS 140-3 validated or as holding Government authorization.
Governed intake
Evaluation is scoped, never self-serve.
Bring one connection that matters. Your team and ours define the scope, key custody, and success criteria before a guided evaluation begins.
Bring a confidential transfer or a link between locations. Evaluation terms are agreed with your team; nothing is self-serve.