The scope of these results
Device evidence, examined.
Our Android prototype requests a server-issued challenge, receives a device certificate chain, and checks the evidence against pinned trust roots and revocation information. These observations concern attestation, not compute performance or workload confidentiality.
Accepted means the evidence passed the verifier in the recorded test. A customer policy can still reject that device. These outcomes are specific observations, not certification of an entire model family.
Five physical devices
What we observed
Samsung
S22 Ultra
SM-S908U
- Key security
- StrongBox
- OS noted
- Android 16
- Trust path
- RSA attestation chain
Dedicated secure-element backing was reported. A StrongBox policy can distinguish this result from TEE-only evidence.
Motorola
Moto G Play 2026
XT2615-1
- Key security
- TEE
- OS patch observed
- June 2026
- Trust path
- RKP / ECDSA chain
Hardware-backed evidence was accepted. This result does not satisfy a requirement for StrongBox-backed keys.
Samsung
Galaxy Tab A9+
SM-X210
- Key security
- TEE
- OS observed
- Android 16, patch June 2026
- Trust path
- Pinned Google root
Eight hardware-enforced claims were returned, including bootloader and vendor patch levels that the Lenovo evidence did not carry.
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. A locked bootloader and a verified boot state were reported, both hardware-enforced.
Sony
Xperia
G3223
- Attestation security
- Software
- Reported key security
- TEE
- Trust path
- No accepted pinned root
A reported TEE key level was insufficient. The evidence did not establish a trusted hardware attestation chain.
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 checking only verified boot would miss that difference.
Missing fields need explicit handling.
The Motorola evidence omitted the attested model field that appeared in the Samsung evidence. In our policy engine, a missing required claim fails the rule; it is never silently treated as satisfied.
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, both sit at key custody only — and they do not carry the same evidence. A policy requiring a vendor patch level would reject one of them for a reason unrelated to how trustworthy it is.
Certificate expiry is not a freshness mechanism.
The Lenovo attestation certificate carries no expiry at all, while Samsung certificates in these tests expired within roughly thirty minutes. Freshness therefore rests on the server-issued challenge and our own maximum attestation age, never on the certificate validity window.
Datacenter validation comes next.
GPU integration and configuration testing remain in development. No GPU benchmark, confidential-execution result, or supported GPU configuration is being announced here.
Compare attestation boundaries