The inputs, the weights, and where they come from
Every input to the exposure score, the anchor rubric that turns it into a number, its provenance class, and how the five weights were set
On this page — 10 sections
A score is only as trustworthy as the provenance of what went into it. This page lists every input the exposure score consumes, states whether we observed it, you declared it, we derived it or we assumed it, gives the anchor values that turn each input into a 0–100 sub-score, and explains how the five weights were arrived at. If you want the arithmetic that combines these, read How the exposure score is built first.
Provenance before weight
Before an input is weighted, it is labelled with how we came to know it. This is the single most useful thing on a finding record, because it tells a reviewer where to push. An observed input is a fact about your estate. An assumed input is a default of ours, and it is where a score is most likely to be wrong.
| Provenance class | What it means | Example | Effect on the finding |
|---|---|---|---|
| Observed | Read directly from a configuration, binary, certificate or handshake | The key-exchange group negotiated by a TLS endpoint | Scored normally. The observation is cited in the evidence chain. |
| Declared | Supplied by your team during intake or in a scope document | The retention obligation on a data store | Scored normally and attributed to the declaring owner by name. |
| Derived | Computed from other inputs by a rule published in the method | Confidentiality Horizon derived from a retention class | Scored normally. The rule that produced it is named in the record. |
| Assumed | Neither observed nor declared, so a documented conservative default applies | Reachability where we have no network data for a host | Scored with the default, flagged in the record, and routed to human review. |
A finding whose deciding dimension is Assumed never reaches a remediation plan without a person looking at it. That rule is enforced, not advisory, and it is listed in Accuracy, false positives, and how we report error alongside the other mandatory review triggers.
The five dimensions in detail
Each dimension is scored against anchors at 0, 25, 50, 75 and 100. Reviewers may interpolate between anchors but must record a reason when they do. The anchors below are abbreviated; the full rubric text lives in The Theos Method.
Primitive Fragility — weight 30
This dimension asks a narrow question: at the parameters actually deployed, how much of the primitive’s security does a known quantum algorithm remove? Shor’s algorithm removes essentially all of it from integer factorisation and elliptic-curve discrete logarithms, so RSA and ECC key establishment and signatures sit at the top. Grover’s algorithm gives a square-root speed-up against symmetric search, which halves effective key strength rather than eliminating it, so AES-128 and AES-256 sit in very different places.
- 100 — Classically sized RSA or elliptic-curve key establishment or signature. No parameter increase makes this survivable.
- 75 — A primitive that is already deprecated on classical grounds and also quantum-exposed, such as SHA-1 used for integrity or 3DES used for confidentiality.
- 50 — A symmetric primitive whose effective strength drops below the level your policy requires once Grover is assumed, for example AES-128 under a 128-bit policy.
- 25 — A conformant primitive with a narrow margin, or a hash function used in a construction where collision resistance carries more weight than it should.
- 0 — A NIST post-quantum algorithm from FIPS 203, FIPS 204 or FIPS 205 at an approved parameter set, or a symmetric primitive with a comfortable margin under Grover.
Sources: detector output from discovery, plus our algorithm register, which tracks NIST SP 800-131A transition guidance and the FIPS 203/204/205 parameter sets. See The detector catalogue for what produces the underlying observation.
Confidentiality Horizon — weight 25
How long must this data stay secret, counted from the moment it could be captured? This is the shelf-life term in the Mosca inequality, and it is the reason harvest-now-decrypt-later matters before any quantum computer exists. Horizon is almost always a Declared input, because your retention schedule and your regulatory obligations are yours to state.
Mosca inequality
if shelf_life + migration_time > time_to_CRQC
then the asset is already exposed
shelf_life -> Confidentiality Horizon (you declare it)
migration_time -> Change Cost (we estimate it with you)
time_to_CRQC -> we do not assert a value
see /knowledge/migration-windowAnchors run from 0 for data that is worthless within days, such as an ephemeral session token, through 50 for a multi-year commercial obligation, to 100 for data with a statutory retention period measured in decades: health records, life policies, pension data, sealed government material. Signing keys are scored on the lifetime of the artefacts they authenticate, not on the key rotation period, which is why firmware signing scores high even when keys rotate often.
Reachability — weight 20
Reachability measures how much work an adversary has to do to obtain the protected material, either by reaching the asset or by recording its traffic. It is not a measure of whether the asset has been attacked. An asset can be at 100 here and have a clean history, and that is not a contradiction, because harvest-now-decrypt-later leaves no trace at the time of capture.
- 100 — Internet-facing, or traffic crosses a network path you do not control, including carrier and cloud backbone links.
- 60 — Reachable from a broad internal population, or traffic crosses between availability zones or data centres.
- 30 — Reachable only from a segmented administrative network with brokered access.
- 0 — No transcript exists to capture and no remote path reaches the material, for example a key held only inside a hardware security module with no external protocol exposure.
Change Cost — weight 15
A cost factor inside an exposure score deserves an explanation, because the obvious objection is that difficulty is not risk. Our reasoning is that it is: an asset that takes eighteen months and forty counterparties to change stays vulnerable for eighteen months, and that residual duration is exposure. Change Cost is the migration-time term in the Mosca inequality, and leaving it out would silently assume every asset can be fixed instantly.
Anchors are driven by coordination breadth rather than engineering hours. A configuration change on a single load balancer scores low. A change requiring a protocol version bump agreed with external counterparties, or a re-issue from a signing root, scores high. Change Cost is capped at 75 unless the change touches a trust anchor, so it cannot dominate a score on its own.
Substitution Gap — weight 10
The smallest weight, and the one that shrinks fastest as the standards landscape matures. Substitution Gap asks whether there is somewhere to go. A primitive with a published NIST replacement, a shipped library implementation and a defined hybrid deployment mode scores near zero even when everything else about it is bad, because the work is scheduling rather than research. A primitive with no standardised successor scores high, and those findings are escalated to a named reviewer rather than handed to an engineer.
Sources: our standards register, tracking FIPS 203, FIPS 204 and FIPS 205, the CNSA 2.0 algorithm list, and library and protocol support status. See FIPS 203, 204 and 205, mapped to output.
Where each input actually comes from
| Dimension | Primary source | Usual provenance | If it is missing |
|---|---|---|---|
| Primitive Fragility | Detector output plus our algorithm register | Observed | No finding is raised. Fragility cannot be assumed. |
| Confidentiality Horizon | Your retention and data-classification schedule | Declared | A conservative default by data class, marked Assumed. |
| Reachability | Ingress configuration, certificate subject names, network reachability data | Observed or Derived | Defaults to 60, marked Assumed, flagged for review. |
| Change Cost | Dependency graph plus a short interview with the asset owner | Derived or Declared | Defaults to 50, marked Assumed. |
| Substitution Gap | Our standards and library-support register | Derived | Not applicable. The register always resolves. |
What we never take as an input
No private key, seed, passphrase or HSM-resident secret is an input to any dimension. We do not need key material to score an asset and we do not accept it. We also do not price your estate, do not read the plaintext protected by the cryptography we find, and do not ingest customer data as a scoring signal. See What we hold, and what we never take.
Why the weights are what they are
The weights are a judgement, and we would rather say so than dress them up. They were set by structured elicitation among our cryptography reviewers, each proposing a weight vector independently, followed by discussion of the disagreements and a fixed integer result. The vector was then checked against our labelled evaluation set for rank agreement with reviewer ordering, not for accuracy against a ground-truth score, because no ground-truth score exists.
- 01Fragility carries the largest weight because it is the only dimension that is a property of mathematics rather than of your deployment. It is also the most reliably Observed.
- 02Horizon comes second because it is the term that makes exposure real today rather than at some future date.
- 03Reachability is weighted below Horizon deliberately. A short-lived secret on a public endpoint is a smaller problem than a fifty-year secret on an internal one.
- 04Change Cost and Substitution Gap together carry 25, enough to influence ordering within a tier and not enough to move an asset between tiers on their own.
Weights change only on a method version bump, and a bump re-scores nothing retroactively. Every published score carries the version it was computed under. The review cadence and the notice period are set out in How the method is versioned. The most recent weight review was [PLACEHOLDER: date of the most recent weight review].
When an input is missing
Incomplete estates are the normal case, not the exception. Our rule is that a missing input never quietly improves a score. Defaults are set at or above the population midpoint, the substitution is labelled Assumed, and the gap is listed in the report so it can be closed on the next run.
There is one hard stop. If Primitive Fragility cannot be observed, we do not raise a finding at all. A guess about which algorithm is in use is worse than an acknowledged blind spot, and blind spots are enumerated rather than scored. What discovery will not do lists the categories where this happens most often.
Once an asset has a score, it lands in one of four tiers, each with an explicit band and an expected action.What the risk tiers meanMore in Risk & scoring