When should organisations rethink email as the primary identifier?

Why This Matters for Security Teams

Email is a useful human-centric identifier, but it becomes fragile once identity is no longer tied to a single inbox and password flow. The moment users can arrive through wallets, external issuers, passkeys, or account-free journeys, email stops being a reliable anchor for trust and starts acting like a loose label. That creates account-linking drift, recovery ambiguity, and avoidable privacy exposure when one email address is treated as the source of truth across systems.

Security teams also run into a governance problem: the identifier that helps routing communications is rarely the best identifier for authorisation, audit, or lifecycle control. Best practice is to separate the internal account ID from the login method and manage the mapping explicitly. This is consistent with NIST Cybersecurity Framework 2.0 thinking about identity governance and traceability, and it aligns with NHIMG research showing how identity and credential assumptions fail under modern attack pressure, as seen in the DeepSeek breach and JetBrains GitHub plugin token exposure cases. In practice, many security teams discover the weakness only after recovery tickets, duplicate accounts, or access disputes have already become operational noise.

How It Works in Practice

The practical shift is to treat email as an attribute, not the primary identity key. A stronger model uses an immutable internal subject identifier, then maps login methods to that record: social sign-in, enterprise SSO, passkeys, external wallet attestations, or verified email links. The mapping layer should record when an authenticator was added, what assurance it provided, and whether it can still be trusted. That is especially important when a user may have multiple valid entry points over time.

For security governance, this means separating three decisions: who the subject is, how they authenticate, and what they are allowed to do. Current guidance suggests using the internal ID for RBAC, audit logs, and recovery workflows, while treating email as one of several verifiable contact or recovery channels. That approach reduces brittle coupling if a mailbox changes, disappears, or belongs to a federated provider outside your control. It also fits the broader identity direction in NIST Cybersecurity Framework 2.0, where identity proofing, access management, and monitoring are treated as distinct control concerns.

• Use a stable internal subject ID for records, entitlements, and audit trails.
• Bind each login method to the subject with explicit assurance metadata.
• Separate recovery from authentication so one weak channel does not define the account.
• Review link expiry, account merging, and unlinking rules as first-class security controls.

NHIMG research on the DeepSeek breach shows how quickly identity assumptions can collapse when exposure expands beyond a single trusted boundary, while the JetBrains GitHub plugin token exposure illustrates how a compromised token can become a durable access path if identity mapping and revocation are not explicit. These controls tend to break down when organisations allow self-service account linking across loosely verified channels because the system can no longer distinguish a legitimate identity merge from a takeover attempt.

Common Variations and Edge Cases

Tighter identity binding often increases operational overhead, requiring organisations to balance user convenience against recovery complexity and support cost. That tradeoff matters most in customer-facing systems, contractor portals, and B2B platforms where one person may authenticate through different issuers over time.

There is no universal standard for this yet. Some platforms still use email as the visible username while keeping an immutable backend subject key, which is usually acceptable if the email is not used for authorisation or recovery decisions. Other environments need stronger identity proofing when the user can regain access through multiple external wallets or enterprise tenants, especially where account reuse and identity portability are expected.

The main exception is regulated or high-risk workflows where email may remain a notification address but should not drive access decisions. In those cases, use explicit lifecycle rules for linking, unlinking, and step-up verification. Where account-free journeys are involved, the best practice is evolving toward consented, context-aware identity mapping rather than a single canonical address. That is also where auditability matters most, because the wrong link can silently merge two distinct identities into one record.

For teams still transitioning, the practical test is simple: if losing control of an inbox would mean losing control of the account, email is carrying too much identity weight.

Related resources from NHI Mgmt Group

• When should organisations require step-up verification for access?
• How can organisations reduce authentication risk for both users and NHIs?
• How should organisations reduce MFA-related account takeover risk?
• When should organisations add step-up authentication during a session?