7 min read
For teams already working on EUDI Wallet architecture, the hard part is no longer understanding the concept. It is ensuring that high-value mobile operations remain trustworthy once the wallet is running on real devices.
Every sensitive wallet action depends on a chain of events: the app displays information, the user makes a decision, protected functions are invoked, and backend services decide whether to accept the request.
If that chain is manipulated at runtime, the credential may remain protected while the operation around it becomes untrustworthy. An attacker does not always need to extract a private key or break encryption. In many cases, it is enough to alter what the app does, what the user sees or what the backend believes.
This article focuses on that operational layer: how to protect the moments when identity data, user consent and cryptographic capability meet inside the mobile app.
For wallet providers, the important question is not only whether a credential is protected, but whether each high-value operation can still be trusted when the app is exposed to the realities of mobile deployment.
Why Wallet Security Must Protect Operations, Not Just Credentials
A wallet operation is more than a cryptographic event. It is a sequence of application logic, user interaction, device-state assumptions and server-side trust decisions.
A credential presentation, for example, depends on the integrity of the screen shown to the user, the authenticity of the relying party, the accuracy of the requested attributes, the state of the device and the behaviour of the application code controlling the flow.
This distinction matters because attackers often look for the weakest link around the protected asset rather than the protected asset itself. If the app can be made to present the wrong relying party, suppress a warning, automate a consent step or send a request from an unexpected device state, the result may still look technically valid to another system.
Where Runtime Attacks Enter the Wallet User Journey
Runtime attacks are dangerous because they target the active user journey rather than the credential container alone. They can affect what the app displays, how the user responds, what values are passed between functions and what evidence reaches the backend.
This is why wallet teams need to think in terms of protected operations. Device registration, wallet activation, credential issuance, attribute presentation, account recovery and signing each create different opportunities for manipulation.
Looking at the wallet through these flows helps security teams move beyond a generic list of threats. It also makes it easier to decide where runtime evidence is most useful, which controls should operate silently, and where the user or backend should be asked for stronger assurance.
Why Real Devices Are Difficult Trust Environments for Wallet Apps
Mobile applications operate in environments that wallet providers do not fully control.
Backend services can be configured, monitored and restricted within managed infrastructure. A wallet application, by contrast, leaves that controlled environment as soon as it is installed.
It may run across thousands or millions of devices with different hardware, operating-system versions and patch levels. It also shares those devices with other applications, including software from unofficial sources or apps with powerful permissions.
During attribute presentation, authentication, data disclosure or electronic signing, runtime interference can turn a valid-looking request into an untrustworthy operation. The risks include identity misuse, privacy compromise, fraudulent approval or unauthorised use of credentials.
These conditions make device and application signals important. A suspicious runtime environment does not automatically prove fraud, but it can change the level of confidence a wallet provider should have before allowing a high-risk action to continue.
In practice, this means a wallet may need to treat the same request differently depending on its runtime context. A low-risk attribute disclosure on a healthy device may be handled normally, while a recovery attempt from a rooted device, a modified app or an emulator may require additional checks or be blocked entirely.
Runtime Threat Patterns that Matter for Wallet Operations
If an attacker gains sufficient influence over the application’s runtime environment, they may not need to break its encryption or extract a protected private key.
Instrumentation frameworks can observe how the application behaves while it is running. Hooking can intercept or modify calls between the application, libraries and operating system. Debuggers may reveal sensitive logic, data or control flows, while rooted or jailbroken devices can weaken platform restrictions.
An attacker may use these capabilities to bypass local checks, alter values in memory, invoke protected functions or change the sequence of a sensitive operation.
For example, the credential itself may remain securely stored while the application workflow controlling its presentation is manipulated. The cryptographic operation may be valid, but the information shown to the user before approval may have been altered.
These attacks are especially relevant for wallet applications because many critical decisions happen in the mobile layer before the backend receives a request. If the app has already accepted manipulated input or skipped part of a local flow, the server may only see the final request, not the unsafe path that produced it.
Why Backend Trust Decisions Need Mobile Runtime Evidence
Secure APIs, encrypted communications, authenticated sessions and protected backend infrastructure are essential, but they cannot detect every attack taking place inside the mobile application.
A backend service may receive a correctly structured and authenticated request over an encrypted connection. From the server’s perspective, the request may appear valid.
However, the application generating that request could have been modified. A hooking framework could have altered a value before transmission. Malware could have automated the interaction. An overlay could have misled the user about what they were approving.
Traditional perimeter controls protect the route between the app and the server. They do not necessarily establish whether the application itself is genuine, whether its execution has been manipulated or whether the user interface can be trusted.
EUDI Wallet security therefore needs both sides of the architecture to participate in the trust decision: the application detects relevant threats, and the backend evaluates those signals before allowing sensitive operations to continue.
This does not mean transferring every decision to the server. Instead, the goal is to create a feedback loop between the app and backend, where runtime signals, application integrity, device state and operation sensitivity are assessed together. That model allows the wallet to respond proportionately rather than relying on static rules that may be too weak for high-risk flows and too disruptive for ordinary use.
Tampering and Repackaging: When the Wallet App is No Longer the App You Released
Code tampering changes the behaviour of a legitimate application. Repackaging embeds malicious functionality into a modified version and redistributes it through unofficial channels.
A repackaged wallet may retain the branding, interface and much of the functionality of the genuine application. To the user, it may appear legitimate. Behind the interface, however, it could capture information, redirect communications, disable security checks or modify how credentials are presented.
Code signing and trusted application stores can reduce this risk, but wallet applications should also be able to verify their own integrity while running.
Runtime integrity checks can help identify modified code, resources or execution flows. Code and asset protection can also make it harder to analyse the application, locate sensitive logic and produce a functioning malicious version.
For EUDI Wallets, this is not simply a brand-protection issue. A modified wallet app could undermine the integrity of credential presentation, consent capture, session handling or communication with relying parties. Runtime checks help reduce the chance that a compromised application can continue to operate as if it were trusted.
Overlays and Automation: When User Consent Can No Longer Be Trusted
The user interface is a critical security boundary because many wallet operations depend on informed approval.
An overlay attack places a malicious screen over part or all of the legitimate application. The user may believe they are interacting with the wallet while entering information into an attacker-controlled interface or approving a misrepresented credential, relying party or transaction.
Accessibility services can create similar risks when they are abused to observe interactions, capture displayed content or generate automated input. Screen mirroring, synthetic input and malicious automation can further weaken the connection between the user’s intent and the operation ultimately performed.
The underlying cryptography may continue to function correctly throughout such an attack. That is precisely why protecting the user journey matters.
Wallet teams should therefore consider consent as a protected process, not just a screen or button. The app needs confidence that the user is seeing the intended information, interacting through an expected channel and approving the operation that will actually be performed.
Building a Risk-Based Response for EUDI Wallet Operations
A strong runtime security model should identify the operations whose manipulation could cause the greatest harm.
These are likely to include wallet activation, device registration and binding, user authentication, credential issuance, attribute presentation, consent, account recovery and electronic signing.
For every sensitive operation, the team should ask whether an attacker could alter application logic, manipulate the interface, replay a request, automate an interaction, clone a session or invoke the operation from a modified application.
Under what runtime conditions should the wallet permit, challenge, restrict or block this operation?
The answer should reflect the sensitivity of the action. Not every detected anomaly requires the application to shut down. A binary “trusted or untrusted” model can create unnecessary friction, false positives and accessibility problems.
A low-risk function may be allowed to continue while additional evidence is collected. A credential presentation may require stronger authentication. Recovery, registration or signing may be restricted when clear evidence of tampering, hooking or automation is present.
This approach also supports usability. Instead of imposing the strongest control on every action, the wallet can reserve stricter responses for operations where the potential impact justifies them. That helps maintain a smoother experience while still treating high value flows with appropriate caution.
How MASC Supports Runtime Protection for High-Value Mobile Wallet Flows
Cryptomathic’s Mobile Application Security Core (MASC) is designed to protect high-risk mobile applications against threats that appear after deployment.
MASC combines protection inside the application with server-side verification and security policy. This allows wallet providers to detect manipulation on the device and use verified runtime signals when deciding whether a sensitive operation should proceed.
MASC Core embeds security controls directly into Android and iOS applications. These controls can help identify rooted or jailbroken devices, hooking, debugging, instrumentation, emulators, overlays, screen mirroring, synthetic input and signs that an application has been modified or installed through an unexpected route.
It also provides capabilities for code and asset protection, runtime integrity checking, secure storage, device-bound protection and stronger network and session security.
These controls help defend the wallet instance itself: the code performing the user journey, communicating with services and invoking protected cryptographic operations.
MASC Assurance extends this model to the server side. It verifies integrity signals from the mobile application and evaluates them against centrally managed policy. The backend can then decide whether to allow, report, challenge, restrict or block an operation according to its sensitivity and the evidence available.
For organisations preparing EUDI Wallet services for production, this combination is useful because protection does not stop at the mobile boundary. Signals from the app can become part of a wider trust decision, helping teams connect mobile threat detection with backend enforcement, fraud monitoring and operational response.
Go deeper into EUDI Wallet application security. Download our whitepaper, The European Digital Identity Wallet, for a closer look at the EUDI Wallet attack surface, risk assessment, threat modelling and the role of mobile application security.
How Runtime Protection Complements Cryptography & Secure Hardware
MASC does not replace the secure cryptographic components within an EUDI Wallet architecture.
Wallet Secure Cryptographic Devices, Wallet Secure Cryptographic Applications, hardware-backed keystores and certified cryptographic modules remain essential for protecting critical assets and executing sensitive cryptographic functions.
MASC addresses a different but connected part of the architecture: the application and runtime environment surrounding those components.
Secure hardware can prevent a private key from being exported. MASC can help detect whether the application requesting use of that key has been modified or instrumented. Encryption can protect stored credentials, while runtime protection helps secure the workflow through which those credentials are accessed and presented. In this way, application-level protection supports the wider wallet security model without replacing the cryptographic controls it depends on.
The result is a layered model: cryptographic controls protect the keys and credentials, platform controls support secure execution, and runtime application security helps determine whether the mobile app invoking those controls is still operating in a trustworthy way.
Strengthen EUDI Wallet Runtime Security with Cryptomathic MASC
For teams already building or securing wallet services, the next step is to assess which operations need runtime evidence, how device and application signals should influence backend decisions, and where additional protection is needed around the most sensitive user journeys.
Explore how Cryptomathic MASC can support runtime protection for EUDI Wallet applications, helping teams address tampering, overlays, compromised-device risks and server-side trust decisions across sensitive mobile flows.