Is EEI a replacement for platform attestation?

No. Attestation establishes that the device is in a trusted state at a checkpoint — typically when the app starts, or when a sensitive flow begins. EEI establishes what the device did between checkpoints — every credential use, biometric, payload assembly, request submission. The two are designed to compose: attestation is the bookend, EEI is the trajectory.

What does Play Integrity / App Attest do that EEI does not?

Platform-attestation services issue a vendor-signed token confirming that the device, app, and OS are in a known-good state at the moment of the call. They are also the route to hardware-rooted device identity in the platform's chain of trust. EEI does not replicate that platform-vendor relationship; it consumes the trust basis the platform declares and signs the runtime trajectory that follows.

What does EEI do that attestation does not?

Attestation tells you the device passed an integrity check at one moment. It does not tell you what happened during the next 30 seconds — credential use, biometric, payload assembly, network swap, retry. EEI signs each of those events as they happen, hash-linked to the previous one. The result is a continuous, ordered, signed record of execution that downstream consumers (issuer, scheme, dispute platform) can verify against.

Yes — and most production deployments do. Attestation establishes the trust basis at session start (`hardware_backed`, `hardware_bound`, `software_layer`); EEI carries that trust basis forward in every signed event, declared in the Evidence Token. The operator's policy engine reads both: attestation gives the bookend, EEI gives the path.

Why does the verification path matter?

Attestation tokens are typically verified back to the platform vendor's service or against the vendor's certificate chain. EEI tokens are verified against operator-stored public keys, in the operator's stack, with no YinkoShield endpoint in the path. That matters when the consumer is a regulator, a scheme, or a partner who isn't part of the platform-vendor relationship — they can verify EEI directly without coordinating with Apple, Google, or Samsung.

comparison · EEI vs platform attestation

Bookend, meet trajectory.
Attestation is point-in-time. EEI is continuous.

Play Integrity, App Attest, SafetyNet, hardware-backed Keystore attestation — these establish that the device is in a trusted state at a moment. EEI establishes what the device did between those moments. The two compose; neither replaces the other.

short answer

Platform attestation is the bookend — vendor-signed proof that the device, app, and OS are in a known-good state at one moment. EEI is the trajectory — operator-signed proof of what the runtime did between bookends, hash-linked, ordered, verifiable without YinkoShield in the path.

bookend vs trajectory

Two pillars. Five signed events between them. One declared trust basis throughout.

Attestation is point-in-time. EEI is continuous. The attested trust basis is carried forward in every Evidence Token between bookends — no re-call to Play Integrity / App Attest per event.

side by side

What each one proves. What each one does not.

