EUDI App Attestation Choices: AppiCrypt vs. Google Play Integrity & Apple App Attest

The EUDI Wallet secures the user's identity, but AppiCrypt is what secures your Relying Party app against clones, mods, and malicious automation.

The eIDAS 2.0 Architecture 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.

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 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 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 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 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.

Google Play Integrity API

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.

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).

Concern	Play Integrity	App Attest	AppiCrypt
Android	✅	—	✅
iOS	—	✅	✅
Works without Google Play Services	❌	n/a	✅
Per-request gating model	Token-per-request (with quotas)	Stored key + signed assertions	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 token as the cross-platform attestation

2. a 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®".

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