How to read your first exposure report

The front page of an exposure report carries four numbers. They are easy to read wrongly, and a wrong reading in the first week sets the tone for the whole programme. This page walks through the figures from our pilot run and states, for each one, what it supports and what it does not.

Use it as a template for reading your own. The numbers will differ. The questions to ask of them will not.

#The four figures, and the pilot values

Read them in that order. The count bounds the score, the score prioritises the work, and the time figure explains why the exercise is repeatable rather than annual.

#42 — the asset count

Forty-two cryptographic assets were discovered in the pilot estate. An asset is a distinct cryptographic usage in a distinct context, not a file, a host or a certificate. The same algorithm appearing in a library, a container image and a load-balancer profile is one asset if it serves one usage in one context. What counts as an asset gives the full rule.

The count is bounded by scope, so it is not a measure of your estate. It is a measure of the part of your estate you agreed to look at.

• It does mean: every one of the 42 has a provenance record — the detector, the artefact, the revision, the matched evidence.
• It does not mean: the estate contains exactly 42. Excluded scope and undetectable cryptography are not in the number, and the report lists both.
• It does not mean: 42 pieces of work. Several assets often share one root cause, and one asset can require changes in six services.
• Check first: the exclusions list. Read it before the score. A high count with a short exclusions list means something different from a low count with a long one.

#36 of 42 — the vulnerable classification

Thirty-six of the 42 assets were classified vulnerable. That leaves six that were not, which is the more interesting half of the sentence: those six were examined and found not to carry quantum-relevant weakness, and each carries the reasoning for that conclusion.

"Vulnerable" here has a specific meaning. It says the asset relies on a primitive whose security assumption fails against a sufficiently capable quantum adversary — RSA and elliptic-curve key establishment and signatures against Shor's algorithm, and symmetric constructions with reduced margin against Grover's. It says nothing about whether the asset is exploitable today by anybody.

• It does mean: 36 assets need a replacement primitive at some point, and each has a mapped FIPS 203, 204 or 205 target.
• It does not mean: 36 live vulnerabilities. No quantum computer exists today that breaks any of them.
• It does not mean: 36 urgent items. Urgency comes from data lifetime and exposure surface, which is what the score weights.
• It does not mean: the other six are safe forever. They are not vulnerable under the current method version, which is a dated statement.

A high vulnerable proportion is normal and expected. Almost all public-key cryptography deployed before 2024 is affected, because the standards it was built on predate the replacements. A first report showing most of the estate as vulnerable is a correct report, not an alarming one. What a quantum computer actually breaks sets out which primitives fall and why.

#75 / 100 — the aggregate exposure score

The pilot estate scored 75 out of 100, where higher means more exposed. The aggregate is not an average of the per-asset scores. It weights each asset by the inputs described in The inputs, the weights, and where they come from — algorithm family, key length, protocol context, data lifetime, exposure surface and remediation difficulty — so a small number of long-lived, externally exposed assets can move it more than a large number of internal ones.

This is the figure most likely to be misused, because it is the one that fits in a board pack.

The score's job is to order work, not to summarise your security posture. Track the tier distribution alongside it — an estate moving assets out of the top tier is making progress even while the aggregate barely shifts. See How the exposure score is built and What the risk tiers mean.

#22 hours to 14 minutes — the time figure

A manual review of the same pilot estate took 22 hours. AutoPQC completed it in 14 minutes. On the two published figures that is 1,320 minutes against 14, a factor of roughly 94, on one estate of 42 assets.

The number that matters is not the ratio. It is that 14 minutes is short enough to run on every change, and 22 hours is not. A 22-hour review happens once a year and is stale within a quarter. A 14-minute review can run against a release candidate, which is what turns a cryptographic inventory from a document into a control. See API and automation surfaces for where that fits in a pipeline.

• It does mean: repeated assessment becomes cheap enough to be continuous.
• It does not mean: the engagement takes 14 minutes. Scoping, access, triage and the review session are human work and take weeks. See What the first thirty days look like.
• It does not mean: 94 times fewer person-hours overall. The saving is in mechanical review, not in the decisions that follow it.
• It does not generalise: one estate, one scope, one detector configuration.

#The error bars: 95.2% and 0.94

Classification accuracy is 95.2% and macro-F1 on the labelled evaluation set is 0.94. Both are properties of our evaluation set, not promises about your estate. We publish them because a classifier without a reported error rate is not a measurement.

Apply them to the pilot figures and the honest conclusion is straightforward: at 95.2% accuracy across 42 assets, you should expect roughly two labels to be wrong. Not zero. That is the reason the week-three review session exists, and it is the reason every finding ships with its evidence attached.

Accuracy 95.2%

Share of assets in the evaluation set given the correct classification

Macro-F1 0.94

Balanced performance across classes, so rare categories are not hidden by common ones

Practical implication

On a 42-asset estate, expect around two labels to need correcting

Your response

Review the top tier with your own engineers before scheduling anything

How we count errors, which direction we prefer to err in, and what we do when a finding is disputed are set out in Accuracy, false positives, and how we report error. The short version: we tune toward over-reporting, because a false positive costs an engineer ten minutes and a false negative costs you an asset you never migrated.

#Three mistakes in a first read

1. 01Reading the score before the exclusions. The exclusions list defines what the score is a score of. Read it first, every time.
2. 02Treating the vulnerable count as an incident queue. These are architectural exposures on a multi-year horizon, not live intrusions. Escalating all 36 at once burns the credibility you need for the actual programme.
3. 03Working top-down through the score. The highest-scoring asset is not always the right first move. Sequencing accounts for change-freeze windows, dependencies and rollback, which the score does not. See Sequencing a migration.

One last habit worth forming. Every report records the method version that produced it. When you compare two reports, check that version first — a score that moved because the method changed is a different fact from a score that moved because your estate did. See How the method is versioned.