Dimension	Platform attestation	EEI
What it proves	The device was in a trusted state at the moment of the attestation call (hardware integrity, OS integrity, app integrity).	The device's runtime trajectory — every credential use, biometric, payload assembly, request submission — between credential and network receipt.
Temporal scope	Point-in-time. One attestation = one bookend.	Continuous and ordered. Hash-linked record across the full transaction flow.
Who issues the trust	The platform vendor (Google, Apple, Samsung, the OEM's TEE vendor).	The operator-registered device key, generated in the device's TEE at first init. The vendor relationship is at bootstrap; YinkoShield is not in the path.
Who verifies	Vendor service or vendor certificate chain — Google Play Integrity API, Apple App Attest service, OEM-specific endpoints.	The operator's stack, against operator-stored public keys. No YinkoShield endpoint in the verification path.
Output shape	Vendor-signed integrity verdict (PASS / FAIL with details). Bound to the vendor's verification chain.	Signed Evidence Token (~200 bytes JWS-compact ES256) carrying signal classes and trust basis declaration.
Trust-basis declaration	Vendor-defined verdict categories (e.g. `MEETS_DEVICE_INTEGRITY` / `MEETS_BASIC_INTEGRITY` / `MEETS_STRONG_INTEGRITY` for Play Integrity).	`hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, `software_layer` — declared inline in every Evidence Token, never inferred.
Coverage between checkpoints	None — what happens after the attestation call until the next call is unobservable.	Continuous — every significant event signs and references its predecessor's hash.
Cross-platform consistency	Each platform vendor has its own attestation API, its own verdict shape, and its own SLA.	Same Evidence Token shape across Android, iOS, POS, SoftPOS, SST. One verifier handles the entire estate.
Vendor coverage	Google (Play Integrity), Apple (App Attest), Samsung Knox, OEM-specific (Huawei, Xiaomi, MediaTek). Each emits its own verdict shape; coverage on entry-tier OEMs (Tecno, Infinix, itel) is inconsistent.	Vendor-agnostic. Same Evidence Token across every Android OEM, iOS, POS firmware, SST. One verifier handles every device the operator's app runs on.
Adoption pattern	Mature; required by many scheme programs and OS distribution policies.	New category; consumes the attestation trust basis and signs the trajectory that follows.

where they compose

Attestation gives the bookend. EEI carries it forward.

A typical Tier-1 deployment runs both. Platform attestation runs at session start — the operator's app calls Play Integrity (Android) or App Attest (iOS), receives a vendor-signed verdict, and uses it to decide whether the session may proceed. EEI runs continuously thereafter, signing each significant event with a key bound to the device's TEE.

What the trust basis declaration links them:

Play Integrity returns MEETS_STRONG_INTEGRITY → EEI Evidence Tokens for that session declare trust_basis = hardware_backed.
App Attest passes → EEI declares trust_basis = hardware_bound.
Attestation soft-fails (rooted device, custom ROM, emulator) → EEI declares trust_basis = compromised_device or software_layer, and signs anyway. The operator's risk engine reads both signals and decides.

The operator's verifier sees one continuous signed sequence, starting from the attested bookend, with the trust basis carried forward in every event. The dispute platform, the issuer, and the regulator can replay that sequence independently — none of them needs to re-call Play Integrity or App Attest.

Platform verdict	EEI `trust_basis` declared
Play Integrity `MEETS_STRONG_INTEGRITY`	`hardware_backed`
Play Integrity `MEETS_DEVICE_INTEGRITY`	`hardware_bound`
App Attest assertion verified	`hardware_bound`
Attestation soft-fail (rooted, custom ROM, emulator)	`compromised_device` or `software_layer`
Attestation unavailable (entry-tier OEM, no Play Services)	`software_layer` or `execution_proof` (declared honestly)

In markets where Tecno, Infinix, itel, and other entry-tier OEMs dominate, platform attestation verdicts are inconsistent or unavailable. EEI's hardware-bound key still produces strong evidence on those devices when the TEE is present, and declares software_layer honestly when it is not. The operator's risk engine reads the declaration; the substrate does not infer.

frequently asked

Five questions, five answers.

·01 Is EEI a replacement for platform attestation?: No. Attestation establishes that the device is in a trusted state at a checkpoint — typically when the app starts, or when a sensitive flow begins. EEI establishes what the device did between checkpoints — every credential use, biometric, payload assembly, request submission. The two are designed to compose: attestation is the bookend, EEI is the trajectory.
·02 What does Play Integrity / App Attest do that EEI does not?: Platform-attestation services issue a vendor-signed token confirming that the device, app, and OS are in a known-good state at the moment of the call. They are also the route to hardware-rooted device identity in the platform's chain of trust. EEI does not replicate that platform-vendor relationship; it consumes the trust basis the platform declares and signs the runtime trajectory that follows.
·03 What does EEI do that attestation does not?: Attestation tells you the device passed an integrity check at one moment. It does not tell you what happened during the next 30 seconds — credential use, biometric, payload assembly, network swap, retry. EEI signs each of those events as they happen, hash-linked to the previous one. The result is a continuous, ordered, signed record of execution that downstream consumers (issuer, scheme, dispute platform) can verify against.
·04 Can I use both?: Yes — and most production deployments do. Attestation establishes the trust basis at session start (`hardware_backed`, `hardware_bound`, `software_layer`); EEI carries that trust basis forward in every signed event, declared in the Evidence Token. The operator's policy engine reads both: attestation gives the bookend, EEI gives the path.
·05 Why does the verification path matter?: Attestation tokens are typically verified back to the platform vendor's service or against the vendor's certificate chain. EEI tokens are verified against operator-stored public keys, in the operator's stack, with no YinkoShield endpoint in the path. That matters when the consumer is a regulator, a scheme, or a partner who isn't part of the platform-vendor relationship — they can verify EEI directly without coordinating with Apple, Google, or Samsung.

Operators that already run Play Integrity or App Attest get the most from a 60-minute mapping briefing.

We map your existing attestation verdicts to EEI's trust-basis declarations and show how the runtime trajectory continues past the attestation call. You keep the attestation, you add the trajectory.

Request a briefing

Bookend, meet trajectory. Attestation is point-in-time. EEI is continuous.