# EUDI App Attestation Choices: AppiCrypt vs. Google Play Integrity & Apple App Attest
The [eIDAS 2.0 Architecture Reference Framework](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-architecture-and-reference-framework) treats **the wallet** as the security anchor on the user side. **Your Relying Party app is not part of that anchor.** Which means:
* ⚠️ Malicious clone of your RP app can issue OpenID4VP requests that look identical.
* ⚠️ Hooked (Frida) app can hook `verifyPresentation()` and lie to your backend.
* ⚠️ Scripted automation tool can hammer your enrollment endpoint with attested user wallets.
App attestation answers exactly one question: **"Is the request really coming from a genuine, unmodified instance of my app?"** If you cannot answer that question with cryptographic confidence, every other RP-side control is paper-thin.
{% hint style="info" %}
This multi-part series is built for CTOs, architects, and mobile developers. We break down the regulatory clock, the architectural shifts, and the hands-on implementation details required to close the mobile security gap.
**Explore the complete series:**
* **Part 1:** [Build a Secure EUDI Wallet Relying Party](/appsec-articles/articles/eudi-guide-build-a-secure-eudi-wallet-relying-party.md) An overview of the new eIDAS 2.0 landscape, the mobile threat surface nobody warned you about, and how to map regulatory obligations to your security stack.
* **Part 2:** [EUDI Wallet Integration: A CTO's Decision Guide](/appsec-articles/articles/eudi-wallet-integration-a-ctos-decision-guide.md) A strategic roadmap covering implementation timelines, the shift from real-time IdP callbacks to offline verification, and the privacy requirements your DPO needs you to know.
* **Part 3:** [Secure EUDI Wallet Integration for Mobile Developers](/appsec-articles/articles/eudi-developer-guide-secure-eudi-wallet-integration-for-mobile-developers-arf-dcql-2026-2027.md) A hands-on implementation guide for securing the OpenID4VP flow, writing GDPR-compliant DCQL queries, and setting up robust backend verification gates.
* **Part 4:** [App Attestation for EUDI Relying Parties](/appsec-articles/articles/eudi-app-attestation-choices-appicrypt-vs.-google-play-integrity-and-apple-app-attest.md) A deep dive into platform attestation: AppiCrypt, Google Play Integrity and Apple App Attest , and how to build a resilient, cross-platform attestation strategy.
*Disclaimer for full transparency: This article utilizes Talsec technology. We know we aren't the only vendor in the mobile security space. But we are the one running on 2,000,000,000 devices. We’ve protected more apps than there are cars on Earth. It's safe to say we know what we're doing.*
{% endhint %}
### Google Play Integrity API
{% hint style="warning" %}
Google Play Integrity API frequent service downtimes and rate limiting can break your verification flows. It is prone to unpredictable failures, so integrate it only as an optional, secondary security check.
{% endhint %}
No discussion of app attestation would be complete without mentioning Google's native attestation service. While the underlying concept of an OS-vendor signal is fundamentally sound, the real-world execution has historically fallen short. Plagued by frequent **API downtimes** and restrictive **rate limiting**, it is effectively ruled out as a primary security layer for most serious businesses.
The Play Integrity backend signs an **integrity verdict** that includes `requestDetails`, `appIntegrity`, `deviceIntegrity` (legacy: `deviceRecognitionVerdict`), and `accountDetails`.Your client requests a token from Play Integrity, sends it to your backend, your backend asks Google to **decode the token** (or you decrypt locally), and you read the verdict labels.Here are considerations:
* **Strengths.** First-party signal from the OS vendor. Free at low volume.
* **Weaknesses for an EUDI RP.**
* **Requires Google Play Services.** Useless on Huawei devices, on AOSP, on
* enterprise builds, and on parts of the EU long-term sovereignty roadmap.
* **Verdict labels are coarse.** `MEETS_DEVICE_INTEGRITY` hides a lot. You
* cannot, for example, distinguish *clean stock* from clean
* rooted-but-Magisk-hidden.
* **Quota and latency** are real production concerns.
* **No cross-platform symmetry.** Different model on iOS.
### Apple App Attest
Apple's per-device, per-app attested key pair, anchored in the Secure Enclave.
* **How verification works.** **There is no live Apple verification API.** Your app calls App Attest once to get an attestation object. Your backend validates the object locally against Apple's published roots, stores the resulting attested public key, and thereafter verifies signed assertions from that key on every sensitive request. That stored key *is* your proof of authenticity.
Here are the considerations:
* **Strengths.** Hardware-anchored, low overhead per request after enrollment.
* **Weaknesses for an EUDI RP.**
* **iOS only.**
* **Operationally heavier than it looks:** you must persist and rotate attested keys, handle device migration, and reason about App Attest "fraud" assertions.
* **No detection of jailbreak, hooking, or malware:** App Attest tells you the **key is genuine**, not that the **runtime is clean**.
### Talsec AppiCrypt®
Talsec's **cross-platform** API protection and app and device-integrity verification layer. Each API call carries a unique cryptographic proof/signature, which is verified on the backend.Here are the considerations:
* **Strengths for an EUDI RP.**
* **Same SDK and same verification model on Android and iOS (or website).** One mental model, one backend code path.
* **No dependency on Google Play Services or Apple's online services.** Works on any Android distribution, including EU-sovereign builds.
* **Can be combined with RASP signals** for a stronger runtime-aware policy decisions.
* **Designed for per-request API gating**, which maps well to high-risk RP actions (presentation, issuance, signature authorization).
|
Token-per-request (no third-party online dependency)
|
|
Tied to RASP runtime view
|
❌
|
❌
|
✅
|
|
EU sovereignty story
|
Weak
|
Weak
|
Strong
|
|
Free tier
|
Yes (rate-limits)
|
Yes
|
Starter plan available
|
### The pattern we recommend for EUDI RPs
**Use AppiCrypt as your primary gate.** Optionally, **layer Play Integrity / App Attest as a secondary signal** when you want OS-vendor corroboration. The order matters: In practice, each mobile request should carry three security inputs:
1. an [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt) token as the cross-platform attestation
2. a [RASP](https://docs.talsec.app/premium-products/product/rasp) on the app side
3. an optional Play Integrity or App Attest signal as secondary corroboration;
Your backend should verify all available inputs before forwarding the request to the wallet flow (OpenID4VP), then optionally enrich the decision with your selected risk/telemetry service.Why **AppiCrypt first**: it's the one that doesn't break the moment a user installs your app on a Huawei phone, an EU sovereign Android build, or an enterprise-managed iPad with strict network egress. We have also published another article if you want to learn details: "[**Mobile API Anti-abuse Protection with AppiCrypt®**](https://docs.talsec.app/appsec-articles/articles/mobile-api-anti-abuse-protection-with-appicrypt-r-a-new-play-integrity-and-devicecheck-alternative)".
### Conclusion
For EUDI relying parties, app attestation is a core trust gate for every sensitive flow. A practical setup is to enforce AppiCrypt on every request, optionally enrich decisions with Play Integrity or App Attest signals, and always combine attestation with runtime risk checks.
*written by Majid Hajian*
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.talsec.app/appsec-articles/articles/eudi-app-attestation-choices-appicrypt-vs.-google-play-integrity-and-apple-app-attest.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.