Skip to content
Theos Quantum Θ mark
Risk & scoring

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

Reviewed 24 Jul 2026 8 min read
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 classWhat it meansExampleEffect on the finding
ObservedRead directly from a configuration, binary, certificate or handshakeThe key-exchange group negotiated by a TLS endpointScored normally. The observation is cited in the evidence chain.
DeclaredSupplied by your team during intake or in a scope documentThe retention obligation on a data storeScored normally and attributed to the declaring owner by name.
DerivedComputed from other inputs by a rule published in the methodConfidentiality Horizon derived from a retention classScored normally. The rule that produced it is named in the record.
AssumedNeither observed nor declared, so a documented conservative default appliesReachability where we have no network data for a hostScored with the default, flagged in the record, and routed to human review.
Every dimension sub-score on a finding carries one of these four labels.

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.

text
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-window

Anchors 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

DimensionPrimary sourceUsual provenanceIf it is missing
Primitive FragilityDetector output plus our algorithm registerObservedNo finding is raised. Fragility cannot be assumed.
Confidentiality HorizonYour retention and data-classification scheduleDeclaredA conservative default by data class, marked Assumed.
ReachabilityIngress configuration, certificate subject names, network reachability dataObserved or DerivedDefaults to 60, marked Assumed, flagged for review.
Change CostDependency graph plus a short interview with the asset ownerDerived or DeclaredDefaults to 50, marked Assumed.
Substitution GapOur standards and library-support registerDerivedNot 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.

  1. 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.
  2. 02Horizon comes second because it is the term that makes exposure real today rather than at some future date.
  3. 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.
  4. 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 mean