7 min read
For several years, the European Digital Identity Wallet has been discussed largely in terms of regulation, architecture, standards and pilots.
In 2026, that conversation changes.
The European Digital Identity Regulation entered into force in May 2024. Under Article 5a, each EU Member State must provide at least one European Digital Identity Wallet within 24 months of the entry into force of the relevant implementing acts. The European Commission now summarises the practical milestone clearly: Member States must provide EUDI Wallets by the end of 2026.
That changes the questions development organisations need to ask. The challenge is no longer simply: What will an EUDI Wallet look like?
It is increasingly: Can the implementation we are building actually operate securely, interoperate across the ecosystem, pass the required assessments and remain trustworthy when deployed on millions of real mobile devices?
And that brings mobile application security for the European Digital Identity Wallet directly into the EUDI Wallet conversation.
Why 2026 Is the EUDI Wallet Implementation Deadline Development Teams Cannot Ignore
The regulatory foundation for EUDI Wallets is already in place.
Commission Implementing Regulations adopted in 2024 established detailed rules covering areas including wallet integrity and core functionality, protocols and interfaces, person identification data and electronic attestations of attributes, ecosystem notifications, and wallet certification.
Those specifications have continued to evolve. In July 2026, Commission Implementing Regulation (EU) 2026/1731 updated standards and specifications referenced by several of the original implementing regulations. The EUDI Architecture and Reference Framework, or ARF, subsequently reached version 3.0.0, aligning the architecture with those amended implementing acts and introducing the Functional Conformance Assessment Framework into the overall implementation picture.
The significance for engineering organisations is important. This is no longer a programme in which teams can postpone difficult implementation decisions while waiting for the regulatory architecture to stabilise completely. Implementations, reference applications, conformance work and certification mechanisms are progressing in parallel.
The European Commission's Functional Conformance Assessment Framework, for example, is designed to provide a harmonised way of testing whether wallet implementations behave according to applicable specifications. It covers interfaces, credential formats and mandatory wallet functionality, while explicitly noting that functional conformance is only one part of what is required for a compliant production wallet.
What the End-of-2026 EUDI Wallet Deadline Means for Secure Mobile App Development
Commission Implementing Regulation (EU) 2024/2981 defines a wallet solution as a combination of software, hardware, services, settings and configurations. It states that the certification object includes software components such as the wallet instance and requires certification schemes to map security controls to the components of the wallet architecture. Providers must also refine the common risk assessment with threats specific to their own implementation.
Security decisions affecting application design, device trust, authentication, secure storage, build pipelines, application integrity, backend enforcement, update mechanisms and runtime behaviour need to be considered while the system is being designed.
The regulation also establishes ongoing vulnerability-management obligations. Certification can be valid for up to five years, but vulnerability assessments are required every two years, while the certification framework additionally provides for surveillance, vulnerability notification, impact analysis and remediation processes.
Why EUDI Wallet Security Requires More Than Identity, Cryptography and Certification
Commission Implementing Regulation (EU) 2024/2979 requires wallet instances to use at least one Wallet Secure Cryptographic Device, or WSCD, to manage critical assets. It also contains requirements covering cryptographic keys, proof of possession, authentication and secure cryptographic operations.
But secure keys do not automatically mean a secure wallet.
The ARF describes the Wallet Instance as the application installed on the user's device. That application implements core business logic and interfaces and interacts with the secure cryptographic components used to protect critical assets and perform cryptographic operations.
Cryptographic controls can protect a private key from extraction. Signed credentials can provide integrity and authenticity. Secure hardware can ensure that particular cryptographic operations occur inside a protected environment.
But the application still has to decide when those capabilities are invoked, what is being requested, what the user sees, which service the wallet is communicating with and what data is being presented. An attacker therefore does not always need to break the underlying cryptography.
If the application execution environment can be manipulated, the attacker may instead attempt to alter application behaviour around otherwise legitimate cryptographic operations.
This is why EUDI Wallet security is simultaneously an identity problem, a cryptographic problem, a platform-security problem and an application-security problem. For teams building sensitive wallet apps, Cryptomathic MASC Core is relevant because it focuses on runtime protection, code and asset protection, secure storage and network hardening for high-risk Android and iOS applications.
Why Securing EUDI Wallet Credentials Is Not the Same as Securing the Mobile App
Consider two separate security objectives.
The first is credential and data security. This includes protecting private keys, maintaining credential integrity, protecting sensitive data at rest and in transit, authenticating issuers and relying parties, and ensuring that credentials cannot simply be copied and replayed.
The second is application execution security. An attacker may target the software around the protected credential rather than the cryptography protecting the credential itself.
The EUDI certification framework reflects this broader view. It explicitly includes software components such as the Wallet Instance in the certification scope and requires providers to define assumptions about the devices and platforms on which wallet software operates and to implement measures confirming that those assumptions remain valid in practice.
The latest ARF goes further at the operational level. Its high-level requirements call for wallet providers to monitor the security posture of operational Wallet Instances, with signals including rooting or jailbreaking, emulators, OS health, wallet software versions and relevant secure cryptographic components. It also requires analysis and potentially revocation where compromise of the wallet, mobile device, operating system or cryptographic environment affects trustworthiness.
The execution environment therefore cannot simply be treated as someone else's problem.
What Mobile App Threats Can Compromise EUDI Wallet Security?
A production wallet will operate on consumer devices that are physically controlled by users and potentially by attackers. That makes mobile applications fundamentally different from backend services running inside infrastructure controlled by the wallet provider.
Compromised devices can weaken assumptions about operating-system protections, application sandboxing, secure storage and authentication. Rooted or jailbroken devices may expose capabilities that would not normally be available to applications, which is why mobile app protection for iOS and Android needs to account for device-state signals as part of the wider wallet trust model.
Application tampering and repackaging can allow an attacker to modify an application binary, alter its resources or distribute a modified build. OWASP's Mobile Application Security Verification Standard specifically addresses application integrity and anti-tampering as part of its resilience controls.
Hooking and instrumentation allow attackers to interact with functions while an application is executing. Instead of modifying source code, an attacker may try to inspect parameters, change return values or intercept security-relevant calls dynamically.
Debugging and reverse engineering can reveal application logic, protocol handling, security decisions and sensitive client-side behaviour. OWASP's resilience guidance covers both resistance to static analysis and measures intended to make dynamic analysis and runtime instrumentation more difficult.
Runtime manipulation is particularly relevant because a cryptographically valid operation is not necessarily the same thing as an application flow that has executed as intended. Depending on the architecture, attackers may attempt to manipulate the circumstances surrounding credential issuance, presentation, authentication or signing rather than attacking the cryptographic primitive directly.
The EUDI risk model already recognises the broader categories behind these scenarios. The current ARF includes tampering, application-level errors, development-time errors, software vulnerabilities, supply-chain attacks and malware among its technical threats inside the Risk Registry.
OWASP is explicit that resilience measures such as obfuscation, anti-debugging, anti-tampering and Runtime Application Self-Protection are defence-in-depth mechanisms, not substitutes for sound security architecture. Their use should be driven by the application's threat model.
How to Build EUDI Wallet Mobile Security Earlier in the SDLC
Implementing Regulation 2024/2981 requires security controls to be mapped to architecture components, implementation-specific risks to be identified, an evaluation plan to be defined and vulnerability assessment to form part of the evaluation. For assurance level High, evaluation activities include testing resistance against attackers with high attack potential; where appropriate, they can also include review of design and source code.
- Threat modelling needs to influence architecture.
- Security requirements need acceptance criteria.
- Build and release processes need to preserve the properties that were evaluated.
- Dependencies need to be managed.
- Security testing needs to include the actual production artefact.
- And vulnerability response, application updates and minimum supported versions need to be part of the operating model from the beginning.
How EUDI Wallet Teams Can Balance Security, Interoperability and User Experience
Adding security controls indiscriminately is not the answer either. An EUDI Wallet has to operate across Member States, issuers, relying parties, devices and use cases. Interoperability is therefore a fundamental architectural requirement. At the same time, the European Commission identifies usability as one of the wallet's major challenges: wallets need to provide strong security while remaining intuitive and accessible enough that citizens actually use them.
Device-integrity policies can exclude certain devices. Runtime checks can create false positives. Aggressive hardening can affect performance, diagnostics or accessibility. Platform-specific integrity services can create dependencies on particular mobile ecosystems.
OWASP explicitly warns about several of these trade-offs, including potential platform lock-in and the possibility that resilience mechanisms make independent verification more difficult. That requires security teams, mobile developers, architects, UX teams and certification specialists to work together rather than treating their requirements as separate workstreams.
Five EUDI Wallet Security Questions Every Development Team Should Ask Before Production
- What exactly are we trusting on the user's device?
Which security assumptions depend on the mobile OS, secure hardware, keystore, Wallet Instance, WSCA or WSCD and how do we verify those assumptions when the wallet is operating in the field? - What happens if the application is running in a hostile environment?
Have we threat-modelled rooting or jailbreaking, application modification, repackaging, debugging, hooking and runtime instrumentation? Which risks require detection, prevention, backend enforcement, restricted functionality or wallet revocation? - Are we protecting the transaction as well as the credential?
It is not enough to demonstrate that keys cannot be extracted. Can the architecture also preserve user intent, application integrity and the integrity of the workflow surrounding issuance, presentation, authentication and signing? - Can every important security requirement be traced to implementation and evidence?
Can the team move from a certification requirement to the relevant threat, technical control, architecture component, test result and release artefact without relying on assumptions or undocumented behaviour? - Have we tested security without breaking interoperability or the user experience?
Have controls been validated across the supported device population? Are false positives, accessibility, recovery, upgrades and compromised-device scenarios understood? And can the wallet continue to meet interoperability requirements after production hardening is applied?
The Key EUDI Wallet Security Question for 2026: Can the App Stay Trusted on Real Devices?
By the end of 2026, the question will no longer be whether EUDI Wallets are moving from policy into implementation. They are.
The more important question is whether the mobile applications implementing them can deliver the level of trust expected from European digital identity infrastructure once they leave the architecture diagram and run on real devices.
The EU framework already recognises that a wallet is more than a credential container. Certification covers software, hardware, services, settings and configurations. The security model also considers the Wallet Instance and the environment in which it operates. Providers are expected to manage vulnerabilities, monitor the continuing security of deployed wallets and respond when trust in the wallet, device or execution environment is affected. Where security signals need to inform backend decisions, MASC Assurance can support server-side mobile app integrity verification and policy-based responses.
That makes mobile application security a practical part of EUDI Wallet architecture, not a separate consideration to address after compliance work is complete.
Fatima will explore what EUDI Wallet security means from the mobile developer's perspective, where application-level threats enter the architecture and what teams should consider before their wallet reaches production.
- Regulation (EU) 2024/1183 — European Digital Identity Framework
EUR-Lex: Regulation (EU) 2024/1183 - Commission Implementing Regulation (EU) 2024/2981 — Certification of European Digital Identity Wallets
EUR-Lex: Implementing Regulation (EU) 2024/2981 - Commission Implementing Regulation (EU) 2026/1731 — Updated EUDI standards and specifications
EUR-Lex: Implementing Regulation (EU) 2026/1731 - EUDI Wallet Architecture and Reference Framework (ARF)
EUDI Wallet Architecture and Reference Framework - EUDI Wallet ARF — Wallet Solution Certification and Risk Management
EUDI Wallet: Certification and Risk Management - EUDI Wallet ARF — High-Level Requirements by Topic
EUDI Wallet: High-Level Requirements - EUDI Wallet Architecture and Reference Framework — GitHub releases
EUDI ARF GitHub Releases - FCAF — Introduction
FCAF Introduction - OWASP Mobile Application Security Verification Standard — Resilience
OWASP MASVS: Resilience - EU Digital Identity Wallet — iOS Reference Implementation Security Guidance
EUDI iOS Wallet Reference Implementation