Our Position

AutoPQC reads the estate you nominate rather than the inventory you believe you have. Source trees and dependency manifests, build and release chains, configuration as deployed rather than as documented, certificate stores, and the key stores that hold the material behind all of it. Out of that comes a list of cryptographic assets, each one recorded with where it was found and what evidence supports its classification.

Every discovered asset is then scored under a published, versioned method along five dimensions: Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. Findings are mapped to NIST FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA), sequenced into a remediation order a change board can argue with, and paired with a measurement of what the proposed change does to latency, throughput and handshake size on your own traffic.

One estate has been run end to end. In that pilot the platform discovered 42 cryptographic assets, classified 36 of them vulnerable, and produced an aggregate estate score of 75 / 100, which places it in the Elevated tier. The per-asset distribution was Acute 13, Elevated 16, Watch 7, Contained 6. The same review took 22 hours by hand against 14 minutes on the platform, and classification measured 95.2% accuracy with a 0.94 macro-F1 on the labelled evaluation set. Those are the only performance figures we quote anywhere, and they describe one estate rather than a population.

What that adds up to is an input to a migration, not the migration. We do not operate your infrastructure, we do not push changes into it, and we do not certify the result. Your posture changes on the day a system stops negotiating a vulnerable key exchange, and that day sits on your change calendar rather than ours.

We do not name a date. There is no defensible arrival date for a cryptographically relevant quantum computer, so we publish none, and we do not run a clock towards one on any page. Where timing has to be discussed we work from ranges in published expert surveys, from the regulatory deadlines that genuinely carry dates, and from the Mosca inequality applied to the reader’s own inputs at the Quantum Window. A ticking figure engineers a decision through discomfort, and it invites the fair objection that the vendor set the clock.

We do not overstate what exists or what has already happened to you. No machine capable of breaking RSA-2048 is publicly established to exist, and we will not imply otherwise. Quantum computing does not end all encryption, and a reader who works in this field knows that within a sentence. Nor will we tell you your traffic has been harvested, because passive interception leaves nothing on your side to find; the case rests on that asymmetry rather than on an assertion nobody can test in either direction.

We do not manufacture numbers. There is no credible public count of quantum-enabled decryption incidents, so any percentage or currency figure offered as the cost of quantum risk has been constructed. Where a figure is not ours we name a public source anyone can open, such as CISA’s Known Exploited Vulnerabilities catalogue, the NVD or the GitHub Advisory Database. Where we do not have one, a visible placeholder stays in the page.

We do not claim the platform makes an organisation quantum-safe, and we do not demonstrate capabilities we have not built. Unreleased work is labelled as roadmap in the same sentence that introduces it rather than in a footnote. Each of these refusals is set out claim by claim, with the reasoning and the substitute wording, in the article below. Section 6 of this page describes how to hold us to it.

The scoring rules are public. The five dimensions, the fixed weight carried by each, the anchor rubric that turns an observation into a sub-score, the combination formula, the override that stops a fragile primitive being averaged away, and the four tier boundaries are all on The Theos Method rather than held back for a briefing. That page owns those figures. We do not restate a weight anywhere else on the site, because the same number written in two places eventually becomes two different numbers.

Publication changes the shape of a disagreement, which is the point. A reviewer who thinks a finding is wrong can name the dimension that produced it and argue about that, instead of being left to accept or reject an opaque total. Several early corrections to our own rubric arrived exactly that way. A method that cannot be contested cannot be improved.

The method carries a version, theos-method-v1.0, published 2026-07-27, and every finding, report and attestation is stamped with the version that produced it. Scores computed under an earlier version are not silently rewritten when the rules change. A change that only adds detection is a minor version; a change that moves an existing score is a major version, and a major version does not arrive without notice.

The honest limit on all of this is track record. Two versions have been published, so the versioning policy has been exercised rather than proven across years of releases. Judge it again after the next one ships. [PLACEHOLDER: next method version and target publication date]

