How should organisations balance digital identity wallet convenience with privacy and tracking risk?

Why This Matters for Security Teams

digital identity wallet promise a better user experience, but the convenience problem is really a privacy problem. Every extra attribute, persistent identifier, or shared token can become a tracking signal across services. Security and privacy teams need to decide not only what a wallet can prove, but also how much correlation it enables over time. That tension is central under EU General Data Protection Regulation (GDPR) and the emerging EU digital identity model in eIDAS 2.0.

For NHIMG practitioners, the key question is whether the wallet reduces friction without creating a reusable identity trail that outlives the transaction. Centralised issuance, broad attribute bundles, and long-lived identifiers can all increase linkage risk, even when authentication is technically strong. The same design choices that make a wallet easy to use can also make it easy to profile, replay, or over-collect.

In practice, many security teams discover tracking risk only after multiple relying parties have already consumed the same stable identifier.

How It Works in Practice

Balanced wallet design starts with data minimisation: share the fewest attributes needed for the transaction, and prefer selective disclosure where the wallet can prove a claim without revealing the underlying identifier. Current guidance suggests treating persistent identifiers as exceptions, not defaults. That means separating authentication from correlation, so the wallet can prove age, residency, or employment status without handing every service the same user-wide handle.

Operationally, teams should define the wallet trust model before rollout. That includes who issues credentials, who can revoke them, how metadata is logged, and whether the wallet or issuer can observe every presentation event. A useful reference point is the broader identity hygiene problem described in the Ultimate Guide to NHIs, which shows how poor lifecycle control and overexposure create avoidable risk. Even though wallets are human-facing, the same pattern applies: if the system retains too much detail for too long, it becomes easier to correlate activity across contexts.

• Use pairwise or service-specific identifiers where possible, rather than a single global identifier.
• Minimise stored claims and set short retention windows for presentation logs and telemetry.
• Separate issuer analytics from relying-party logs to reduce central visibility into user movement.
• Prefer explicit user consent for sensitive attribute release, but do not rely on consent alone as a privacy control.

Security controls should also align with baseline identity governance, including NIST Cybersecurity Framework 2.0 and appropriate privacy controls from NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when a wallet is used across many relying parties that all demand a stable identifier because correlation risk becomes structurally unavoidable.

Common Variations and Edge Cases

Tighter privacy controls often increase friction for account recovery, fraud detection, and cross-service continuity, so organisations must balance user convenience against the loss of observability. There is no universal standard for this yet, especially where wallets support both high-assurance identity proofing and everyday logins.

One common edge case is regulated access, where a relying party may legitimately need stronger assurance or auditability than a low-risk consumer app. Another is delegated or shared wallet use, where the organisation must decide whether the wallet binds to a person, a device, or a credential set. Best practice is evolving, but current guidance leans toward privacy-preserving defaults with narrowly scoped exceptions. For that reason, teams should document when they may request more data, who approves the exception, and how long the extra data may be retained.

NHIMG’s research on Ultimate Guide to NHIs and the The 2024 ESG Report: Managing Non-Human Identities shows how identity sprawl and weak governance create risk at scale; wallet programs can repeat the same mistake if central platforms accumulate too much linkage data. Organisations should accept that a perfect balance is unlikely, then tune the design toward minimal disclosure, short retention, and auditable exceptions.

Related resources from NHI Mgmt Group

• Why do organisations need to verify identity at every access request for high-risk digital services?
• Why do hybrid identity environments often create more access risk when organisations split credential management between legacy and cloud systems?
• Why do privacy-preserving identity controls matter when organisations collaborate on fraud detection?
• What breaks when organisations do not have a unified view of SaaS identity risk?