What breaks when email is the primary identifier in decentralized identity flows?

Why email stops doing three jobs at once

Email works as a familiar account handle, but decentralized identity changes what that field can safely mean. In a wallet-led flow, a person may prove control of credentials without having pre-existing platform registration, so the system cannot assume email is the unique key, the verified contact point, and the proof of account ownership at the same time. The design problem is not email itself, it is overloading one legacy attribute with multiple trust functions.

That distinction matters because decentralized identity often introduces verifiable presentation, selective disclosure, and multiple issuers. A relying party may need to recognise a returning user, contact them later, or correlate records across systems, yet each of those jobs may require a different identifier model. Digital Identity, eID and Identity Wallets Guide is useful here because it shows how wallet flows separate presentation from registration and why reusable identity needs clearer identifier strategy.

When email remains the primary identifier, teams often discover that they have actually bound account creation, lookup, and recovery to one brittle field. That becomes fragile when users can hold multiple wallets, rotate credentials, or present verifiable credentials that were never issued through the local application. The safer pattern is to treat email as one optional attribute among several, not as the core identity anchor.

What breaks in account lookup, uniqueness, and recovery

The first thing that breaks is deterministic lookup. If a user can arrive with a wallet credential before the system has a local account, the application cannot assume the email address maps to exactly one record, or even to an existing record at all. Duplicate, recycled, aliased, or unverified emails can all point to the wrong person, which is especially dangerous when the application uses email as the join key across multiple services.

The second breakage is uniqueness. Email is often unique only within a given provider or organisation policy, not across identity ecosystems. In decentralized identity, the same person may present different credentials to different relying parties, and the verifier may not receive a stable, globally meaningful email claim. The consequence is a mismatch between identity proof and internal account namespace, which is why identifier design has to distinguish between subject, contact channel, and account handle. OpenID Connect Core 1.0 helps illustrate the older federation pattern where subject identifiers, claims, and relying party mapping are explicit rather than inferred from one mutable field.

The third breakage is recovery. If email is both the login key and the recovery route, then losing or changing that mailbox can collapse the account lifecycle into a single point of failure. Decentralized identity flows usually push teams toward stronger recovery rules, such as separate recovery identifiers, verified contact channels, or explicit wallet re-binding steps, because possession of a wallet credential does not automatically prove control of the historical email address.

How identifier models should change

The practical fix is to model identity in layers. Use a stable internal subject identifier for the record, use one or more attributes for discovery and communication, and bind authentication evidence to the credential or wallet presentation rather than to email alone. That lets the organisation support multiple proofing journeys without forcing every user into a legacy registration path.

Teams should also plan for correlation without overreliance. If different wallets, issuers, or verifiers can represent the same human, then the system needs explicit linking logic, governance for merge and unlink actions, and rules for when an email claim is only advisory. Ultimate Guide to NHIs, What are Non-Human Identities is not about email specifically, but it is useful background on how identity models separate the thing that is being represented from the credential or assertion used to prove it. That separation is the same design lesson here.

In practice, this usually means the application team, identity team, and product team need a shared rulebook for registration, account linking, and recovery. If the user experience still depends on email, it should be because email is the chosen contact path, not because the architecture cannot distinguish a person from an inbox.

Practitioner Guidance

What to verify: Confirm whether your product uses email for lookup, uniqueness, recovery, and audit correlation. If it does, document which of those jobs must survive when the user authenticates through a wallet or other decentralized credential.

Decision rule: If the identifier can be presented before local registration, do not use email as the primary trust anchor. Keep a stable internal identifier for the account and treat email as a mutable attribute unless the workflow explicitly proves otherwise.

Common mistake: Teams often preserve the legacy login screen but quietly change the trust model underneath it. That creates hidden coupling between account creation and proof of identity, which only shows up when two wallets, one recycled mailbox, or one changed email address map to the same person.

Practitioner takeaway: Decentralized identity does not remove the need for identifiers, it removes the safety of assuming one field can be both the human-facing handle and the proof-bearing key.

Related resources from NHI Mgmt Group

• When should organisations rethink email as the primary identifier?
• What breaks when identity governance relies on spreadsheets and email approvals?
• What breaks when access reviews are the primary identity control?
• What breaks when identity records can be changed through weak recovery or admin flows?