Discovery works on metadata about cryptography, not on the secrets that cryptography protects. We look at which algorithm a key uses, what size it is, which store holds it, when it expires and which custody boundary it sits inside. None of that requires the key material itself, and we do not want a copy of it. The same applies to production credentials, administrative sessions and anything that would let us act inside your estate rather than read a description of it.

What we do ask for is narrow and named in advance: read access to the repositories in scope, dependency manifests, exported configuration, certificate and key inventory metadata, and a named engineering contact who can confirm what a finding actually means. If we can answer a question from an export instead of from live access, we take the export. If a surface cannot be covered without credentials we will not hold, we mark it as out of scope in the report rather than quietly widening the access request.

Customer material is held only for as long as the engagement and its evidence trail require, and then removed on a stated schedule. We are not publishing an interval on this page that we have not committed to contractually. [PLACEHOLDER: retention period for engagement material, and the deletion path a customer can invoke]

Business terms are separate from this and are handled where they belong. Our security disclosure policy, in-scope surfaces and reporting route are published at Security & Disclosure, and the data questions an assessor will ask are answered in the article below rather than summarised loosely here.

We have no customers to name. Not redacted, not anonymised, not described as a large European bank. There are no logos on this site, no case studies, no testimonials and no quotations attributed to anyone outside the company, because there is nobody yet to attribute them to. When that changes it will change with a named reference who agreed to be named. [PLACEHOLDER: first referenceable customer, and the date they agreed to be cited]

We hold no third-party audit and no certification. There is no SOC 2 report, no ISO 27001 certificate and no independent assessment of the platform or the method to point you at. The Assurance Center describes the controls we operate and marks each of these gaps as a gap. [PLACEHOLDER: audit or certification scope, assessing firm, and target report date]

We publish no availability figures and no price list. Uptime is not measured across a period long enough to state, so no percentage appears anywhere on the site. Commercial terms are set per engagement and every price on the site is a placeholder, which is deliberate: an invented number that a buyer later has to unwind is worse than an open question. [PLACEHOLDER: commercial model and indicative engagement pricing]

Our evidence base is one pilot estate, and the figures in section 1 describe that estate rather than a benchmark. Discovery has documented blind spots. Classification has a measured error rate that we report as a measurement rather than as a claim of accuracy. Capabilities on the roadmap, including the Continuum programme interface, are not generally available and are labelled as roadmap wherever they appear. [PLACEHOLDER: Continuum general-availability target date]

If a question matters to your decision and this page does not answer it, ask us directly through Contact and we will either answer it or tell you that we cannot yet. A pre-revenue vendor that pretends otherwise is telling you something about how it will behave later.

Start with The Theos Method. It carries the full specification of the exposure score: the five dimensions named in section 1, the weight each one carries, the anchor rubric, the combination formula, the tier boundaries, and the arithmetic that produces the pilot estate’s aggregate from the per-asset scores beneath it. The method is versioned as theos-method-v1.0 and was published on 2026-07-27. Its revision history is on the same page, so a reader can see what changed and when.

Then recompute something. The article below walks through re-deriving our published figures from the inputs, including the estate roll-up, and states which steps you can reproduce independently and which depend on data only the customer holds. If a number on this site does not fall out of the published rules, that is a defect and we would rather hear about it from you than not hear about it.

For a specific report, use Attestation Lookup. A Posture Attestation carries the method version that produced it, and the lookup confirms whether a given attestation was issued by us and what it covers. It is not a compliance certificate and we do not describe it as one; it is a record of what was assessed, under which rules, on which date.

Corrections are recorded rather than absorbed. If you find a claim on this site that breaches the standard in section 2, report a security assertion through Security & Disclosure and anything else through Contact. Changes to the site, the method and the platform are logged in the Signal Log, which means a reader can check whether a correction we accepted actually shipped.