BUILDING SECURE EUDI WALLETS

A software developer’s guide to architecture, implementation, runtime security and operational assurance

For wallet providers, mobile developers, security architects and engineering teams translating EUDI Wallet requirements into secure software.

THE IMPLEMENTATION CHALLENGE

Europe’s digital identity programme is moving from architecture and regulation towards implementation. The current EUDI Wallet Architecture and Reference Framework, or ARF, provides the common technical baseline for wallet architecture, ecosystem roles, trust relationships, protocols and interoperability.

At the same time, the new OWASP MAS-EUDIW Profile gives development and security teams a mobile application security baseline tailored specifically to EUDI Wallets. It extends OWASP’s existing mobile security framework to cover digital identity assets such as Person Identification Data, Wallet Instance Attestations and wallet-specific security processes.

Together, these sources provide a strong foundation. However, they do not remove the central engineering challenge:

How do you maintain trust in a wallet application when it runs on a device that the Wallet Provider does not control?

A wallet may use strong cryptography and secure hardware while still being exposed to application-layer manipulation. Attackers may target consent screens, local authentication, credential-selection logic, backend requests or the application code surrounding a secure cryptographic operation. Building a secure wallet therefore requires more than protecting credentials. Developers must also protect the application handling them.

THE WALLET TRUST MODEL

An EUDI Wallet is not simply a mobile application containing digital credentials. It participates in an ecosystem involving the wallet user, Wallet Provider, Wallet Unit, Wallet Instance, Wallet Secure Cryptographic Application, Wallet Secure Cryptographic Device, credential issuers, relying parties and supporting trust services.

The ARF serves as the common technical specification for the EUDI Wallet and its ecosystem. It describes the roles, trust model, high-level requirements, technical specifications and interactions that allow wallets, issuers and relying parties to interoperate.¹ [github.com], [eudi.dev]

Developers should examine wallet security across several related layers:

Ecosystem Trust

Are the issuer, relying party, Wallet Provider and other interacting entities recognised and authorised?

Protocol Security

Are messages authenticated, integrity-protected, confidential where required and resistant to replay?

Cryptographic Security

Are keys generated, protected, used, rotated and destroyed correctly?

Platform Security

Are operating-system isolation, platform keystores and secure hardware used appropriately?

Application Security

Can wallet code, configuration, assets and user journeys resist manipulation?

Runtime Assurance

Can the system determine whether its security assumptions still hold while the wallet is being used?

Operational Security

Can the Wallet Provider detect attacks, investigate events and change policy after deployment?

A design addressing only cryptography leaves potential attack paths through application logic, APIs, storage, the user interface and the runtime environment. This distinction is important because the user does not interact directly with the WSCA or WSCD. The user interacts with a mobile application, and that application determines what is displayed, what the user approves, when a secure operation is requested and how the result is subsequently used.

GET CLEAR ON WALLET'S SECURITY BOUNDARIES

Before selecting security controls, development teams should document which component owns each sensitive responsibility. The applicable implementing rules establish important responsibilities for the WSCA and WSCD. For example, critical cryptographic operations must be performed through the WSCA, communication between the Wallet Instance and WSCA must be protected for confidentiality, integrity and authenticity, and the WSCD is used to manage critical assets. A practical responsibility model may look like this:

SECURITY RESPONSIBILITY	PRIMARY IMPLEMENTATION AREA
PID / EAA Lifecycle	Wallet Instance and issuer services
User consent and attribute selection	Wallet Instance
Wallet-user authentication	Wallet Instance and WSCA
Critical cryptographic operations	WSCA
Protection of critical private keys	WSCD
Wallet Unit Attestation	WSCA, WSCD and Wallet Provider services
Runtime application integrity	Wallet application security layer
Device and application threat detection	Wallet application security layer
Backend trust decisions	Wallet Provider backend
Security-event processing	Wallet application and backend
Certification evidence	All responsible component owners

IDENTIFY ASSETS AND SENSITIVE WALLET JOURNEYS

