The runtime challenge for EUDI Wallets

Europe’s digital identity wallet is moving from shared architecture into national delivery. EU Member States must provide at least one European Digital Identity Wallet by the end of 2026. Citizens and residents will be free to choose whether to use one.

Certification is central to that delivery. ARF v3.0.0 distinguishes between cybersecurity evaluation and functional conformance more clearly. The new Functional Conformance Assessment Framework provides shared test cases for functional requirements and interoperability. It complements rather than replaces cybersecurity evaluation.

Neither process freezes the environment in which a wallet operates.

A Wallet Instance may be installed on a device that changes over time. The operating system is updated. Software libraries age. Device security may be weakened. The application itself may be copied, modified, instrumented, or run in an environment the Wallet Provider did not intend. A Wallet Instance can pass every certification check and, days later, be running on a jailbroken device, under a debugger, inside a repackaged clone.

The current Architecture and Reference Framework, or ARF, addresses this need for runtime trust. It assigns Wallet Providers responsibility for verifying genuine Wallet Instances, checking their integrity, monitoring their security posture, and acting when compromise affects trust.

The framework defines the required outcomes. Wallet teams still need to decide how to deliver them.

First, separate law from implementation guidance

Claims about what “EUDI requires” often combine several different sources. Keeping them separate is important for security architects, compliance teams, and anyone preparing for certification or a national procurement.

The EUDI Regulation and its implementing and delegated acts are the legally binding sources. They define the formal obligations that Member States and ecosystem participants must meet.

The ARF serves a different purpose. It provides a common architecture, terminology, trust model, and set of high-level requirements to support consistent implementation across the EU. The ARF describes itself as informative but describes the annexes as containing normative high-level requirements. It doesn't replace the Regulation or its implementing and delegated acts, which remain the mandatory legal sources.

Annex 2 of the ARF contains the current high-level requirements. It uses capitalized terms deliberately:

  • SHALL identifies a requirement within the annex

  • SHOULD identifies a recommendation

  • MAY identifies an option

These terms describe the status of a statement within the ARF. They do not turn the ARF itself into legislation. The ARF also warns readers not to rely on historic discussion papers after their content has been integrated and revised. Requirements analysis should use the latest Annex 2.

National certification schemes and procurement documents add another layer. They may translate the common framework into more detailed technical, operational, or evidence requirements for a particular wallet implementation.

Vendor controls sit at a further layer. App shielding, runtime application self-protection (RASP), telemetry, and policy management are possible ways to support selected requirements. They are not part of the legal framework unless an exact regulation, ARF requirement, certification scheme, or procurement clause says so.

This gives wallet teams a useful source hierarchy.

EUDI source hierarchy

These distinctions prevent implementation recommendations from being presented as legal mandates.

This article focuses on mobile Wallet Instances

The ARF uses three terms to describe different parts of the ecosystem:

  1. Wallet Solution

  2. Wallet Unit

  3. Wallet Instance

A Wallet Solution is the complete product and service provided by a Wallet Provider. A Wallet Unit is the unique technical configuration used by an individual user. The Wallet Instance is the application that implements the wallet’s core business logic and interfaces.

diagram-v2

The ARF commonly describes the Wallet Instance as an application installed on a user device. It also allows a Wallet Instance to be implemented as a web application or on another type of device. Most ARF requirements apply regardless of the architecture unless the framework states otherwise.

This article focuses on Wallet Providers delivering a mobile Wallet Instance. That is where the application runs inside an operating system and device environment that the provider doesn't fully control.

Read more: Mobile app vs. mobile device security: What are the differences?

It is also important to distinguish the Wallet Provider from other EUDI roles. PID Providers and Attestation Providers issue identity data and credentials. Relying Parties request and use that information. One organization may perform more than one role, but the responsibilities associated with each role remain distinct.

Runtime trust is a lifecycle

The ARF doesn't treat Wallet Instance trust as a single check performed during development or certification.

Trust is established during activation. It is supported by integrity measures. It is monitored while the Wallet Instance is operational. It must be reassessed when the application, device, operating system, or cryptographic environment changes.

runtime trust lifecycle

Runtime trust continues after activation and certification.

