How can organisations tell whether a digital ID system is genuinely privacy-preserving?

Look for selective disclosure, user-controlled consent, minimal retention, and a lack of behavioural tracking across services. A privacy-preserving system should let users share only what is necessary for the transaction and should avoid creating hidden identity profiles through logging or correlation.

Why This Matters for Security Teams

A digital ID system is only privacy-preserving if it limits what is disclosed, who can correlate it, and how long the data persists. That sounds straightforward, but teams often overfocus on authentication strength and miss the privacy failure modes: overcollection, reusable identifiers, broad telemetry, and backend correlation across services. Those weaknesses turn an identity transaction into a profile-building mechanism.

Current guidance suggests checking the system against privacy principles in EU General Data Protection Regulation (GDPR) and control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, but those are only starting points. A system can still claim compliance while exposing stable identifiers, device fingerprints, or transaction logs that make cross-service tracking easy. NHI Management Group has shown how secret leakage and identity sprawl can silently expand exposure, as seen in the IOS app secrets leakage report and the Emerald Whale breach.

In practice, many security teams discover privacy erosion only after a second service can link records that were supposed to stay separate.

How It Works in Practice

The most reliable test is to follow the data flow, not the marketing language. A genuinely privacy-preserving system should prove that it uses selective disclosure, meaning the relying party receives only the attributes needed for the transaction. It should also support user-controlled consent that is specific, revocable, and understandable, rather than bundled acceptance buried in a general terms screen.

Look for technical mechanisms that reduce correlation risk. That includes pairwise or per-service identifiers, verifiable credentials that can reveal only specific claims, and minimal logging that avoids storing raw identifiers unless there is a clear operational need. Retention should be short and explicit, with separate rules for audit records and identity events. If the system uses analytics, the telemetry must be aggregated or anonymised in a way that does not enable user-level reconstruction.

• Test whether the same user receives the same identifier across services.
• Check whether optional attributes can be withheld without failing the transaction.
• Review whether consent is tied to each disclosure event, not a blanket account setting.
• Inspect logs, SDKs, and identity providers for hidden correlation keys.
• Verify retention schedules and deletion pathways for identity and transaction data.

For implementation benchmarks, teams can map controls to the privacy and logging requirements in NIST SP 800-53 Rev 5 Security and Privacy Controls and the data minimisation principles in GDPR. NHI Management Group’s broader guidance on secrets handling reinforces why identity systems must avoid persistent correlation artifacts, a lesson echoed in the Millions of Misconfigured Git Servers Leaking Secrets research.

These controls tend to break down in federated ecosystems with shared analytics, where multiple vendors can combine logs, identifiers, and device signals into a durable user profile.

Common Variations and Edge Cases

Tighter privacy controls often increase integration cost and can reduce observability, so organisations must balance user protection against fraud detection, supportability, and audit requirements. There is no universal standard for this yet, especially across wallets, identity wallets, and public sector schemes.

One common edge case is step-up verification. A system may be privacy-preserving for routine access but not for high-risk transactions that require more attributes or stronger correlation checks. Another is delegated access, where a parent, caregiver, or enterprise administrator may need limited visibility without inheriting full identity history. In both cases, best practice is evolving toward context-specific disclosure rather than one-size-fits-all identity release.

Also watch for privacy claims that rely on “we do not sell data” while still retaining enough event data to reconstruct behaviour. That is not the same as privacy-preserving design. The real test is whether the architecture prevents unnecessary collection in the first place, rather than promising restraint after collection has already happened.

Security teams should treat opaque token exchanges, cross-domain session stitching, and third-party SDK telemetry as warning signs. If a vendor cannot explain what is disclosed, how long it is retained, and whether it can be linked back across services, the privacy claim is too weak for production trust.

Related resources from NHI Mgmt Group

• How can organisations tell whether an AI system is leaking sensitive information?
• How should organisations support Digital ID without increasing privacy risk?
• Who is accountable when a certified digital ID is rejected or misused?
• How do organisations operationalise NHI ownership at scale?