The scope of these results
Device evidence, examined.
Our Android app asks the coordinator for a challenge, receives a device certificate chain in return, and checks that evidence against pinned trust roots and revocation information. Everything recorded here is about attestation. None of it is about compute performance, and none of it is about workload confidentiality.
Accepted means the evidence passed the verifier on the day we ran it. Your own policy can still turn that device away, and often should. Each line below is one observation on one handset, not a certificate of health for an entire model family.
Recorded by hand, October 2026
Android Hardware tests
Each card below was installed from the Google Play Store onto a physically distinct handset and attested against the live coordinator. The device name on every card is ours, written down during the session. On the seven recorded on 13 October the card also carries the model the hardware signed, because version 1.1 of the app asks for device property attestation and those are the first devices on this site to answer. The two are not the same string, and one of them is a factory codename. Verdicts, key security levels, patch levels and trust paths come from the coordinator on every card. Three of the seven changed what we publish: Seven stock Android phones, and we could not name the boot key on a single one of them, The five year old phone was the easy case, and A phone will tell you its model in hardware, and the model it tells you is a factory codename.
Motorola
Edge 70 Fusion
- Model as signed
marvel- OS patch level
- January 2026
- Key security
- Trusted execution environment
- Trust path
- Google attestation root
The most current of the seven, nine months behind on patches on the day it ran. The model it signed in hardware is the word marvel, a factory codename, which is why the name above it had to be written down by us. That has an entry of its own, A phone will tell you its model in hardware, and the model it tells you is a factory codename. Boot and vendor patch both 1 January 2026, Android 16.0.0.
OnePlus
13R
- Model as signed
CPH2691- OS patch level
- Not captured
- Key security
- StrongBox
- Trust path
- Google attestation root
A dedicated secure element, and the persistent identity key sits in the same place as the attestation key. Boot and vendor patch both 5 December 2024. Seventeen claims, the same seventeen the handsets on the weaker backing produced, which is the point worth taking away: the tier changes where the key lives, not how much the evidence says.
Samsung
Galaxy A17
- Model as signed
SM-A176B- OS patch level
- Not captured
- Key security
- Trusted execution environment
- Trust path
- Google attestation root
Boot and vendor patch both 1 September 2025, thirteen months behind on the day it ran, and the freshest of the Samsungs here. A mid-range handset holding its own against the flagships on every question the attestation is asked.
Samsung
Galaxy Tab S11
- Model as signed
SM-X736B- OS patch level
- August 2025
- Key security
- StrongBox
- Trust path
- Google attestation root
A tablet on Android 16.0.0, StrongBox, fully verified, and fourteen months behind on security patches. The notice we added the same day would hand it a warning, and somebody bought it recently.
Samsung
Galaxy Z Fold 5
- Model as signed
Not captured- OS patch level
- Not captured
- Key security
- StrongBox
- Trust path
- Google attestation root
The oldest patch state of the seven, three years and two months behind at boot level, boot and vendor patch both 1 August 2023. Its device.model line sat below the visible area of the session capture, so the signed string is the one field this card cannot print. Everything else here is read from the evidence.
Samsung
Galaxy Z Fold 6
- Model as signed
SM-F956B- OS patch level
- Not captured
- Key security
- StrongBox
- Trust path
- Google attestation root
A folding handset, and the fold changes nothing the evidence says. Boot and vendor patch both 1 June 2024, twenty eight months behind, locked, verified, accepted. The second fold on this page, five generations apart from the one above it, and the evidence shape is identical.
Oppo
F29
- Model as signed
CPH2721- OS patch level
- February 2025
- Key security
- Trusted execution environment
- Trust path
- Google attestation root
Twenty months behind on patches and a major Android release behind the rest of this group, on 15.0.0. Seventeen claims, seven statements of what the evidence does not prove, and a clean verdict. The second device here the patch notice would speak up about.
Pixel 11 Pro
- Key security
- StrongBox
- OS patch level
- June 2026
- Trust path
- Google attestation root
The first handset to verify after the Play app signing certificate was pinned. Its refusal the hour before was ours, not the phone’s: the coordinator had been told to accept only our upload certificate, and a Play Store install is signed by Google.
Pixel 8
- Key security
- StrongBox
- OS patch level
- October 2023
- OS distribution
- stock
- Trust path
- Google attestation root
The most detailed result of the run, and the oldest. Seventeen separate claims came back, including the stock operating system distribution, and a security patch level nearly three years behind the newest device checked in the same session. Both phones verified. Verification is not currency.
OnePlus
15R
- Key security
- StrongBox
- Trust path
- Google attestation root
Refused on the first attempt by our own certificate parser, not by the device. One boolean byte was encoded in a way the specification permits and our reader did not. The phone was accepted unchanged once the reader was corrected. A genuine device we had been turning away.
Samsung
Galaxy Z Fold 8 Ultra
- Trust path
- Google attestation root
A folding handset, verified on exactly the same path as every other Android device on this page. The hinge changes nothing about what the attestation says, which is worth stating plainly because people assume it does.
Samsung
S26 Ultra
- Trust path
- Google attestation root
Run specifically to sit beside the S22 Ultra we recorded by hand in September, so we could see what four years of the same vendor looks like in the evidence.
Oppo
K14x
- OS patch level
- April 2026
- Trust path
- Google attestation root
First Oppo on the record. It reached Google’s attestation root the same way every other brand here did, and that is the whole argument for a verifier that is not built around one vendor.
Vivo
T5x
- OS patch level
- January 2026
- Trust path
- Google attestation root
First Vivo device on the record.
Realme
P4
- OS patch level
- December 2025
- Trust path
- Google attestation root
First Realme device on the record. Two earlier sessions on this model died before the app could report anything. The third finished, and what you are reading is the third run, not an average of the three.
Pixel 6
- Reported application
- UnknownPackage
- Signing certificates reported
- none
- Trust path
- Chain accepted, application not
The attestation chain was sound. The device would not say which app had produced it. The calling application came back as UnknownPackage carrying no signing certificate at all, so it could not be matched against the one application this coordinator accepts, and the evidence was refused. One unit, and we still cannot tell you why. It is on the page because a refusal we cannot explain is worth more to you than eight we can.
Source: hand-recorded test sessions, 11–13 October 2026, on physical devices. Of the seven recorded on 13 October, four back their keys with StrongBox and three with a trusted execution environment, and every one produced the same seventeen claims; on all seven the bootloader was locked, verified boot had passed, and the boot patch level and the vendor patch level were the same date. Xiaomi could not be tested. No Xiaomi handset, including the Redmi Note 14 Pro 5G, was available to us. Node identifiers, subject identifiers and raw device certificates are not included here.
Recorded by hand, 13 October 2026
Apple Hardware tests
Seven attestations across six models, every one installed from TestFlight onto a physically distinct device and checked against the live coordinator. They span iOS 17.0 to iOS 27.0, and one of them is not a phone. The device names and operating system versions are recorded by hand from the sessions; the verdicts and trust paths come from the coordinator. Apple App Attest reports no operating system version of its own, so the version on each card is ours and the evidence carries nothing to check it against. The finding has an entry of its own, We ran five iPhones across ten iOS releases and the evidence could not tell them apart.
Apple
iPhone 12
- OS version
- iOS 17.0
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
The oldest device and the whole point of running it. Ten major iOS releases separate this handset from the newest one on this page, and its evidence is indistinguishable from theirs.
Apple
iPhone 16 Pro Max
- OS version
- iOS 27.0
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
A second model on iOS 27, run to check whether the newest release carries anything the others do not. It does not. Four claims, the same four.
Apple
iPhone 17e
- OS version
- iOS 26.4
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
Slowest of the five to produce a key and an attestation, by a clear margin, timed by hand, not instrumented. Attestation is not a performance test and we are not publishing a number from a stopwatch, but the difference was large enough to write down.
Apple
iPhone Air
- OS version
- iOS 26.0
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
Accepted on the same path as every other Apple device here. A new chassis changes nothing the evidence says, which is worth stating because people assume it does.
Apple
iPhone 18 Pro Max
- OS version
- iOS 27.0
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
Run twice, from two separate instances, producing two different Secure Enclave keys and two different subjects. Both accepted, both carrying the same four claims, which is what turned one observation into a repeatable one.
Apple
iPad Pro 13
- Device class
- Tablet
- OS version
- Not recorded
- Key security
- Secure Enclave
- Trust path
- Apple App Attestation root
The only device here that is not a phone, and it made no difference at all. Four claims, the same four. Nothing in this evidence says tablet. We did not write its OS version down, and the attestation cannot tell us either, which is the entry below stated twice over.
Source: hand-recorded test session, 13 October 2026, on physical devices. Every device here produced exactly four hardware-backed claims: the application identity, the distribution environment, the key security level and the workload identity, and nine statements of what the evidence does not prove. Raw device certificates and identifiers are not included here.
Recorded by hand, September 2026
Earlier prototype observations
These five were written up by hand while the prototype was still being built, before the verifier kept records of its own. They stay on the page because they carry detail the generated table cannot.
Samsung
S22 Ultra
SM-S908U
- Key security
- StrongBox
- OS noted
- Android 16
- Trust path
- RSA attestation chain
This one reported a dedicated secure element behind the key. A StrongBox policy is written to find exactly that result, and it is the line that separates this card from the three below it.
Motorola
Moto G Play 2026
XT2615-1
- Key security
- TEE
- OS patch observed
- June 2026
- Trust path
- RKP / ECDSA chain
The evidence was hardware backed and the verifier took it. It still would not clear a policy that insists on StrongBox, and a reader deciding where to send work needs to know which of those two sentences applies to them.
Samsung
Galaxy Tab A9+
SM-X210
- Key security
- TEE
- OS observed
- Android 16, patch June 2026
- Trust path
- Pinned Google root
Eight claims came back hardware enforced, bootloader and vendor patch levels among them. The Lenovo below carried neither, which is the first time we saw two devices at the same tier say different amounts about themselves.
Lenovo
Tab P12
TB370FU
- Key security
- TEE
- OS observed
- Android 15, patch June 2026
- Trust path
- Pinned Google root
The first MediaTek based device we have verified. It reported a locked bootloader and a verified boot state, both hardware enforced, which settled an open question about whether our pinned roots reached past Qualcomm silicon.
Sony
Xperia
G3223
- Attestation security
- Software
- Reported key security
- TEE
- Trust path
- No accepted pinned root
The device said TEE. Saying it was not enough. Nothing in the chain it presented led back to a root we pin, so there was no trusted hardware attestation here to accept, and we refused it.
Source: internal prototype engineering records. Exact per-run timestamps, complete OS/build configurations, and reproducible public evidence packages are not yet published. Raw device certificates and identifiers are not included here.
Lessons from the lab
Details that change a decision
One patch date is not the whole picture.
The Motorola observation recorded an OS patch level of June 2026 alongside a boot patch level of 5 May 2024. A policy that checks verified boot and stops there would walk straight past a two year gap.
Missing fields need explicit handling.
The Motorola evidence simply had no attested model field, where the Samsung evidence did. In our policy engine a missing required claim fails the rule. It is never quietly counted as satisfied, because that is how an absence turns into a yes.
The same tier does not mean the same evidence.
The Samsung tablet returned eight hardware-enforced claims. The Lenovo returned six, omitting the bootloader and vendor patch levels entirely. Both were accepted, both reported TEE, and both sit at key custody only. They still do not carry the same evidence. A policy that requires a vendor patch level would turn one of them away for a reason that has nothing to do with how trustworthy it is.
Certificate expiry is not a freshness mechanism.
The Lenovo attestation certificate carries no expiry at all. Samsung certificates in the same tests expired inside half an hour. So freshness rests where we put it, on the challenge the server issues and our own maximum attestation age, and never on a validity window we do not control.
Generated from verification records
Everything the verifier has checked
Which handsets are behind these rows. Recorded by hand during the sessions that produced them, and stated here because the evidence itself does not carry it: Google Pixel 11 Pro · Google Pixel 8 · Google Pixel 6 · Samsung Galaxy Z Fold 8 Ultra · Samsung S26 Ultra · Samsung S22 Ultra · OnePlus 15R · Oppo K14x · Vivo T5x · Realme P4 · Motorola Moto G Play 2026 · Samsung Galaxy Tab A9+ · Lenovo Tab P12 · Sony Xperia, together with our own development machines and a confidential GPU instance. Every device here is ours to name. Paid for with our own money or owned outright, tested by us, and published at our discretion. They are not written into the rows below for a different reason: a row is not a device. The verified Android row is seventeen separate attestations folded into one line, and no single handset name belongs on it. A device earns its own row only once its evidence makes it distinguishable from the others, which is what happened to the Pixel 11 Pro and what the rest of these cannot now do. The cards further down give each handset its own result. Android attestations only began carrying brand, manufacturer and model with app version 1.1 on 12 October 2026, and an attestation made before that cannot be reopened and asked again. That is why one row names itself and the rest never will. See The first device to put its own name on this page and A phone will not tell you what it is unless you ask.
Apple device
- Checked against
- Apple App Attest
- What the hardware protects
- key-custody-only
- Times seen
- 6
Apple device
- Key security
- secure-enclave
- Checked against
- Apple App Attest
- What the hardware protects
- key-custody-only
- Times seen
- 13
AWS Nitro enclave
- Checked against
- AWS Nitro Enclaves
- What the hardware protects
- memory-encrypted-vm
- Times seen
- 1
Android handset
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 34
Android handset
- Key security
- strongbox
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 5
Android handset
- Key security
- strongbox
- Patch level
- 2025-11
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- strongbox
- Patch level
- 2026-01
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- strongbox
- OS version
- 14.0.0
- Patch level
- 2023-10
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- strongbox
- OS version
- 17.0.0
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 2
Android handset
- Key security
- tee
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 4
Android handset
- Key security
- tee
- Patch level
- 2025-12
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- tee
- Patch level
- 2026-01
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- tee
- Patch level
- 2026-04
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- tee
- OS version
- 11.0.0
- Patch level
- 2021-11
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- tee
- OS version
- 11.0.0
- Patch level
- 2022-02
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Android handset
- Key security
- tee
- OS version
- 15.0.0
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Confidential GPU node
- Checked against
- GPU node (NVIDIA)
- Times seen
- 8
TPM 2.0 machine
- Checked against
- TPM 2.0
- What the hardware protects
- host-measured
- Times seen
- 1
GB202
- Checked against
- GPU node (NVIDIA)
- What the hardware protects
- device-level-tee
- Times seen
- 1
BLU
BLU B1660V
- Key security
- tee
- OS version
- 15.0.0
- Patch level
- 2026-03
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Google Pixel 11 Pro
- Key security
- strongbox
- OS version
- 17.0.0
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Google Pixel 7 Pro
- Key security
- strongbox
- OS version
- 13.0.0
- Patch level
- 2022-10
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Intel
Intel GB202
- Checked against
- GPU node (NVIDIA)
- What the hardware protects
- device-level-tee
- Times seen
- 1
OPPO
OPPO CPH2721
- Key security
- tee
- OS version
- 15.0.0
- Patch level
- 2025-02
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
OnePlus
OnePlus CPH2691
- Key security
- strongbox
- OS version
- 15.0.0
- Patch level
- 2024-12
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
OnePlus
OnePlus CPH2767
- Key security
- strongbox
- Patch level
- 2025-11
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
motorola
motorola marvel
- Key security
- tee
- Patch level
- 2026-01
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
motorola
motorola nevada
- Key security
- tee
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
samsung
samsung SM-A176B
- Key security
- tee
- Patch level
- 2025-09
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
samsung
samsung SM-F946B
- Key security
- strongbox
- OS version
- 13.0.0
- Patch level
- 2023-08
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
samsung
samsung SM-F956B
- Key security
- strongbox
- OS version
- 14.0.0
- Patch level
- 2024-06
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
samsung
samsung SM-X736B
- Key security
- strongbox
- Patch level
- 2025-08
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 2
vivo
vivo V2437
- Key security
- tee
- OS version
- 15.0.0
- Patch level
- 2025-04
- Checked against
- Android Key Attestation
- What the hardware protects
- key-custody-only
- Times seen
- 1
Apple App Attest
13 accepted, 6 rejected.
What this class of device cannot prove:
- accelerator-state: no claim about any GPU or neural engine on the device ×19
- boot-state: no verified-boot or bootloader claim; a jailbroken device is not distinguished from a clean one ×19
- device-identity: no model, no serial number, no hardware identifier -- a device matrix cannot be built from this evidence ×19
- os-patch-level: no security patch level is reported, so a device several releases behind is indistinguishable from a current one ×19
- os-version: App Attest reports no operating system version at all ×19
- workload-code-measurement: no hash of any executed job is covered by the signature ×19
- workload-memory-isolation: the app runs in ordinary iOS userspace; the Secure Enclave holds the key but does not execute the workload ×19
- physical continuity over time: apple-app-attest publishes no hardware counter that increments on power cycle, so there is no way to show this device has not been powered down and altered between attestations ×13
- secure-mode: the key access policy attaches no secure-mode constraint, so System Integrity Protection and full security mode are neither proved nor disproved ×2
AWS Nitro Enclaves
1 accepted, 0 rejected.
What this class of device cannot prove:
- enclave-logic-correctness: PCRs measure what code was loaded, not whether that code is trustworthy ×1
- isolation-measurement: the PCRs measure the enclave image, kernel, application, parent instance and IAM role. Memory isolation from the parent instance is a property AWS designs and asserts; this document does not measure it ×1
Android Key Attestation
34 accepted, 34 rejected.
What this class of device cannot prove:
- runtime-continuity: evidence describes device state at attestation time only; the device may change afterwards ×68
- workload-memory-isolation: the job runs in the Android rich OS, not inside TrustZone; integrity is inferred from verified boot, not enforced ×68
- how strongly the calling app is proven: attestationApplicationId is asserted by the Android Keystore daemon, which is privileged software, not by the secure element. It was checked against this coordinator's allowlist and matched; it is not a hardware-signed statement ×26
- physical continuity over time: google-android-key-attestation publishes no hardware counter that increments on power cycle, so there is no way to show this device has not been powered down and altered between attestations ×26
- whether this device agrees with its boot key about what device it is: the attestation carries no hardware-enforced brand or model, so the comparison was not made. The app must request device-property attestation for it to be possible ×5
- certificate-encoding: 1 certificate(s) in this chain encode an extension's critical flag in a form DER does not permit, and were read leniently. No check was relaxed and every signature was verified over the original bytes, but the encoding is out of spec and this device should not read as identical to one whose encoding is correct ×3
- os-identity: verified boot did not pass, so no statement about which operating system is running is enforced by anything ×3
GPU node (NVIDIA)
2 accepted, 8 rejected.
What this class of device cannot prove:
- availability: the host can reset or withhold the GPU at any time ×2
- physical continuity over time: gpu-node-nvidia publishes no hardware counter that increments on power cycle, so there is no way to show this device has not been powered down and altered between attestations ×2
- side channels: memory encryption does not rule out timing and cache side channels ×2
- software loaded after launch: MRTD covers the TD's initial image, and the RTMRs record only what the guest chose to extend into them ×2
- the CPU model: the certificate names the platform only by its FMSPC code, not by a product name ×2
- collector-image-integrity: the binding proves which GPU reports this confidential VM gathered, under the CPU vendor's own signature, and not that the image doing the gathering is honest. Its launch measurement is what covers that, and a policy should pin workload.measurement ×1
- firmware currency: the platform and TDX module TCB levels were not appraised against Intel's published TCB info, so this says the platform is genuine, not that it is patched ×1
- gpu-job-placement: this names the GPUs this node attested, not the one any particular job is placed on, and not that a job is given a GPU at all. Nothing in this evidence is a statement about scheduling ×1
- revocation: Intel's certificate revocation lists for the PCK chain were not checked ×1
- revocation: a platform Intel has revoked is not detected, because that is published through the same TCB info that was not consulted ×1
- the Quoting Enclave's identity: its MRSIGNER, ISVPRODID and ISVSVN were not compared against Intel's published QE identity, so this says the QE was vouched for by a genuine PCK certificate, not that it is the QE Intel ships. A debug-mode QE IS refused ×1
TPM 2.0
1 accepted, 0 rejected.
What this class of device cannot prove:
- boot-component-identity: the PCR values are digests of whatever was measured into them, not names. Without the TCG event log, which this evidence does not carry, they cannot be decoded into the firmware, bootloader or kernel that produced them; they can only be compared against a value the reader recorded themselves ×1
- device-identity: no model, serial number or platform identifier beyond the chip this attestation key was enrolled against ×1
- operator-visibility: isolation is host-measured. An administrator of this machine can read anything it runs. These measurements describe how it booted, not who can see inside it ×1
- reset-and-restart-totals: TPM 2.0 obfuscates resetCount, restartCount and firmwareVersion when the attestation key sits outside the endorsement or platform hierarchy. tpm.ak_hierarchy reports where this key was derived, but the agent asserts that and a quote cannot prove it, so these three are never readable as counts ×1
- runtime-continuity: no statement about any moment after this quote was produced. The machine could have changed a second later ×1
- secure-boot-state: PCR 7 records secure-boot policy measurements and is not decoded here, so no claim is made about whether secure boot was enabled ×1
- selected-registers-only: only the registers named in tpm.pcr_selection are covered by this signature. Anything measured into any other register, including those an operating system uses for its own components, is outside it ×1
- unmeasured-code: a TPM records only what was measured into it. Anything loaded without being measured, including any process started after boot, leaves no trace in these values ×1
- workload-code-measurement: no hash of any job this machine ran is covered by this signature ×1
- workload-memory-isolation: a TPM holds keys and measurements and does not execute the workload, so nothing here separates one job's memory from another's or from the operating system ×1
Why devices were turned away
Rejections
| Checked against | Reason | Seen |
|---|---|---|
| Android Key Attestation | this evidence names an accepted package but is signed by a certificate this coordinator does not accept; a package name alone is not an identity, because anyone can build an app with any package name | 6 |
| GPU node (NVIDIA) | confidential VM: sevsnp: report is 0 bytes, want 1184 | 5 |
| Apple App Attest | apple: authenticator data extensions are malformed: apple_validation_category_01 is not an unsigned integer | 3 |
| Android Key Attestation | cert chain order: android: ambiguous chain order (2 candidate leaves) | 3 |
| Android Key Attestation | cert chain: x509: malformed extension critical field | 3 |
| Android Key Attestation | chain does not verify to a pinned root: x509: certificate signed by unknown authority | 3 |
| GPU node (NVIDIA) | confidential VM: revocation: tdx: Intel's revocation service answered 404 Resource Not Found | 3 |
| Android Key Attestation | this evidence was produced by UnknownPackage, which is not an application this coordinator accepts | 2 |
Generated from our verification records on Sun, 25 Oct 2026 22:05:58 UTC. Every value shown here was approved by a person before publication. No device identifier appears in this data. No node id, no subject, no certificate, and no network address, because we do not record one. Identical machines are counted together, so a row describes hardware and not a particular device. 405 values reported by devices have not been approved for publication and are not shown.
Verification is live. Execution is not.
The coordinator has accepted GPU node evidence since 1 October 2026, and the appraisal has run against real signed attestation reports: an NVIDIA H100, a Blackwell report, and an eight-GPU protected-PCIe report. That is verification of what the hardware says about itself, checked against roots built into the verifier.
Execution is a different thing, and that difference matters more than anything else on this page. Two of our own jobs have run on a confidential GPU, on 19 October 2026 through the production coordinator. No customer workload has, no benchmark exists, and no supported GPU configuration is being announced here. Those are separate claims, and we are making only the first one.
Compare attestation boundaries