On this page
Methodology & Proof Points
Our methodology combines automated discovery, provider-aligned workflow validation, and expert analysis to uncover cryptographic vulnerabilities and quantify their business impact.
~24 min readMethodology claims are governed by a live claim registry, review requirements for qualifying zero-critical challenge outcomes, and release evidence for public QStrike statements.
Key Takeaway:Our methodology uses multi-level analysis to compute a scenario-weighted “Board Number” risk metric. Public QStrike materials are limited to provider-aligned workflow profiles, release-verified modeled runtime statements, and governed claim-registry wording. Buyer-facing claims stay mapped to NIST IR 8547, CNSA 2.0, OMB M-23-02, NSM-10, and EO 14028 requirements.
1. Board-Level Risk Modeling (“Board Number”)
We provide a scenario-weighted exposure model that translates technical findings into a single board-ready risk metric. This model incorporates the likelihood of a cryptographically-induced breach (accounting for emerging quantum capabilities) and the business impact of such a breach. Our assessment engine combines passive, authenticated, and quantum-specific analysis to compute this risk in financial terms.
How the score works
- • Quantum Exposure Window: Time-to-CRQC scenario model, sourced from Global Risk Institute expert-elicitation data and normalized to Qtonic Quantum's 2029 readiness/control planning horizon
- • Loss equation: Expected Loss = Σ (Asset Classi) × P(CRQC within window) × Exposurei × Residual Control Factori
- • Present value: Discounted at customer-configurable rate, with both undiscounted (risk appetite) and discounted (NPV) views provided
- • Quantum Exposure Score (0-100): Normalized composite derived from expected loss and confidence bounds
A typical engagement might reveal catastrophic, irreversible data exposure due to quantum-vulnerable encryption inside the client's retention window — a level of risk that exceeds any reasonable appetite. By quantifying exposure in dollars and scenario impact, boards can act on math, not fear.
All assumptions (asset value, threat timelines, discount rates) and intermediate calculations are documented so the math survives audit scrutiny. Breach cost baseline: $4.88M global average (IBM/Ponemon 2024). Regulatory timeline: NIST IR 8547 deprecation path through 2035; OMB M-23-02 federal mandate. Cryptographic Debt analysis methodology informed by Federal Reserve research (2025) and G7 Cyber Expert Group roadmap.
2. Validation Workflows
When analysis flags a potential weakness exploitable by a quantum adversary, public materials stay at the provider-aligned workflow level. Scoped customer engagements determine when hardware-backed validation is used and what provider evidence is included in the final report.
Evidence included in reports
- • Provider job artifacts: Backend name, job ID (or hash + verification method), timestamp, qubit count, circuit depth, shot count, result metadata
- • Circuit evidence: Diagram screenshots and/or exported OpenQASM format with sensitive labels removed
- • Console screenshots: Per-provider showing backend, job ID, and completion status
- • Integrity controls: Published hashes of evidence files for post-engagement verification
- • Reproducibility: “Run these same circuits” appendix for review
Public materials describe provider-aligned workflow validation and release evidence. Scoped customer engagements determine when hardware-backed validation is used, and those artifacts are included in customer reports when the scope requires them.
3. Deliverables & Sample Reports
QScout public intake Snapshot + Governed Follow-Up Scope
- • Executive summary with Quantum Exposure Score and exposure window
- • Browser-safe public-surface signal summary
- • CBOM priority inputs for governed follow-up scope
- • TLS and certificate observations
- • Prioritized migration inputs for the next execution step
- • Governed exports only when scoped and approved
- • Board-ready recommendations mapped to compliance frameworks
QStrike Scoped Validation Pack (90-120 day testing)
- • Executive summary with exploitation narrative
- • Proof-of-concept evidence for key vulnerabilities
- • Complete CBOM mapping with dependency impact
- • Quantum hardware job artifacts and circuit evidence
- • Screenshots of sensitive material found (e.g. key fragments in memory)
- • Migration governance handoff notes for QSolve
- • Re-test validation after remediation
What we do not include in samples: No private keys, no customer traffic, no internal hostnames, no sensitive architecture diagrams.
Governed QScout follow-up can produce a CycloneDX 1.7 Cryptographic Bill of Materials with machine-readable quantum risk classification. QScout public intake remains a browser-safe executive snapshot; raw enterprise artifacts and signed delivery require approved scope.
View Technical Documentation
Request Full Sample Deliverables
Redacted sample materials with Board Number calculation, CBOM excerpts, and scoped-validation evidence are available upon request. Sample materials are sanitized before buyer review and exclude customer identifiers, private keys, and internal network details.
Open complete methodology reference
4. Validation & External Review
Governed validation artifacts remain available for procurement and audit review. Public references are anonymized and normalized for release.
Validation structure
- • Historical validation: An anonymized client validation record with governed claim mapping and checksums
- • $2M QStrike Challenge review: Zero-critical outcomes still require third-party review before any payout
- • Challenge governance: Signed challenge terms define review, payout eligibility, and the annual program cap for zero-critical outcomes
- • Standards alignment: Methodology is maintained against current NIST PQC standards (FIPS 203, 204, 205) and transition guidance
Public proof: Public diligence summaries describe governed engagement patterns. Buyer identifiers are removed, sensitive details are normalized, and public metrics are banded before release so procurement teams can assess outcomes without exposing protected environments.
- • Derived from governed engagement evidence
- • Normalized and rounded for controlled public release
- • Aligned to delivered outcomes without reproducing protected buyer reports
Buyer-facing validation language is now tied to the governed claim registry. If a proof pack or review statement is not live in the registry, it should not appear in product or buyer materials.
6. Quantum Proof-of-Work Finding
Each engagement includes at least one deep-dive finding showing how a quantum-relevant attack path could succeed given a specific vulnerability. We do not claim that today's public hardware can trivially break strong crypto like RSA-2048 on its own. Instead, we focus on scenarios where a classical weakness materially reduces problem complexity and then document the validation path used in the engagement.
Example: Ephemeral key leak + quantum factorization
- Classical analysis discovers partial RSA private key fragments in debug logs (ephemeral key leak)
- Leaked bits reduce RSA-2048 factorization from computationally infeasible to achievable within hours
- Provider-aligned workflow evidence is gathered for the reduced-strength exploit path defined in scope
- Customer report records the observed result, confidence notes, and reproduction constraints for reviewer follow-up
- Report includes quantum circuit details, output evidence, and scaling limitations
What we claim: Classical techniques find the vulnerability. Scoped validation records how the exploit path was assessed and what evidence was captured for the client report. This gives clients a concrete proof trail for the most critical quantum-relevant weakness in their environment.
Current public quantum hardware cannot break production RSA-2048 wholesale. Our methodology documents exploit mechanics where classical shortcuts (key leaks, weak entropy, implementation flaws) materially reduce problem complexity, and the engagement report records what validation path was actually used.
7. PQC in Production: Verified Implementations
The public record on PQC migrations is thin but growing. Most organizations treat these projects as competitive intelligence. These verified implementations prove PQC works in production — and reveal the real challenges enterprises face.
Technology
Cloudflare
Hybrid X25519+Kyber on all edge servers (Oct 2022). By March 2025, 38% of HTTPS traffic encrypted with PQC algorithms (Cloudflare Radar). Encountered middlebox failures after Chrome 124 release.
Apple (iMessage PQ3)
PQ3 deployed March 2024. Combines post-quantum initial key establishment with three ongoing ratchets. Formally verified with ETH Zürich's Tamarin tool.
Google Chrome
X25519Kyber768 enabled by default in Chrome 124 (April 2024). Reported 4% TLS handshake slowdown from additional 1.1-1.2kB per direction (Google, 2024).
AWS
ML-KEM for hybrid PQC key agreement deployed across KMS, Secrets Manager, and Certificate Manager in all regions (non-FIPS endpoints).
Financial Services
JPMorgan Chase
Implemented quantum-secured crypto-agile network (Q-CAN) connecting two data centers. Third quantum node established as research platform. Uses both PQC and QKD as layered defense.
HSBC + Quantinuum
Production PQC-VPN tunnel in gold tokenization environment. Observed minimal performance impact irrespective of data size. Demonstrated PQC can protect DLT without re-architecture.
Documented Challenges
- • Middlebox failures: Devices that don't correctly implement TLS malfunction when offered PQC options (Cloudflare/Chrome 124)
- • Handshake overhead: 4% TLS slowdown from larger key exchanges (Google)
- • Hybrid maintenance: 20-40% additional staff time for dual-algorithm management (MDPI research)
- • Timeline reality: 5-7 years for small enterprises, 8-12 for medium, 12-15+ for large (baseline estimates)
What remains missing:No enterprise has published a complete end-to-end migration with costs, timelines, and lessons learned. That gap is where QSolve operates — providing the migration governance, sequencing discipline, and standards-mapped execution structure that turn proof-of-concepts into production deployments.
Redacted sample reports, third-party review letters, and tool comparison data available under NDA.
9. Public-to-Private Proof Path
Qtonic Quantum runs two surfaces with one truth contract. The public surface (Lab registry, QScout approved-scope executive signal, published methodology) renders against published artifacts and published proof metadata. The private surface (governed QScout engagement, QStrike validation) operates on customer evidence under engagement-specific access. The progression from public Lab signal to private engagement evidence is what we call the public-to-private proof path.
Levels
- • QScout public intake (public, /qscout): Executive snapshot rendered against the public truth contract. No customer data, no scoped evidence. Business-email verified, browser-safe, and typically completed in minutes.
- • QLab (public, /lab): Independently scored PQC implementations across a published 10-dimension rubric. Source: vendor evidence, public artifacts, expert ground truth. No customer data.
- • QScout governed scope (governed): Scoped engagement against a customer environment. Provider-aligned validation, structured evidence collection, contract-bound delivery.
- • QStrike (governed validation): Quantum-resistance validation with governed proof artifacts and reproducible verification through the published proof engine.
Evidence Handshake
The Evidence Handshake is the deterministic binding between the public Lab registry and the governed QStrike evidence ledger. When a public Lab score advances to a governed engagement claim, the handshake binds:
- • The public solution_id and its rubric provenance state (verified, contested, inferred, degraded)
- • The signed bundle hash of the source dataset used to render the score
- • The scoped engagement_id and the contract that authorizes the evidence elevation
- • The signing identity of the verifier and the timestamp of the handshake event
Every artifact released under the public-to-private proof path carries a content hash that customers can verify against the live trust feed at /trust. The lab proof health endpoint exposes the current registry state at /lab.
Public surface uses No customer data
Everything visible on qtonicquantum.com is rendered against published artifacts: the Lab registry, the QScout truth contract, the methodology rubric, and signed proof bundles. Customer evidence stays in the governed engagement boundary and is not transmitted to public surfaces.