How should organisations design digital identity without creating surveillance risk?

What “minimise identity data” means in practice

Designing digital identity safely starts with data minimisation at the protocol and business-process level. The user should reveal only what the relying party needs for the specific transaction, not a reusable profile that can be stitched together across contexts. That means separating proof of entitlement from broad identity reuse, and making disclosure purpose-specific rather than all-purpose.

Selective disclosure is the practical mechanism that keeps identity verification useful without turning it into a tracking primitive. Where a credential, wallet, or federation flow supports it, disclose attributes in the narrowest form possible, for the shortest necessary time, and avoid persistent identifiers unless they are strictly required for continuity, fraud control, or legal obligation.

For cross-border and wallet-based identity models, this is exactly where architecture matters. Digital Identity, eID and Identity Wallets Guide is useful because it explains how wallets, verifiable credentials and selective disclosure are supposed to reduce unnecessary exposure rather than expand it.

How trust anchors and correlation controls limit surveillance risk

Surveillance risk appears when one trust anchor can be used as a universal join key across services, journeys or sectors. Narrow trust anchors reduce that risk by limiting what is stable, linkable and reusable. A good design keeps the verifier’s confidence high while keeping the identifier itself low-value outside the transaction that created it.

That usually means avoiding unnecessary centralisation of identity events, over-sharing of attributes, and logging that silently becomes a secondary identity graph. Organisations should also be explicit about which entities can correlate records, because even a legitimate federation layer can become a cross-service tracking layer if scope, audience and retention are too broad.

Identity lifecycle discipline matters here as well, because stale or over-retained identity artefacts often become the easiest source of long-lived linkage. NHI Lifecycle Management Guide is relevant because lifecycle control, rotation, offboarding and visibility are the controls that stop identity material from outliving its intended purpose.

Design choices that reduce correlation without weakening assurance

The safest design is not “less identity”, but “less unnecessary identity exposure”. Use pairwise or context-bound identifiers where possible, prefer claims over raw source attributes, and make sure correlation between services requires a deliberate policy decision rather than a default technical behaviour. If the same identifier appears everywhere, the system is optimized for convenience, not privacy.

Organisations should also separate identity assurance from perpetual observability. It is reasonable to verify who or what is acting at a point in time, but it is not necessary to preserve a complete behavioural trail in every dependent system. Retention, audit, and fraud detection should be scoped to the purpose, with clear rules for who can re-identify, under what authority, and for how long.

For regulated identity ecosystems, the legal framework often shapes what “narrow” must mean. eIDAS 2.0, the EU Digital Identity Framework is relevant because it formalises wallet-based digital identity and selective disclosure patterns that are intended to improve trust while limiting unnecessary disclosure.

Risk and Threat Considerations

Surveillance risk emerges when identity systems optimise for universal reuse, broad logging, or cross-service correlation instead of context-specific verification. Even when the original purpose is legitimate, the same design can enable behavioural profiling, exclusion, or quiet linkage of a person’s activity across unrelated services.

Failure mechanism: Overly stable identifiers, excessive attributes, broad trust scopes, and long-lived logs create repeatable join points that allow controllers, intermediaries, or attackers to correlate identities across contexts. Once that linkage exists, it is difficult to prove that downstream reuse is limited to the original purpose.

Impact: Users can be tracked without meaningful consent, identity data can be repurposed beyond intent, and organisations can accumulate privacy, compliance and trust exposure even if each individual transaction looks lawful in isolation.

Practitioner Guidance

What to verify: Check whether each identity transaction can complete with a minimal, purpose-bound attribute set and whether any persistent identifier is truly required. If the answer is “only for convenience”, redesign it.

Decision rule: If a verifier needs confidence but not repeatability, prefer selective disclosure, scoped identifiers, and short retention over a broad identity record. If the business process requires durable linkage, treat that as a deliberate privacy and governance choice, not a default design outcome.

What practitioners underestimate: The biggest mistake is treating logs, federation metadata, and analytics as neutral infrastructure. In identity systems, those layers often become the real surveillance surface, so the control objective is to minimise linkability at every layer, not just in the credential format.

Practitioner takeaway: Good digital identity design proves who is involved without making that person easy to follow everywhere else; if the architecture enables effortless correlation, it has already failed the privacy test.

Related resources from NHI Mgmt Group

• How should organisations design digital identity verification journeys so users complete onboarding without creating unnecessary friction?
• How should governments and service providers design mobile digital identity systems without creating unnecessary privacy risk?
• How should organisations automate identity lifecycle management without creating more risk?
• How should organisations control access to frontier AI systems without creating surveillance risk?