5 min read
European Digital Identity (EUDI) Wallet programs are often described as mobile-first. And in many ways, they are: the wallet app is where credentials live, where cryptographic operations occur, and where users expect a secure, controlled experience.
But as pilots turn into real-world rollouts, a practical truth keeps showing up: Mobile-first doesn’t mean web-free.
In many journeys, users still begin (or recover, or sign) via the browser - an issuer portal, a relying party flow, a consent page, or a help desk-driven recovery step - before handing off into the wallet to complete issuance or approval. The cryptography can be solid and the wallet runtime can be hardened - yet the browser step can still shape what the user believes they’re approving and how the journey is routed.
The goal isn’t to avoid the browser. It’s to treat browser touch points as first-class components in the security architecture - so the overall journey maintains end-to-end integrity, assurance, and user intent.
Where The Web Shows Up in “Mobile-First” Journeys
If you map an EUDI wallet journey end-to-end, web pages often appear in places that feel operationally convenient - but are security-critical:
- Enrollment and onboarding portals: identity proofing initiation, account setup, issuer selection, document upload, status tracking
- Consent flows: approvals, purpose explanations, terms, attribute selection
- Recovery journeys: device change, account recovery, re-binding flows, helpdesk-driven steps
- E-signing pages: document review, signature initiation, handoff to the wallet
- Alter what the user sees or approves (consent text, relying party identity, requested attributes, purpose statements)
- Swap endpoints or redirect flows (issuer/relying party confusion, phishing-by-redirection, QR/link substitution)
- Inject scripts that tamper with the journey (DOM manipulation, form-field alteration, session hijacking patterns)
- Increase exposure via third-party scripts (tag managers, analytics, A/B testing, widgets) that weren’t designed for high-assurance identity flows
- content and logic can be modified at runtime,
- scripts are loaded from multiple sources (sometimes dynamically),
- third-party code is embedded without strong governance, and
- visibility into client-side interference is limited.
These touch points sit outside the wallet app’s protected runtime environment - and outside the controls teams typically associate with “wallet security.” That doesn’t automatically make them unsafe, but it does mean they deserve the same rigor you’d apply to the app itself.
What’s At Risk: Not Just Data, But Intent And Context
When people think “web risk,” they often jump straight to credential theft. In wallet journeys, the more subtle (and often more realistic) risk is manipulation of user intent and transaction context. Even if the wallet’s cryptographic core is strong, web steps can be targeted to:
The outcome isn’t always stolen keys. More often, a user is guided into approving the wrong thing - or the journey loses integrity somewhere between the browser and the wallet.
Why This Matters For Assurance And Rollout Readiness
EUDI wallet initiatives are increasingly shaped by assurance expectations: how you demonstrate robustness, how sensitive steps are controlled, and how the overall experience resists tampering.
That’s hard to argue convincingly if the journey includes browser pages where, in practice, teams often do an excellent job hardening the wallet app, while web portals remain governed by standard web baselines that aren’t calibrated for high-assurance identity transactions. The gap usually isn’t malicious intent - it’s organizational: different owners, different tools, different release processes.
A Practical Blueprint To Harden Web-to-Wallet Journeys
The most effective approach is to think in terms of coverage, not components:
- Harden the wallet/app runtime so critical assets and operations are resistant to tampering and runtime manipulation.
- Harden the web touchpoints so the pages involved in enrollment, consent, recovery, and signing maintain integrity - and you can detect and respond to client-side interference.
- Connect the story end-to-end so your assurance narrative covers the full user journey, not just the “secure parts.”
Below is a practical control set - organized into three categories - that many teams can apply without redesigning their entire architecture.
1) Wallet/app runtime integrity and trustworthy confirmation
Objective: make the wallet the authoritative place where users confirm critical details, and reduce the risk of runtime manipulation that could mislead users or alter intent.
Practical controls to consider (issuance, consent confirmation, recovery confirmation, signing confirmation):
- Make the wallet the final confirmation surface: The browser can explain and prepare, but the wallet should display and confirm the critical details: relying party/issuer identity, requested attributes, purpose, and transaction intent.
- Bind what the user sees to what is authorized: Ensure the user-visible details presented in the wallet are cryptographically bound to what the backend will accept - so “what I approved” matches “what executed.”
- Harden sensitive wallet flows, not just cryptography: Treat confirmation screens and handoff handlers as security-critical UI. Protect them from tampering patterns that can alter on-screen intent.
- Use integrity signals and policy for sensitive steps: Where appropriate, apply platform-native integrity checks and define outcomes (allow, step-up, restrict, or safe-fail) based on confidence.
- Design safe-fail recovery paths: When something looks off, route users to a controlled flow (step-up verification, limited capability mode, or assisted recovery) rather than silently continuing.
2) Journey integrity across web-to-wallet handoffs
Objective: preserve the integrity of what’s being requested and approved across handoffs - so user intent and transaction context remain consistent end-to-end.
Concrete design checks:
- Bind the handoff to transaction context: Integrity-protect the “what” (requested attributes / signing intent / relying party identity), not just the transport.
- Make identity explicit and consistent across steps: Users shouldn’t have to infer who they’re dealing with from a logo on a web page. Keep relying party/issuer identity clear and stable from browser → wallet → backend.
- Be deliberate about redirects, QR codes, and deep links: These are high-leverage attack points for substitution and confusion. Validate, minimize, and instrument them.
- Correlate context across systems for assurance: Ensure you can trace what was shown, what was requested, what was approved, and what was executed - across the web-to-wallet boundary.
- Define a step-up / safe-fail path: Decide what happens when integrity signals look wrong: block, step-up, degrade functionality, or route to controlled support.
3) Webpage integrity and third-party script governance
Objective: reduce the likelihood that wallet-adjacent web pages can be tampered with (or silently changed by third-party code), especially on high-assurance steps.
Practical controls for wallet-adjacent pages (onboarding, consent preparation, recovery initiation, signing initiation):
- Separate high-assurance pages from marketing pages: Don’t reuse the same templates and tag stacks. Treat these pages like transaction surfaces.
- Minimize and lock down client-side execution: Reduce inline scripts, avoid dynamic script loading, keep client logic small and auditable.
- Harden the browser runtime surface: Apply a strict CSP suitable for transactional flows, strong cookie settings, CSRF protections, and standard header hardening (e.g., clickjacking defenses).
- Deny by default for third-party scripts on high-assurance pages: If you don’t need it for the transaction, it shouldn’t run there. Treat tag managers as production code with explicit governance.
- Monitor for drift and unexpected client-side change: Inventory what actually runs in production, detect changes, and alert - especially during consent and recovery flows.
- Treat QR/deep link parameters as part of the trust chain: Validate and instrument them the same way you would APIs.
Quick Self-Check: Are Your “Browser Steps” Treated As High Assurance?
If any of these are true, the browser is part of your assurance story:
- Your portal displays or influences consent text, attributes, or purpose
- A web step initiates issuance, signing, recovery, or re-binding
- You rely on QR codes, deep links, or redirects for handoff
- You run tag managers/analytics on pages that affect wallet actions
- You can’t easily answer: “Which scripts ran on this page for this user at this time?”
Why This Is A Joint Problem - And A Joint Opportunity
In many programs, the wallet provider focuses on app security and cryptographic robustness, while system integrators and relying parties own the portals that initiate or support the journey. That division of labor is normal - but security coverage must still be continuous.
The opportunity is to align stakeholders on a shared model:
- Which parts of the journey are high assurance
- Which controls are mandatory on those steps
- How you monitor integrity in production
- How you tell the end-to-end assurance story
Join The Webinar: Harden The Overlooked Steps
If your EUDI wallet initiative includes any browser-based touch points - enrollment, consent, recovery, or signing - those steps are part of your security posture and your assurance story.
In our 45-minute joint session with Cryptomathic and JScrambler, we’ll walk through a practical end-to-end model and share a reference blueprint for closing the web-to-wallet gap - including a checklist you can use to review your own journeys.
Cryptomathic will cover end-to-end journey integrity and wallet-side confirmation - how to preserve user intent across web-to-wallet handoffs, and how to harden the wallet runtime so approvals remain trustworthy.
JScrambler will cover webpage integrity and client-side protections - how to reduce tampering risk on browser steps that initiate or influence wallet actions.