QStrike known gaps
We publish what we don’t yet have. Honesty is part of the methodology.
Why we publish gaps
Most security vendors maintain a marketing posture that asserts capability uniformly. The post-quantum cryptography category is too young and too consequential for that posture. We’re explicit about what’s bounded, what’s pending, and what’s deliberately out of scope.
Buyers benefit from knowing the boundary; we benefit from not over-promising; the field benefits from honest comparison. A gap published is a gap a buyer can plan around. A gap hidden is a surprise during deployment.
The list below is the public-safe view of the engineering KNOWN_GAPS.md maintained in the qstrike-engine repository. Every item is a real boundary we’ve accepted, not aspirational language softened into a roadmap.
Capability boundaries
Public-safe QStrike platform boundaries are named, dated by status, and closed only when we ship the work.
Today QStrike runs Shor’s at N=15, N=21, and N=143 (25-qubit implementation) on calibrated provider profiles. These prove algorithm correctness; they do not break production-strength keys. Larger Shor-N requires hardware QStrike does not yet have access to — when it becomes available, we will integrate it.
QStrike’s representative engagement bundle uses fictional-illustrative entities (Acme Bank, etc.) clearly labeled as such. Real-customer engagements run under SOW with confidentiality controls and are not in the public surface. As anonymized engagements complete, we publish what’s permitted.
Today, every SSE event envelope is signed ECDSA-P256-SHA256 — verifiable per-event via /qstrike/verify. The per-bundle attestation chain (engine code hash + per-provider job IDs + calibration snapshots, all cryptographically chained) is shipping in the next release. Until then, per-event signing is the verifiable surface.
A reference Python verifier (verify_gates.py) and a copy-paste openssl flow at /qstrike/verify are available today. The npm-published CLI (@qtonicquantum/qstrike-verify) is shipping in the next release alongside the per-bundle attestation chain (they pair).
Our SLO target for /api/health is 99.9 percent on a 30-day rolling window. The synthetic monitor that produces measured numbers is scaffolded in ops/synthetic-monitor/ but not yet deployed to Cloudflare Workers. Once deployed, measured uptime will be published at /trust/slo.json and surfaced on /status.
Today’s typical engagement workload mix is approximately 92 percent Intelligence Model reasoning plus 8 percent quantum-cloud-executed cryptanalytic probing. Real-hardware execution scales with engagement scope. We don’t claim "all 8 providers run on every engagement" because that’s not how the work is structured.
Of the 8 platforms in our reference set, Xanadu is currently inactive — calibrated profile is maintained for future activation. The other 7 platforms have credentialed access paths.
BAS tools execute in minutes; QStrike engagements span 30 to 120 days because the capture window is days-to-weeks by design. Our "real-time" claim is per-finding signed proof within minutes of validation completion — not engagement initiation.
Explicitly out of scope
These are not gaps that will close on a schedule. They are claims we will not make on a public marketing surface, by policy.
Until SOW plus explicit permission. Anonymized engagement summaries are published as they become permitted.
The hardware that would make this an honest claim does not exist commercially as of May 2026. We will not stage a misleading demonstration.
We sign with ECDSA-P256-SHA256 today. ML-DSA migration follows the published CNSA 2.0 sequence and is not deployed on the production signing path.
Until legal ships an underwriting attestation. No public dollar-figure guarantee, full stop.
How this list updates
If a competing vendor publishes a similar list, the field improves. If they don’t, you have a comparison surface they declined to provide.
Leave an address below to be notified as items on this page move from in-flight to shipped. We’ll also send a note when a new boundary is added — disclosure flows both directions.
Prefer to read the methodology first? /qstrike/methodology
Forward-threat validation with provider-aligned platform profiles and engagement-tied performance commitments documented in SOW.
ExploreVerified executive snapshot and primary entry point for cryptographic risk assessment.
ExplorePQC migration planning with CISO-led engagements.
ExploreShared intelligence model, delivery rigor, and suite architecture across Qtonic Quantum products.
Explore