Security controls should be based on the assets and journeys they protect. Relevant wallet assets may include:

Relevant wallet assets may include PID and EAA data, credential metadata, Wallet Unit Attestation keys and artefacts, holder-binding keys, authentication factors, access and refresh tokens, session state, consent records, relying-party registration information, pseudonyms, transaction logs, cryptographic aliases and wallet configuration. They may also include backend endpoint and certificate configuration, recovery information, security telemetry and integrity verdicts.

Not every part of a wallet carries the same risk. Development teams should identify particularly sensitive journeys, including:

These particularly sensitive journeys include initial wallet activation; device and application enrolment; PID or EAA issuance; credential presentation, including offline presentation; authentication to a relying party; wallet-to-wallet interaction; consent approval; and account or wallet recovery. They also include authentication-factor enrolment, key generation and rotation, Wallet Unit Attestation renewal, qualified electronic signature initiation, export and deletion of wallet data, device migration, and wallet suspension or revocation.

For each journey, consider what an attacker could achieve by reading, altering, replaying, skipping or triggering the journey without valid user intent. This produces a more useful threat model than applying one generic security level across the complete application.

USE THE OWASP MAS-EUDIW PROFILE AS AN ENGINEERING BASELINE

The OWASP MAS-EUDIW Profile draws on controls from the existing OWASP MAS testing profiles and adds consideration of assets specific to digital identity systems, including Wallet Instance Attestations and PID.

Secure Storage

Sensitive data should be classified before it is persisted. The wallet should store only what it needs, for only as long as it needs it. Development teams should consider:

Encryption of application-managed sensitive data, platform-keystore or secure-hardware protection of keys,exclusion of sensitive data from backups, protection of temporary files and caches, secure deletion, access control around stored values, protection against restoration of obsolete state and separation of encrypted data and the keys protecting it

The MAS-EUDIW profile includes weaknesses covering unencrypted sensitive data, keys stored outside the platform keystore, sensitive information hardcoded in the application package, sensitive logging and data included in backups.

The operating-system sandbox should not be treated as a substitute for application-level data protection.

Cryptography

The cryptographic design should define:

Approved algorithms and parameters; random-number-generation requirements; where keys are generated; whether keys may be exported; key derivation and wrapping; authorisation for key use; key rotation; secure deletion; hardware-backed protection requirements; and behaviour when expected secure hardware is unavailable.

A wallet should not silently downgrade from an expected hardware-backed security level to a software-only mechanism. If fallback is permitted, the achieved protection level should be recorded and made available to the policy layer.

Authentication & Authorisation

Sensitive operations should not depend on a single client-side Boolean or a method that returns “authenticated” without validating protected state. Wallet authentication should cover:

Wallet-user authentication; binding between the user and Wallet Unit; reauthentication for sensitive journeys; biometric fallback; PIN retry and lock behaviour; session lifetime; recovery; step-up authentication; protection against local-authentication bypass; backend authorisation; and binding of consent to the exact relying party and requested attributes.

Developers should assume that local methods can be hooked, skipped or forced to return a chosen result. Sensitive authorisation should therefore be based on protected state and reinforced by backend controls where connectivity and the journey permit it.

Network communication

TLS is foundational, but it does not independently establish that a request came from an uncompromised wallet application. The design should consider:

Server and endpoint authenticity; trust-anchor management; request integrity; replay resistance; token protection; proof of possession; session binding; redirect and deep-link handling; third-party SDK traffic; offline-to-online synchronisation; and whether application-integrity information contributes to backend trust.

Backend services should verify freshness and authorisation rather than accepting an operation solely because it contains a syntactically valid token.

Platform Interaction

Every platform permission, entitlement, exported component, background mode, URL scheme and inter-process communication path should be reviewed. Wallet threat models should explicitly consider:

Accessibility-service abuse; third-party keyboards; notification listeners; screen capture and screen sharing; overlay attacks; clipboard leakage; malicious deep links; WebView storage; camera or capture manipulation; device backup and migration; and excessively broad package visibility. These platform interactions can expose or manipulate a wallet journey even if credential cryptography remains intact.

