How the exposure score is built

Every asset AutoPQC discovers carries one number between 0 and 100. Higher means more exposure. This page gives the whole construction: the five dimensions, the weight on each, the arithmetic that combines them, the one override rule that can move a result, and the roll-up from assets to an estate figure. We then run our pilot estate through the same arithmetic so the 75 / 100 we quote elsewhere is derived here rather than asserted.

#What the number is

The exposure score has one job: to order a migration backlog. It answers the question of which asset a cryptography engineer should touch first, and nothing else. It is a decision aid, not a verdict, and it is designed to be argued with. Every component is published so that a reviewer who disagrees can point at the dimension they disagree about instead of rejecting the whole number.

Higher is worse. We chose that direction so the score reads the same way as the entries already in an enterprise risk register, where a rising figure means rising concern. It also means the estate score falls as remediation lands, which is the shape most programme dashboards expect.

Scoring is deterministic. The same inputs under the same method version produce the same score every time. There is no sampling and no randomness at scoring time, so two reviewers working from the same finding record reach the same integer. See Reproducing our numbers for how to recompute a score by hand.

#The five dimensions

Each asset is scored 0–100 on five dimensions against a published anchor rubric, and those five sub-scores are then combined. We kept the count deliberately small. Five dimensions can each be defended in a review meeting; fifteen cannot, and in practice the extra ones correlate with the first few rather than adding information.

Because the weights sum to 100 and every sub-score sits on 0–100, the combined result stays on the same scale as its inputs. That property matters more than it sounds. A reviewer reads a dimension sub-score and the final score in the same units, and can see at once how much of the total a single dimension contributed. The inputs, the weights, and where they come from gives the rubric anchors and the provenance of each input.

#How the dimensions combine

The aggregation is a weighted arithmetic mean, rounded half-up to an integer, followed by one explicit floor rule.

exposure(asset) = round_half_up(
      0.30 * primitive_fragility
    + 0.25 * confidentiality_horizon
    + 0.20 * reachability
    + 0.15 * change_cost
    + 0.10 * substitution_gap
)

# every dimension is scored 0-100 against the published anchor rubric
#
# fragility floor, applied after rounding:
#   if primitive_fragility == 100 and reachability >= 60:
#       exposure = max(exposure, 65)

We use an arithmetic mean rather than a multiplicative or geometric aggregation for one reason: you can reproduce it in a spreadsheet. Multiplicative aggregation is a legitimate choice and it does stop one healthy dimension from masking a fatal one, but it makes single-dimension sensitivity hard to explain to a risk committee and hard to audit line by line. We would rather handle the masking problem with a rule we can state in two lines than bury it inside the arithmetic.

That rule is the fragility floor. An asset whose primitive is completely defeated by a known quantum attack, and which is meaningfully reachable, belongs inside the migration programme even when it is cheap to fix and its data is short-lived. The floor lifts such an asset to 65, the bottom of the Elevated band. It never lowers a score. Where the floor binds, the finding record keeps both the computed value and the floored value, so the adjustment is visible rather than silent.

#A worked asset

The example below is illustrative. It is not a record from the pilot estate. It exists to show the arithmetic on a shape that is common in the sectors we work in.

asset       tls-edge-payments-01   (illustrative)
primitive   RSA-2048 key transport, TLS termination at the edge

primitive_fragility     100  x 0.30  =  30.00
confidentiality_horizon  95  x 0.25  =  23.75
reachability            100  x 0.20  =  20.00
change_cost              65  x 0.15  =   9.75
substitution_gap         30  x 0.10  =   3.00
                                        ------
raw                                      86.50
round half-up                            87
fragility floor (65)                     not binding
tier                                     Acute  (85-100)

Read what moved the number. Fragility and reachability are both at maximum and together contribute 50 of the 87. Substitution Gap is low because FIPS 203 gives a standardised key-establishment replacement and mainstream TLS stacks already ship a hybrid mode, so this is a solvable problem rather than a stuck one. Change Cost sits mid-band because the cutover has to be coordinated with clients you do not control. Taking that one dimension to zero would move the asset to 77, still Elevated. Nothing short of replacing the primitive removes this asset from the migration programme, which is the correct answer.

#From assets to an estate score

The estate score is a criticality-weighted mean of asset scores. Weighting by business criticality stops a large population of low-consequence assets from diluting a small population of consequential ones. Criticality is declared by you during intake, not inferred by us, and it uses three bands.

Core (k = 3)

Regulated, customer-facing or safety-relevant. Signing roots and payment paths sit here.

Supporting (k = 2)

Internal systems that process regulated data but are not directly exposed to customers.

Ancillary (k = 1)

Everything else inside the agreed scope.

Our pilot run discovered 42 cryptographic assets and classified 36 of them vulnerable. Grouped into cohorts and weighted by criticality, the arithmetic runs as below. The cohort counts total the pilot’s real 42 and 36. The cohort mean scores are illustrative values used to show the roll-up, not a per-asset dump of the pilot record.

estate = sum(k * n * cohort_mean) / sum(k * n)
       = 6295 / 84
       = 74.940...

round half-up = 75
tier          = Elevated  (65-84)

That is the 75 / 100 we quote for the pilot estate. It is an ordinary weighted mean of 42 asset scores. It sits ten points above the floor of the Elevated band and ten below Acute, so no single cohort in the table moves the estate tier on its own. See What the risk tiers mean for what Elevated obliges, and Sequencing a migration for what to do with the ordering this produces.

#What is deliberately absent

Several inputs a reader might expect are not in the score. Each was considered and left out for a stated reason.

• Monetary loss estimates. We do not know the value of your data and we will not model it. A currency figure would carry more authority than its inputs deserve.
• CVE severity. A quantum exposure and a patchable implementation flaw are different problems on different clocks. We read CISA’s Known Exploited Vulnerabilities catalogue and the GitHub Advisory Database during discovery, and we report what they say alongside this score rather than folding a severity number into it.
• Attacker capability assumptions. No dimension encodes a belief about a specific adversary’s budget or hardware.
• Time to a quantum computer. The Mosca inequality needs that term and we decline to supply it. The migration window explains how we handle the arithmetic without inventing the date.