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 — configured security-relevant events: 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.

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. Approov's attestation service issues vendor-signed verdicts on the same checkpoint surface as Play Integrity / App Attest; EEI sits alongside, signing the trajectory.

comparison · EEI vs platform attestation

Bookend, meet trajectory.
Attestation is discrete. EEI is event-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 — configured security-relevant events: credential use, biometric, payload assembly, request submission — between credential and network receipt.
Temporal scope	Discrete trust assertions — each call proves device state at that moment. Re-attestation on sensitive flows adds checkpoints; the execution sequence between calls is not captured.	Ordered and hash-linked. Signed record across the full transaction flow, from the attested bookend through every event to submission.
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	Each call covers the moment of the call. Re-attestation on sensitive flows adds checkpoints; the execution trail between calls remains outside attestation's scope.	Configured security-relevant events — credential use, biometric, payload assembly, network change, submission — each 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; attestation coverage varies operationally in heterogeneous Android fleets and markets with inconsistent Play Services conditions.	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.	Emerging category; consumes the attestation trust basis and signs the trajectory that follows.

where they compose

Attestation gives the trust checkpoint. YinkoShield carries that trust basis forward as signed execution evidence across the transaction flow.

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 event — credential use, biometric, payload assembly, network change, submission — with a key bound to the device's platform key store.

What the trust basis declaration links them — the operator's policy engine defines the translation from platform verdict to trust-basis label; the reference mappings below are the defaults:

Play Integrity returns MEETS_STRONG_INTEGRITY → EEI Evidence Tokens for that session declare trust_basis = hardware_backed (by default policy).
App Attest passes → EEI declares trust_basis = hardware_bound (by default policy).
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)

Reference defaults. The operator's policy engine defines the mapping from platform verdict to trust-basis declaration; operators — or schemes — may override these defaults.

In heterogeneous Android fleets — particularly in markets with many entry-tier OEMs and inconsistent Play Services conditions — attestation coverage can vary operationally. EEI's hardware-bound key still produces strong evidence on those devices when the platform key store 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 — configured security-relevant events: 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?: Even when re-attestation is called during sensitive flows, each call is a discrete trust assertion — it proves the device state at that moment but does not capture the execution sequence between calls: credential use, biometric, payload assembly, network change, retry. EEI signs each of those events as they happen, hash-linked to the previous one, producing an ordered, signed execution trail 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. Approov's attestation service issues vendor-signed verdicts on the same checkpoint surface as Play Integrity / App Attest; EEI sits alongside, signing the trajectory.

going deeper

Two questions this page raises but does not answer in full:

What is the minimum event schema for a payment flow?: Event type, timestamp source, key ID, trust basis, monotonic sequence number, previous hash, nonce/context binding, app version, policy version, verifier result — the normative field definitions and value constraints are in the YEI-001 specification. The Evidence Token format article covers the public required-claim set.
Who provisions the keys — and what happens on reinstall, device migration, or TEE reset?: Key generation, hardware-backing guarantees, destruction on factory reset, and the bootstrap attestation chain are covered in Local key custody — device, operator, and vendor boundaries.
Where does the trajectory map onto explicit regulatory obligations?: Attestation alone does not address the authentication-code-to-(amount, payee) binding required by PSD2 RTS Article 5. The signed payload-assembly trajectory does — mapped verbatim in EEI and PSD2 SCA.

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.

Map your existing attestation deployment to EEI signals

Bookend, meet trajectory. Attestation is discrete. EEI is event-continuous.