Establish that the Wallet Instance is genuine

After installation, the Wallet Instance begins an activation process with the Wallet Provider.

During this process, the Wallet Provider must verify that the new Wallet Instance is a genuine instance of its Wallet Solution. This is an explicit SHALL requirement in Annex 2, identified as AS-WP-40-004.

For a mobile implementation, this creates a concrete technical question: How will the Wallet Provider distinguish an approved application instance from an unofficial, copied, or modified client?

Official OS app stores can provide one route for establishing application authenticity. If a Wallet Provider distributes its Wallet Solution through other means, the ARF requires a mechanism that allows the user to verify the authenticity of the Wallet Unit. The ARF recommends distributing certified Wallet Solutions through official operating-system app stores and requires another authenticity-verification mechanism when a different installation route is used.

Distribution checks alone do not answer every runtime question. The provider still needs to decide what evidence it will trust when the installed Wallet Instance contacts its backend and begins activation.

Verify integrity before issuing a Wallet Instance Attestation

The activation process also includes the creation and issuance of Key Attestations and at least one Wallet Instance Attestation. This also makes application authenticity relevant beyond the initial activation flow. App attestation can help the Wallet Provider verify that subsequent requests to its backend continue to come from a genuine, untampered application running in an acceptable environment.

Before issuing the Wallet Instance Attestation, the Wallet Provider must take measures to verify the integrity of the Wallet Instance. This is another explicit SHALL requirement, AS-WP-40-011.

The requirement states the outcome. It doesn't prescribe the technical method.

A wallet team therefore needs to determine:

  • What properties establish that the application is intact?

  • Which components and configurations are included in that assessment?

  • What evidence is available to the Wallet Provider?

  • What happens when an integrity check fails?

  • When should integrity be reassessed after activation?

These decisions need to fit the wider Wallet Solution architecture, including its backend services, cryptographic components, device capabilities, and certification model.

Monitor trust after activation

Once a Wallet Instance is operational, the responsibility doesn't end.

Annex 2 requires the Wallet Provider to monitor the security posture of its operational Wallet Instances. The stated purpose is to detect critical security risks in the environment in which the Wallet Instance runs.

The Wallet Provider must also determine and transparently document which data it needs and is allowed to monitor. This requirement appears as AS-WP-56-003.

This makes security posture an operational concern rather than a release-time property.

A Wallet Instance may have passed its original checks, but the conditions around it can change. A device may later be rooted or jailbroken. The application may run under an emulator or debugger. A vulnerable version may remain in use after a replacement becomes available. A software library or operating system component may develop a known security issue.

The Wallet Provider needs a way to recognize relevant changes and decide whether the Wallet Unit remains trustworthy.

Read more: Protection is not intelligence: Why blocking mobile threats is no longer enough

Maintain the Wallet Unit as conditions change

The ARF also requires the Wallet Provider to update the Wallet Unit as necessary to maintain its security and functionality throughout its lifetime. This is requirement AS-WP-56-004.

The framework doesn't prescribe a single update method. A change may require a new Wallet Instance release, a library update, a change to a backend service, a revised response policy, or another technical measure.

The operational objective remains the same: known weaknesses should not remain unaddressed simply because the Wallet Instance has already reached users.

Investigate and act when trust is affected

The Wallet Provider must regularly verify that the Wallet Unit has not been breached or compromised.

When a breach or compromise is detected, the provider must analyze its causes and impact. If the issue affects the trustworthiness or reliability of the Wallet Unit, the provider must revoke the Wallet Unit by revoking the Wallet Instance.

This applies when the relevant compromise affects the Wallet Unit, the mobile device or operating system, the cryptographic environment, or the wider Wallet Solution. The requirement appears as EW-DM-38-007.

Revocation is the strongest response, but it is not the only possible operational action discussed in the ARF.

Its main narrative presents a potential four-level posture model. Depending on severity, responses may include allowing normal use, restricting sensitive functionality, requiring user reauthentication, forcing reactivation, requiring reinstallation, or revoking the Wallet Instance and associated cryptographic components.

The model is illustrative rather than mandatory. Each Wallet Provider still needs to define an appropriate response policy and support it with technical evidence.

