# EUDI Wallet Integration: A CTO's Decision Guide

Your engineering team is about to ask you whether EUDI Wallet is a 2026 problem or a 2027 problem. The honest answer is: it's a **now** problem. The [Architecture and Reference Framework (ARF)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework) is stable, wallets are in pilot, and teams that start integration in late 2026 will be late. This guide covers the decisions you need to make, not the implementation details your developers handle.

<figure><img src="/files/gaR8AniTZfiTWsiMU9jI" alt=""><figcaption></figcaption></figure>

{% 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/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 %}

### The Regulatory Clock

[Regulation (EU) 2024/1183](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1183) (eIDAS 2.0) is already in force. Dates below for engineering milestones:

| <p>2025</p><p> </p><p> </p>     | <p>ARF stable, pilots underway, reference wallets live</p><p> </p><p> </p> | <p>Architecture decisions, RP registration plan</p><p> </p><p> </p> |
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| <p>2026</p><p> </p><p> </p>     | <p>Certified wallets available in Member States</p><p> </p><p> </p>        | <p>Integration in dev/staging, pen testing</p><p> </p><p> </p>      |
| <p>End 2026</p><p> </p><p> </p> | <p>Public services accept wallets</p><p> </p><p> </p>                      | <p>Production readiness for regulated RPs</p><p> </p><p> </p>       |
| <p>End 2027</p><p> </p><p> </p> | <p>Regulated private-sector RPs expected to accept</p><p> </p><p> </p>     | <p>Delivery deadline for banking, telco, VLOPs</p><p> </p><p> </p>  |

**Who must act by 2027?**  Any of the following apply to your company, EUDI Wallet acceptance is a regulatory obligation:

* Banking, payments, or any PSD2 Strong Customer Authentication (SCA) flow
* Very Large Online Platform under the Digital Services Act (DSA)
* Telco SIM registration or contract execution
* Any service legally requiring strong user authentication for online
* identification (health, education, finance, infrastructure)

### What Actually Changes in Your Architecture

EUDI is not a new OAuth provider you add to your SSO. The trust model is fundamentally different.

<figure><img src="https://t9012551331.p.clickup-attachments.com/t9012551331/154179f0-dbaa-4eb1-a987-c85b50391c6e/ecosystem-diagram-simple.webp" alt=""><figcaption></figcaption></figure>

**Traditional identity (OAuth/OIDC):** User logs in → your app redirects to Google/bank/IdP → IdP authenticates the user → IdP calls back to confirm.