Code & Software Supply Chain

The wallet delivery process should include:

Dependency pinning; software composition analysis; CycloneDX or SPDX SBOM generation; secret scanning; static analysis; dependency provenance; release signing; protection of build credentials; review of third-party SDK permissions; vulnerability intake and patch governance; and debug-symbol and logging review.

Open-source wallet implementations provide transparency, but public source code does not eliminate supply-chain threats, build-system compromise or runtime manipulation.

Resilience

OWASP MASVS includes a dedicated resilience category addressing resistance to reverse engineering and tampering. Wallet testing should consider:

Root and jailbreak; debugging; emulation and virtualisation; runtime instrumentation; hooking; code modification; repackaging and resigning; library injection; certificate-pinning bypass; forced application branches; local-authentication bypass; manipulated integrity signals; application cloning; and backup and state restoration.

Resilience controls do not replace secure architecture. They increase attack cost, detect changes in the runtime environment and help prevent sensitive operations from continuing under invalid security assumptions.

What asset or journey is being protected?

Which attack or failure is being addressed?

What prevents the attack?

What detects a change in trust?

How should the wallet respond?

What evidence demonstrates that the control works?

For a credential-presentation journey

The assets may include selected attributes, the holder-binding key, consent information and the presentation result. Relevant attacks may include manipulation of attribute selection, consent-screen overlay, authentication bypass, replay and instrumentation of the cryptographic call. For this scenario:

Preventive controls could include relying-party authentication, data minimisation, consent binding, user authentication and challenge-response protocols.
Detective controls could include package-integrity verification, hooking detection, instrumentation detection, debugger detection, overlay detection and backend validation of request freshness.
The response could range from allowing the operation and reporting the event to requiring step-up authentication, limiting attributes, blocking the presentation or suspending the affected Wallet Instance.
Evidence might include the logs, telemetry and security information, current configuration.

USE PROPORTIONATE RUNTIME RESPONSES

Not every security signal should produce the same result. A rooted device weakens the wallet’s security context, but it does not by itself prove that a particular transaction is under active attack. Conversely, active hooking of an authentication method during a sensitive presentation journey may justify a more restrictive response.

A runtime-response model may include:

RESPONSE	APPROPRIATE CONTEXT
Allow	No relevant security concern
Allow & Report	Low-confidence or low-impact anomaly
Warn	User-actionable concern
Step up	Stronger authentication is requires
Degrade	Selected sensitive capabilities are disabled
Block Journey	Current operation must not continue
Suspend Instance	Backend stops trusting the Wallet Instance
Revoke	Relevant attestation binding or credential is invalidated
Backend trust decisions	Block journey
Security-event processing	Suspend instance
Wipe protected session data	Confirmed compromise where authorised and supported

Local and backend responsibilities should remain distinct. Local controls provide immediate protection and are necessary for offline journeys. Backend controls correlate signals and maintain consistent policy. Business controls determine whether a specific identity operation is permitted.

DESIGN OFFLINE SECURITY EXPLICITLY

Offline operation removes the backend from the immediate decision loop.

The wallet must therefore define, which journeys can operate offline, which credentials can be presented, how relying-party authenticity is established, how freshness is determined, how counters and state are protected, how rollback is detected, which local integrity conditions must hold, how long offline trust remains valid, what happens when connectivity returns, how revocation or expired policy is reconciled.

Offline security should not rely on an unprotected device clock. Time, counters, cached policy and stored state should be regarded as attacker-controlled unless they are specifically integrity-protected.

Runtime Application Protection

Help the wallet resist code modification, repackaging, hooking, debugging and instrumentation around sensitive flows

Protect Local Data

Strengthen protection for application-managed data, configuration and temporary state outside the dedicated cryptographic boundary

Network Hardening

Add application-aware controls around communications, endpoint trust and manipulation attempts.