The ARF identifies concrete security-posture signals

“Security posture” can sound abstract. Annex 2 identifies several types of information that should be monitored for software- and hardware-level problems or vulnerabilities.

These include:

  • Device jailbreak or root detection

  • Emulator detection

  • Operating system version and health information

  • Wallet Instance SDK and software library versions

  • Wallet Instance version

  • Supported Wallet Secure Cryptographic Applications, Devices, and keystores

  • Device sensor identifiers and patch levels

The wording of the requirements here is important. The Wallet Provider shall monitor operational security posture. The listed information should form part of that monitoring.

The main ARF narrative adds further context. Its potential critical-posture model includes confirmed root or jailbreak, an active debugger or emulator, an exploited critical operating-system vulnerability, and a failed Wallet Instance integrity check indicating tampering.

The framework also identifies malware detection as appropriate for security-posture monitoring.

This creates a clearer set of implementation questions for a mobile wallet team:

  • Can the Wallet Instance recognize that the device has been rooted or jailbroken?

  • Can it detect emulated or instrumented environments?

  • Can the provider distinguish current and outdated application versions?

  • Can it identify an integrity failure or signs that application logic is being manipulated?

  • Can the resulting signal be trusted if the application itself is under attack?

  • Can the team connect a detected condition to a proportionate response?

Some relevant controls are not named explicitly in Annex 2.

For example, runtime hooking detection, repackaging detection, code obfuscation, and protection against reverse engineering may help support genuine-instance, integrity, and code-protection objectives. They should be described as implementation controls mapped to those outcomes, not as controls that the ARF explicitly mandates.

Security-posture monitoring is not user surveillance

Runtime security monitoring needs a clear privacy boundary.

The ARF states that complete fraud or risk-signal collection is outside its scope. Wallet Providers should maintain an active understanding of each Wallet Instance’s security posture, but they should do so in a privacy-preserving way.

Its guidance distinguishes between:

  1. information related to the security of the application and device

  2. broader behavioral surveillance

security posture without user surveillance

Root or jailbreak detection, emulator detection, and malware detection are treated as relevant security-posture signals. Behavioral data, IP or GNSS geolocation, active-call detection, and VPN detection are rejected or considered unsuitable for this purpose.

The distinction is practical. A Wallet Provider may need to know that an application is running on a compromised device. It doesn't follow that the provider should collect a detailed profile of the user’s behavior, location, calls, or network choices.

Annex 2 reinforces this boundary. During activation, the Wallet Provider must not process more information than it reasonably needs for legitimate purposes. It must request the user’s consent for the information it will process and explain the purposes of that processing.

A defensible monitoring design should therefore answer several questions:

  • Which signal is collected?

  • What security purpose does it serve?

  • Is it necessary for that purpose?

  • Is it evaluated locally or sent elsewhere?

  • How long is it retained?

  • Which teams can access it?

  • What decision or response can it support?

  • What is explained to the user?

Security telemetry should be deliberate, limited, and explainable. Collecting more data doesn't automatically create better runtime trust.

The ARF defines outcomes rather than a product category

The ARF is specific about the responsibilities of the Wallet Provider.

It requires genuine-instance verification during activation. It requires measures to verify Wallet Instance integrity. It requires operational security-posture monitoring. It requires updates, investigation, and revocation when trust is affected.

It doesn't prescribe RASP, app shielding, or a named vendor as the required way to meet these outcomes.

The ARF states that the relevant trust relationships are the responsibility of the Wallet Provider but doesn't define one required technical method for establishing them.

This leaves an implementation decision.

A mobile wallet team needs controls that can help it:

  • Establish application authenticity and integrity

  • Detect relevant changes in the runtime environment

  • Protect sensitive application logic against inspection or manipulation

  • Produce security signals that operational teams can use

  • Apply a response aligned with the severity of the condition

  • Maintain and update the protection model as risks change

Embedded runtime protection is one way to support these objectives.

Read more: Build it. Prove it. Then release the data: Runtime trust for the browser

It sits alongside the Wallet Solution’s cryptographic design, backend security, identity-proofing processes, privacy controls, certification work, and operational governance. No single mobile security product makes the complete Wallet Solution compliant or certified.