<mark style="background-color:$success;">**EUDI identity:**</mark> <mark style="background-color:$success;"></mark><mark style="background-color:$success;">User presents a credential from their wallet → your backend verifies the cryptographic signature</mark> <mark style="background-color:$success;"></mark><mark style="background-color:$success;">**offline**</mark><mark style="background-color:$success;">, against public keys in the</mark> [<mark style="background-color:$success;">EU Trusted Lists</mark>](https://esignature.ec.europa.eu/efda/tl-browser/) <mark style="background-color:$success;">→ no callback to the issuer, ever.</mark>

The power of that model also lies in its architectural implication: **you own verification entirely**. The issuer (a Member State government) signed the credential. Your backend checks that signature. There is no third-party real-time validation call. No fallback if your trust list is stale.This shifts operational responsibility onto your team for:

* Fetching and caching EU Trusted Lists (refresh daily)
* Verifying credential signatures, disclosure hashes, and holder binding
* Checking credential revocation on every presentation
* Managing your RP registration certificate

### The Security Gap and Why It's Your Problem

Here is the part that the protocol specification does not resolve: **a stolen credential from a compromised device passes every cryptographic check.**&#x54;he credential is real. The signature is valid. The issuer stands behind it. But if the device presenting it is rooted, the app has been repackaged, or malware overlays the consent screen, the protocol cannot tell you. You can.

<figure><img src="https://t9012551331.p.clickup-attachments.com/t9012551331/8a0c5a1d-7ea2-4440-83b5-53a596a6e3af/integration-architecture.webp" alt=""><figcaption></figcaption></figure>

The three attack vectors that live outside the protocol:

| <p>Rooted / jailbroken device</p><p> </p><p> </p> | <p>Attacker extracts credentials or intercepts the presentation flow</p><p> </p><p> </p>       | <p>❌ No</p><p> </p><p> </p> |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------- |
| <p>Overlay attack</p><p> </p><p> </p>             | <p>Malware covers the wallet consent screen; user approves the wrong thing</p><p> </p><p> </p> | <p>❌ No</p><p> </p><p> </p> |
| <p>Repackaged RP app</p><p> </p><p> </p>          | <p>Modified app routes credentials to attacker's server</p><p> </p><p> </p>                    | <p>❌ No</p><p> </p><p> </p> |

This gap is yours to close. The regulation requires RPs to "protect the rights and interests of natural persons"; the mechanism is yours to choose.

### Your Security Stack Decision

Three layers of protection, stacked. Pick based on your risk exposure:

#### Layer 1: Platform Attestation

[Talsec’s AppiCrypt®](https://docs.talsec.app/premium-products/product/appicrypt) is recommended as primary, cross-platform attestation gate. In contrast to the platform solutions like Play Integrity (Android) or App Attest (iOS), AppiCrypt operates with the same SDK and verification model on both Android and iOS and works independently of Google Play Services or Apple’s online services. By binding every API call to a cryptographic snapshot of the device security state and embedding RASP threat flags, AppiCrypt provides a much stronger, runtime-aware posture designed for per-request API gating—crucial for high-risk EUDI actions.

**What this gives you:** app genuineness, device hardware attestation, one-time challenge binding.

#### Layer 2: Runtime Protection

[RASP](https://docs.talsec.app/premium-products/product/rasp) continuously monitors the app's runtime environment: rooting, hooking frameworks (Frida/Xposed), debugger attachment, emulators, and repackaging. For higher-risk flows, RASP adds overlay detection, screen-mirror defense, and accessibility abuse monitoring, the vectors directly relevant to wallet consent screen attacks.

**What this doesn't give you:** real-time detection of rooting, Frida hooks, overlay malware, or runtime compromise after attestation.

#### Layer 3: API Integrity

[AppiCrypt®](https://docs.talsec.app/premium-products/product/appicrypt) binds every API call from your app to your backend with a cryptographic token (a "cryptographical snapshot" of device security state). Your backend verifies this token in real time, blocking cloned APKs, repackaged apps, and requests from compromised environments before you touch the credential. RASP threat flags are embedded in the same cryptogram. See the [AppiCrypt article](https://docs.talsec.app/appsec-articles/articles/mobile-api-anti-abuse-protection-with-appicrypt-r-a-new-play-integrity-and-devicecheck-alternative) for the full capability overview.

### Privacy and GDPR Posture

**The principle:** request only what you need for the specific use case. If you are verifying age, request `age_over_18` (a boolean, the user's birth date never leaves the device). If you need an identity for KYC, request only the claims your regulatory obligation requires, not the full credential.

Three non-negotiable data handling rules for your team:

1. **Never log the raw presentation token.** It contains disclosed PII. One line in a log file is a GDPR Article 5 violation.
2. **Never store the wallet's subject identifier as a user ID.** It enables cross-service tracking. Use a pairwise-derived identifier keyed to your domain.
3. **Discard claims you don't need to persist.** Verify them, act on the outcome, and store only what your service function requires.

Your DPO should review the DCQL queries your team writes before they ship.

### Sector-Specific Implications

**Banking and Fintech:** eIDAS 2.0 and PSD2 converge in the 2027 window. Wallet-based SCA replaces SMS OTP and hardware tokens with a stronger cryptographic guarantee; the wallet signs a commitment to the exact transaction amount and merchant. KYC onboarding via EUDI PID presentation eliminates video-ID costs while delivering a cryptographically verified result. Start the SCA migration architecture in 2026.

**Telecommunications:** SIM registration currently often requires storing passport photocopies and ongoing GDPR liability. EUDI selective disclosure lets you request only the claims national law mandates (name, date of birth, nationality) without building a passport archive. Contract execution via Qualified Electronic Signature (QES) in the wallet replaces PDF/wet-signature workflows at scale.

**E-Signatures / Trust Services:** A successful wallet credential presentation is **not** a Qualified Electronic Signature. Identity verification and document signing are legally separate operations on separate APIs. Ensure your product architecture keeps them distinct, or you will fail both security review and legal audit.

### Roadmap: Three Phases

Here is how you should think of thee phases of what to ship:

| **1: Protocol**   | OpenID4VP request/response, SD-JWT verification, Trust List integration, revocation | Start now      |
| ----------------- | ----------------------------------------------------------------------------------- | -------------- |
| **2: Hardening**  | AppiCrypt, RASP+ runtime protection                                                 | Before pilot   |
| **3: Production** | RP registration, pen testing, EUDI Launchpad interop validation, GDPR audit         | Before go-live |

<figure><img src="https://t9012551331.p.clickup-attachments.com/t9012551331/58e1bd02-c485-4b24-b89b-67abc8bbf52a/fig-11.webp" alt=""><figcaption></figcaption></figure>

### Questions to Ask Your Engineering Team

* Are we verifying the Key Binding JWT (`nonce`, `aud`, `iat`, `sd_hash`) on every presentation, not just the issuer signature?
* Are we checking credential revocation via Token Status List on every call?
* Are we refreshing the EU Trusted List cache daily?
* Have we run the eight negative-cryptography tests (tampered disclosure, reused nonce, wrong audience, revoked credential, etc.)?
* Is the raw `vp_token` excluded from all logging pipelines?
* Have we registered as a Relying Party in the relevant Member State trust ecosystem?
* Have we tested against the official EUDI reference wallet and the [EUDI Launchpad](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/924975727/EUDI+Wallets+Launchpad) interoperability program?

### Conclusion

EUDI Wallet is an infrastructure change with a regulatory deadline. The cryptographic model is more powerful than anything currently deployed at scale for identity, but it transfers verification responsibility entirely to you. The architecture is settled. The reference implementations exist. The tooling is available. The teams that plan now will ship on time.

*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-wallet-integration-a-ctos-decision-guide.md?ask=<question>
```

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.