Attestation drift across distributed terminal fleets

1. The shape of a real fleet

A fleet of N terminals — N in the thousands to tens of thousands — never sits on one firmware version. Updates roll out in batches, batches stall, devices go offline mid-update, hardware revisions take incompatible firmware lines, manufacturer updates arrive on different cycles for different SKUs. Six months after a release, the modal terminal is on the recent build; the distribution has a long tail.

The numbers depend on the fleet, but the shape is consistent across fleets the field has studied:

• The mode is the current vendor build, whichever was the most recent stable release at the operator’s last fleet push.
• The tail extends back to whatever release the oldest not-yet-decommissioned hardware revision can run.
• The tail is small in cohort count but large in cumulative exposure-days: 200 terminals on a year-old version contribute ~6,000 exposed-device-days per month, and 1,000+ such terminals — common in mid-tier fleets — push that into tens of thousands per month.

2. What per-device attestation tells the operator

Per-device attestation behaves differently across terminal classes:

• Android-based mPOS (Tap-to-Phone, COTS commerce devices). Play Integrity returns a signed verdict per call [1]; the Android Key Attestation extension on a hardware-backed key exposes the device’s security-patch level (bootPatchLevel / osPatchLevel) — the data point that lets the operator answer per-device patch freshness.
• iOS-based card-on-glass. Apple App Attest attests the app instance and its key binding to a known device — it does not produce an OS patch-level verdict. Per-device patch freshness on iOS is not exposed through this API; operators combine App Attest with an iOS-side patch-level surface derived from the app’s own runtime checks.
• Fixed-function PCI PTS POI terminals. PCI PTS POI does not standardise a remote attestation channel — there is no PTS equivalent to Play Integrity returning per-call verdicts. Some vendor SDKs expose proprietary attestation interfaces; others do not. Operators of mixed PTS fleets typically have no per-call signed verdict from the platform itself.

Across all three classes, where a per-device verdict is available, it is useful at the moment of the transaction: the operator can decide whether to permit a high-value flow on that terminal at that moment. Where a per-call verdict is not available (most fixed-function PTS), execution evidence is the only signed-per-call channel the operator has.

What it does not tell the operator: the fleet distribution. Per-device attestation surfaces this device’s state. The operator that wants to answer “what fraction of my fleet is more than 90 days behind security patch?” cannot answer it from per-device verdicts alone — only from per-device verdicts aggregated across the fleet over time.

3. Why the aggregation matters

Three operational consequences follow:

• Vulnerability management at scale. PCI DSS Requirement 6 (vulnerability management) and Requirement 11 (regular testing) [3] require risk-ranking and remediation-tracking across the asset population. The fleet distribution is the basis for that ranking; without aggregation, the operator is ranking by anecdote.
• Update-rollout effectiveness. When a vendor ships a critical patch, the operator needs to know how the fleet absorbed it: 24h, 1 week, 30 days post-release. Per-device attestation produces the data points; only aggregation produces the curve.
• Cohort-level decisions. Some risk decisions are properly cohort-scoped: “block flows above $5k from terminals on versions older than v5.5 until they update.” This is a distribution decision, not a per-device decision.

4. Where EEI composes

Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — runs at every transaction and, where the platform exposes the underlying fields, includes firmware-version, security-patch, and rollback-counter signals as documented in os-downgrade-attacks and pos-tampering. Because the substrate signs the values per call, the operator holds a continuous, signed, queryable record of fleet composition over time — including on PCI PTS terminals that provide no remote attestation channel of their own.

What the operator can ask:

• “What was my fleet’s mean security-patch age last month?”
• “Which terminals are in the bottom 5% of patch level today?”
• “When did 95% of the fleet cross past patch X?”

These are fleet-shape questions. Per-device attestation contributes the points; signed evidence at scale contributes the surface.

5. Which signals make it observable

device.integrity. Each Evidence Token carries the firmware-version and security-patch fields per terminal per transaction. The operator’s verifier consumes the tokens; the operator’s analytics layer aggregates over time. The aggregation is where attestation drift becomes legible.

6. Cross-references

• Sibling articles: pos-tampering, os-downgrade-attacks, mpos-side-loaded-apps
• Theme 5 (forthcoming): host-side correlation
• Theme 2: hardware-attestation, play-integrity

7. External references

[1] Google. Play Integrity API — Overview. developer.android.com/google/play/integrity/overview. Cited 2026-03-06.

[2] AOSP. Android Key Attestation — KeyDescription schema and security-patch fields. source.android.com/docs/security/features/keystore/attestation. Cited 2026-03-06.

[3] PCI Security Standards Council. PCI DSS v4.0.1 — Requirement 6 (vulnerability management) and Requirement 11 (regular testing). pcisecuritystandards.org/document_library/?category=pcidss. Cited 2026-03-06.

[4] Google. Android Security Bulletin patch-level distribution. source.android.com/docs/security/bulletin. Cited 2026-03-06.