Seven questions mobile wallet teams should answer now

Translating the framework into an operational design starts with assigning clear answers and owners.

1. Who owns the Wallet Provider responsibility?

Which legal entity is the Wallet Provider? Which organizations own the mobile application, backend, cryptographic components, monitoring, incident response, and certification evidence?

A national authority, systems integrator, mobile developer, identity provider, and QTSP may all participate in the same delivery. Their roles should not remain implicit.

2. How will the backend recognize a genuine Wallet Instance?

What evidence allows the Wallet Provider to distinguish an approved Wallet Instance from a fake, copied, or modified application during activation? Does that trust continue beyond the first connection? How is the evidence protected against replay or manipulation?

3. How will Wallet Instance integrity be established?

Which measures verify integrity before the Wallet Instance Attestation is issued? What exactly is being checked? Does the assessment cover only the original binary, or also the running process and relevant runtime conditions? Which failures should stop activation?

4. Which posture signals will be monitored?

Does the design cover the device, operating system, Wallet Instance version, software libraries, cryptographic components, and relevant hardware conditions identified by the ARF? Are root or jailbreak and emulator detection included? Which additional signals are justified by the wallet’s threat model?

Each signal should be classified accurately as:

  • A binding legal requirement

  • An ARF SHALL

  • An ARF SHOULD

  • A national or procurement-specific requirement

  • An architecture or vendor recommendation

5. What happens when posture changes?

Which conditions allow normal use? Which require additional authentication, restricted functionality, reactivation, an upgrade, or complete revocation? How will teams avoid treating every signal as equally severe?

A detected emulator, an outdated application version, and confirmed application tampering may require different responses.

6. What evidence will security and certification teams receive?

Can the organization show:

  • Which condition was detected?

  • Which Wallet Instance and application version were involved?

  • Which control and response policy were active?

  • What action followed?

  • When did the event occur?

  • Can related events be correlated without collecting unnecessary personal data?

The exact evidence fields will depend on the architecture, certification route, and national requirements. They should be agreed before the Wallet Instance reaches production.

7. Is the monitoring model proportionate and explainable?

Is each data point tied to a documented security purpose? Is the data minimized and protected? Can the organization explain what is collected, where it is processed, how it is retained, and who can use it?

Runtime monitoring should strengthen trust in the Wallet Instance without creating a second, unnecessary layer of user surveillance.

Relying Parties have a different security job

Relying Parties have their own responsibilities within the EUDI Wallet ecosystem. They do not normally build or secure the citizen’s Wallet Instance. Their role is to request information from the wallet, verify what they receive, and use it within a defined service or customer journey.

ARF v3.0.0 formalizes this through the concept of a Relying Party Service. A large organization may operate several services with different purposes and data needs. A bank, for example, might use EUDI Wallet information for customer onboarding, account recovery, and access to a regulated service.

Each service has its own identifier and intended uses. Registration certificates link the service to the attributes it plans to request. Access certificates identify the Relying Party and the service represented by the Relying Party Instance. The Wallet Instance can then confirm who is requesting the information, for which service, and for what purpose.

Relying Parties must therefore manage EUDI Wallet integration at the service level, not only across the organization. Each journey needs an appropriate attribute set, valid certificates, defined verification checks, and accountable data-handling processes.

But trusted credentials and authenticated requests do not secure everything around the EUDI interaction.

A bank, insurer, telecom provider, public service, or digital platform still owns the security of the mobile application that:

  • initiates the request

  • receives and verifies the result

  • connects it to the correct user and session

  • uses it to approve onboarding, access, signing, recovery, or another sensitive action

An attacker who manipulates the Relying Party’s application may target these surrounding steps rather than the credential itself. They may interfere with verification logic, substitute session or transaction details, or change the action taken after a valid result is received.

A trusted EUDI credential can strengthen identity assurance. It doesn't establish the integrity of the Relying Party’s own application, session, or subsequent transaction.

The Relying Party’s task is therefore not to protect the citizen’s Wallet Instance. It is to protect its own mobile service and ensure that a trustworthy credential leads to the intended decision and action.

Where embedded runtime protection can help

Once the required outcomes are clear, the implementation question becomes more concrete:

Which controls will operate inside the mobile application, what will they detect, and how will the Wallet Provider respond?

Promon Shield for Mobile™ embeds protection into the compiled mobile application after build. It doesn't require changes to the application’s source code or the integration of a separate protection SDK.

Read more: Behind the shield: A guided approach to protecting mobile apps and SDKs

Shield for Mobile can help protect the application against tampering, repackaging, reverse engineering, code injection, debugging, runtime hooking, malware, and hostile device conditions such as root or jailbreak. Depending on policy, the protected application can report, block, or exit when a relevant condition is detected.

Together, Shield for Mobile, Promon Verify™, Promon Insight, and Promon Control™ connect runtime protection with backend trust, visibility, and response. For wallet teams, that creates a practical link between protecting the Wallet Instance, verifying application trust at the backend, understanding what is happening across deployed instances, and adapting how the application responds.

These capabilities map to several runtime trust questions:

  • Is the compiled application intact? 
    Application-integrity and anti-tampering controls help detect unauthorized changes.
  • Has the application been copied or altered? 
    Repackaging and signature-related controls can help identify modified distributions.
  • Is the application being inspected or manipulated? 
    Debugger, hooking, and instrumentation detection can identify attempts to alter the running process.
  • Is the device environment high risk? 
    Root, jailbreak, emulator, and malware signals can contribute to the Wallet Provider’s posture assessment.
  • Can the backend trust the application making the request? 
    Promon Verify™ extends the trust established by Shield for Mobile to the backend. It cryptographically validates requests from Shield-protected applications, helping confirm that they come from a genuine app and an acceptable runtime environment before the backend accepts them.
  • What happened in an operational instance? 
    Promon Insight for App Security™ can provide structured telemetry from applications protected by Shield for Mobile. Insight is embedded through Shield and doesn't require an additional SDK. Data can be exported to security, fraud, or compliance systems, with the customer controlling how it flows.
  • Can the response change after release? 
    Promon Control™ provides a post-deployment runtime control layer for Shield-protected applications. It can update protection policies, adjust responses, and apply changes without rebuilding, re-shielding, or resubmitting the application.

These controls can support selected genuine-instance, integrity, monitoring, update, and response objectives.

They remain one part of a wider Wallet Solution. The complete architecture must also cover secure cryptographic components, backend services, identity proofing, authentication, privacy, certification, and operational governance.

Start with a control map

The ARF gives mobile wallet teams a clear starting point.

The Wallet Provider must recognize genuine Wallet Instances, take measures to verify integrity, monitor operational posture, maintain the Wallet Unit, and act when compromise affects trust.

The framework doesn't prescribe one product or implementation method. That places the next decision with the wallet team.

Start by mapping each runtime trust outcome to five things.

runtime trust control map

Any blank cell represents an implementation question that still needs an answer before certification or launch.

Building or operating a mobile Wallet Instance?

Use the EUDI Wallet Runtime Trust Checklist to review genuine-instance verification, integrity, security-posture monitoring, privacy, response, updates, and evidence.

EUDI wallet builders and operators checklist
For teams building, operating, or supplying a mobile Wallet Instance
Download here

 

Accepting EUDI credentials in your mobile service?

Use the EUDI Wallet Mobile Security Checklist for Relying Parties to review registration, verification, application integrity, session binding, transaction security, response, and evidence.

EUDI wallet relying parties checklist
For banks, insurers, telecom providers, public services, and digital platforms accepting EUDI credentials through a mobile journey
Download here

 

Sources and further reading

Primary sources

This article draws primarily on the following official EU legal and technical sources:

EUDI Wallet Architecture and Reference Framework

The following chapters of ARF v3.0.0 provide the main technical basis for the article:

Source note

This article was reviewed against ARF v3.0.0, published on July 21, 2026, and the EU legal and technical material available on the publishing date. The ARF and its supporting specifications continue to develop. References and requirement mappings should be checked again before application.

Turn runtime trust into a working control model
Map the ARF’s runtime trust outcomes to the controls, signals, responses, and evidence your mobile Wallet Instance needs. Talk to Promon about where embedded protection can support your wallet architecture and certification work.
Book a meeting