Application-Instance & Backend Assurance

Provide signals that can help the backend assess whether a request comes from an expected application instance and security context.

Runtime Telemetry, Monitoring & Reaction

Turn relevant events into protected signals and proportionate actions, from reporting and step-up through to blocking or suspension.

A secure EUDI Wallet should not assume that trust established during development, signing, installation or certification will remain valid indefinitely. The wallet must protect critical assets, verify ecosystem participants, authenticate user intent, recognise material changes in its runtime environment and make proportionate trust decisions when sensitive identity operations take place.

The OWASP MAS-EUDIW Profile provides developers with a valuable wallet-specific application-security baseline. The ARF and implementing regulations provide the wider architecture, trust and regulatory context. MASC can contribute an important application-security and runtime-assurance layer within that architecture. Its greatest value comes when its protections are connected to specific wallet journeys, backend policy and measurable security outcomes.

1) Have all critical assets and sensitive wallet journeys been identified?

2) Are responsibilities clearly allocated between the Wallet Instance, WSCA, WSCD and backend?

3) Are critical keys generated and used only within the intended security boundary?

4) Is application-managed sensitive data protected, including caches and temporary state?

5) Can the wallet detect modification, repackaging and unexpected signing?

6) Can the wallet detect relevant hooking, debugging and runtime instrumentation?

7) Are authentication paths resistant to forced-success and hooking attacks?

8) Are overlays, accessibility abuse, screen sharing and untrusted input methods addressed?

9) Are network requests protected against interception, manipulation and replay?

10) Can the backend distinguish a valid credential from a sufficiently trusted application interaction?

11) Are offline freshness, rollback and resynchronisation explicitly designed?

12) Do runtime responses reflect the risk of the affected journey?

13) Can legitimate users recover from false positives?

14) Is security telemetry minimised and protected?

15) Are third-party SDKs subject to dependency, permission and network review?

16) Are SBOM, vulnerability-management and patch processes operational?

17) Can every claimed security control be independently demonstrated?

18) Can compromised Wallet Instances be restricted, suspended or revoked?

19) Can security policy evolve after release?

SOURCES & NOTES

European Digital Identity Wallet, Architecture and Reference Framework. The site identifies ARF v3.0.0 as the current release and describes the ARF as the common technical baseline covering the architecture, roles, requirements, specifications and open topics for the EUDI Wallet ecosystem. [eudi.dev] ↩ ↩²
OWASP Mobile Application Security, MAS-EUDIW: EU Digital Identity Wallet Profile. The profile draws on OWASP’s existing MAS profiles and covers assets specific to digital identity systems, including Wallet Instance Attestations and PID. [mas.owasp.org] ↩ ↩²
European Commission, Commission Implementing Regulation (EU) 2024/2979, particularly the requirements concerning the Wallet Instance, WSCA, WSCD, critical assets and protected communication between wallet components.
OWASP, Mobile Application Security Weakness Enumeration. OWASP describes MASWE as a bridge between MASVS and MASTG for developers, researchers and security professionals. [github.com] ↩
OWASP Mobile Application Security, MASWE catalogue. The catalogue marks wallet-relevant weaknesses under the EUDIW profile, including unencrypted data, inappropriate key storage, hardcoded sensitive information, sensitive logging and backup exposure. [mas.owasp.org] ↩
OWASP Mobile Application Security, MAS Testing Profiles. The supporting MASVS structure includes resilience controls addressing reverse engineering and application tampering alongside storage, cryptography, authentication, communication, platform, code and privacy controls. [mas.owasp.org] ↩
European Digital Identity Wallet, ARF v3.0.0. The current release includes the Functional Conformance Assessment Framework as part of the broader EUDI Wallet documentation and conformance resources. [eudi.dev] ↩

cryptomathic_symbol_red_positive_transparent

PROTECT YOUR EUDI WALLET BEYOND COMPLIANCE

Explore how Cryptomathic MASC can strengthen your EUDI Wallet’s runtime security and protect critical user journeys.