Cohort prevalence: how common is this device's boot config, among devices like it

A modern fleet of legitimate devices does notshare one canonical set of PCR values: firmware, bootloader, and Secure Boot policy measurements legitimately differ by vendor, model, and firmware revision. So "rare PCR value" on its own means "uncommon hardware/firmware combination," not "untrustworthy." That is exactly why prevalence is not the trust gate.

What it does answer, scoped within a cohort of genuinely-comparable devices:how common is this device's least-common tracked boot measurement among real, distinct devices of the same make/model/firmware? That is a useful anomaly signal (a device whose Secure Boot policy is shared by 0.01% of its cohort is worth a second look), but it is advisory by default, never a silent reject.

• Catches: a boot configuration that is unusual relative to other devices of the same kind.
• Does not catch: tampering, downgrade, or a bad boot state. The explicit Secure Boot / dbx / TPM-class / EAR checks do that, and they remain the gate.

Every attestation token and verify response carries the cohort claims, whether or not you act on them in policy. Read them, log them, alert on them; gating is opt-in.

{
  "ueid": "2f9c4a1c8b…",
  "verdict": "pass",
  "earStatus": "affirming",
  "attestationType": "tpm20",

  "cohortKey": "c0a7f31e9b4d…",
  "cohortScope": "global",
  "cohortSampleSize": 48211,
  "cohortPrevalence": 0.034,
  "cohortPrevalencePerPcr": { "0": 0.91, "4": 0.88, "7": 0.034 },
  "novelProfile": false
}

Here the device passes every explicit check (earStatus: affirming). Its firmware and bootloader measurements are common in its cohort, but its Secure Boot policy measurement (PCR[7]) is shared by only 3.4% of distinct devices of the same kind, so cohortPrevalenceis the weakest-link 0.034. Whether that matters is your policy's call.

A device's cohort is its cohortKey: an opaque hash derived only from fields bound to the verified quote and validated EK chain, never from unauthenticated SMBIOS or self-reported device claims:

• TPM-class family: the coarse family from the validated EK certificate chain (e.g. firmware-tpm-intel-ptt).
• Firmware-version measurement: the PCR[0] EV_S_CRTM_VERSIONevent digest (the firmware build's own identity).
• Secure Boot PK issuer: the platform-key issuer from the PCR[7] Secure Boot variables (the OEM platform-key identity).

The key is deliberately coarse-but-sound in v1 and versioned (cohortKeyVersion) so the field set can be refined without invalidating stored statistics. You receive the key so you can reference exact configurations in your tenant allowlist.

Within a cohort, only three low-variance PCRs are scored: PCR[0] (firmware / CRTM), PCR[4] (boot manager / OS loader), PCR[7](Secure Boot policy). High-variance PCRs (e.g. PCR[1] config) are excluded; they'd make every device a singleton and prevalence meaningless.

For each tracked PCR, we keep two distinct-device counters (HyperLogLog), per scope:

• value counter: distinct devices in the cohort whose measurement for that PCR is exactly this device's hash.
• total counter: distinct devices in the cohort that reported that PCR at all (any hash). This is the denominator.

prevalencePerPcr[i] = distinct devices in cohort with THIS hash for PCR i
                      ───────────────────────────────────────────────────   ∈ [0, 1]
                      distinct devices in cohort reporting PCR i (any hash)

cohortPrevalence  = min over tracked PCRs of prevalencePerPcr[i]   // weakest link
cohortSampleSize  = min over tracked PCRs of the total (denominator)

So cohortPrevalencePerPcr is a set of fractions, not counts: “what share of devices like me share my exact PCR[i] measurement.” And cohortPrevalence collapses them to the rarest one: your least-common measurement is the one that matters for anomaly, so the weakest link drives the single number. A device whose firmware and bootloader are ubiquitous (0.91, 0.88) but whose Secure Boot policy is shared by 3.4% of its cohort has a cohortPrevalence of 0.034.

Counters are distinct-device cardinality estimates (HyperLogLog), so one device re-attesting a million times moves nothing (anti-gaming), and they store no device or tenant identifiers, only registers (see Privacy by construction).

Three policy fields control whether prevalence tightens a verdict. All default to the no-op / advisory setting, so adding cohort prevalence to your account changes nothing until you opt in.

{
  "name": "cohort-advisory",
  "acceptedClassGroups": ["hardware", "firmware-tpm"],
  "minCohortPrevalence": 0.001,
  "cohortScope": "global",
  "onNovelProfile": "warn"
}

The class-acceptance fields (acceptedClassGroups) are the explicit gate; they run first and unchanged. The cohort fields (minCohortPrevalence, cohortScope, onNovelProfile) are evaluated only on devices that already passed them, and here they only annotate: a below-floor or novel device still passes, but the verdict carries the flag and a degraded configuration trustworthiness vector so you can route it to review without blocking a legitimate new device.

{
  "name": "cohort-golden-image",
  "acceptedClassGroups": ["hardware", "firmware-tpm"],
  "minCohortPrevalence": 0.05,
  "cohortScope": "tenant-fleet",
  "onNovelProfile": "reject"
}

Against your own fleet (cohortScope: tenant-fleet), the cohort statistics are an empirical golden image of the configurations your managed devices actually run, so reject is a defensible choice there. Pair it with an allowlist so you can pre-approve a new corporate image the day you roll it out.

This is the one place prevalence has a real, unavoidable limitation, and we will not paper over it: a brand-new firmware build is legitimately novel until adoption grows. When a fresh OS update or new hardware SKU ships, the first devices to attest with its measurements have low prevalence by definition; there is no population yet. Hard-gating on prevalence at that moment would reject perfectly legitimate new hardware. This is the same failure mode reputation systems like SmartScreen hit with new-but-signed binaries.

That is precisely why the design is shaped the way it is:

• Default is advisory (warn). onNovelProfile defaults to warn, never reject. A novel config is flagged, not denied.
• Cold start is explicit, not a silent reject. When a cohort has fewer than the configured sample floor, cohortPrevalence is null and novelProfile is true. Your policy decides what that means via onNovelProfile; it is never silently rejected.
• It self-heals. Every cryptographically authentic attestation updates the cohort statistics, including ones that fail policy enforcement. (Authentic means: quote signature verified, event log replays to the quote, EK chain valid; counted once per distinct EK-derived device.) So as real devices adopt a new config, it naturally crosses the prevalence threshold on its own, without you doing anything.

When you want to hard-gate but also roll out a new approved configuration, allowlist it. An allowlist entry is a (cohortKey, pcrIndex, pcrValueHash) tuple scoped to your tenant only. A device config is allowlisted for your tenant when every tracked measurement is present in your entries, and that satisfies the prevalence / novelty constraint for your policies regardless of its global or fleet prevalence.

• Your dashboard shows a review queue of novel / low-prevalence configs from your own attestations only, never any other tenant's devices.
• One-click approve adds the allowlist entry; the config then passes immediately.
• Hard isolation: every query is tenant-filtered. No endpoint returns another tenant's allowlist entries or device configurations.

The prevalence layer stores no identifiers. Distinct-device counts are maintained with cardinality estimators (HyperLogLog registers) that hold only probabilistic count state, mathematically incapable of revealing which device or which tenant was counted. The global pool is aggregate-only; tenant-fleet statistics are partitioned per tenant. There is no cross-customer data exposure, and no way to recover a device or tenant from the stored counters.