Claims we refuse to make

This industry has a credibility problem, and it is self-inflicted. The genuine argument for post-quantum migration is strong enough to stand on published standards and simple arithmetic. It gets buried under countdown clocks, invented statistics and claims of certainty that nobody possesses. This page lists what Theos Quantum will not assert. It is written to be quoted back at us.

#Why we publish this

Two reasons, one principled and one practical. The principled reason is that a security vendor that overstates a threat has no standing to be trusted on the measurement of it. The practical reason is that our buyers are risk, audit and engineering functions who will check. A claim that fails scrutiny in a procurement review costs more than it ever earned in a campaign.

The list below is a standard we hold ourselves to across the website, the platform, our reports and anything a member of our team says in a meeting. It applies to language as well as substance. If a sentence would only work because it frightened the reader, it does not ship.

#Claims about timing

#We do not name a date for a cryptographically relevant quantum computer

Why not: no one knows it. Expert opinion is a distribution with a wide spread, and it shifts as hardware engineering and cryptanalysis advance. Publishing a single date claims knowledge that does not exist, and it makes the argument fragile. If the date passes without incident, every organisation that planned against it concludes the whole field was overstated.

What we say instead: we treat expert-survey results as ranges, we cite the standards deadlines that are genuinely dated, and we run the timing arithmetic across a range of assumptions rather than one. The method is set out in The migration window, with the arithmetic.

#We do not use a countdown clock as a sales device

Why not: a ticking number engineers a purchasing decision through discomfort rather than analysis. It also invites the reasonable objection that the clock is set to whatever suits the vendor. Neither outcome helps a buyer who has to defend the spend internally.

What we say instead: the Quantum Window tracks progress against published standards deadlines and states its start and end points and its sources on the page. It measures a policy schedule. It is not a prediction of when hardware arrives, and we do not describe it as one.

#Claims about capability

#We do not claim a machine capable of breaking RSA-2048 exists today

Why not: because as far as anyone can publicly establish, it does not. Announced physical qubit counts remain far below the error-corrected logical resources that published resource estimates call for, and those estimates themselves carry large assumption-dependent uncertainty. Asserting the capability exists would be false, and it is also unnecessary: harvest now, decrypt later works precisely because the adversary does not need the machine yet.

What we say instead: we describe resource estimates as estimates, name the assumptions they depend on, and mark figures we have not verified with a source as placeholders rather than filling them with plausible numbers. See What a quantum computer actually breaks.

#We do not say quantum computing breaks all encryption

Why not: it is wrong, and a technically literate reader knows it is wrong within one sentence. Grover’s algorithm gives at best a quadratic speed-up against symmetric primitives, which is why AES-256 and SHA-384 remain appropriate selections and why CNSA 2.0 continues to specify them.

What we say instead: we separate the asymmetric column, where the break is structural, from the symmetric column, where the correct response is a parameter change. Conflating the two inflates the apparent scope of the migration and wastes budget on work that is not needed.

#Claims about you

#We do not tell you your data has definitely been harvested

Why not: we cannot know, and neither can anyone else selling you something. Passive interception leaves no artefact on the target side. There is no log entry to produce and no forensic trace to find, which means the claim is unfalsifiable in both directions. Asserting it as fact is a scare tactic dressed as intelligence.

What we say instead: capture cannot be proved or disproved, so the decision rests on the asymmetry between the cost of migrating unnecessarily and the cost of not migrating when capture did occur. That asymmetry is laid out in Harvest now, decrypt later.

#We do not invent breach statistics or financial impact figures

Why not: unsourced numbers are the easiest thing to check and the fastest way to lose a technical audience. There is no credible public dataset of quantum-enabled decryption incidents, because there are no confirmed public incidents to count. Any percentage or currency figure presented as the cost of quantum risk is, at present, constructed.

What we say instead: we cite our own pilot measurements and label them as one estate. That estate produced 42 discovered cryptographic assets, 36 classified vulnerable, an aggregate risk score of 75 / 100, a review time of 22 hours by hand against 14 minutes on the platform, 95.2% classification accuracy and 0.94 macro-F1 on the labelled evaluation set. Those are the only performance figures we quote. Where a figure is not ours, we point to a public source such as CISA’s Known Exploited Vulnerabilities catalogue or the GitHub Advisory Database, and where we do not have one we leave a visible placeholder.

#Claims about us

#We do not claim our platform makes an organisation quantum-safe

Why not: it is not true, and the phrase itself does not survive scrutiny. AutoPQC discovers cryptography, scores exposure, maps findings to NIST FIPS 203, 204 and 205, prioritises remediation with explainable models, and measures the performance impact of a proposed change. Every one of those is an input to a migration. None of them is the migration. Your posture changes when a system stops negotiating a vulnerable key exchange, and that change happens in your infrastructure, on your change calendar.

What we say instead: we describe our contribution precisely, and we publish where it ends. Discovery has documented blind spots, classification has a measured error rate, and both are stated rather than implied. See What discovery will not do and Accuracy, false positives, and how we report error.

#We do not describe features we have not built

Why not: a demonstration that does not match the product is the fastest way to lose an enterprise account, and the discovery usually happens after contract. It also corrodes everything else on the page, because a reader who finds one imagined feature reasonably assumes there are others.

What we say instead: unreleased work is labelled roadmap wherever it appears. Numbers we do not yet hold, including certification dates and audit details, appear as explicit placeholders that a reader can see. Our versioning discipline for the scoring method is described in How the method is versioned.

#Holding us to it

A standard nobody can check is a slogan. These are the mechanisms that make this one checkable.

• Every scoring input, weight and threshold is published, so a finding can be recomputed independently. See Reproducing our numbers.
• Method changes are versioned and dated, and reports carry the version that produced them.
• Classification error is reported as a measured figure on a stated evaluation set, not as a marketing claim of accuracy.
• Scope boundaries appear inside the relevant article rather than in a disclaimer nobody reads. That is what the “Out of scope” panels are for.
• Placeholders are left visible in draft content instead of being filled with plausible values.

If you find a claim on this site that breaches the standard above, tell us and we will correct the page. Report it through Security & Disclosure if it concerns a security assertion, or Contact for anything else. Corrections are recorded in the Signal Log.