What breaks when a service provider relies on email address as the user key?

Email addresses change, especially during name changes, mergers, and domain migrations. If the application uses email as the primary key, JIT can create duplicate accounts or fail to reconnect a returning user to the correct record. A durable subject identifier prevents that ambiguity.

Why This Matters for Security Teams

Using email as the user key makes identity brittle because email is an attribute, not a durable subject identifier. That distinction matters during JIT onboarding, account linking, incident response, and audit trails. When a person changes names, an enterprise renames a domain, or an acquisition merges directories, the email value can change while the underlying identity remains the same. If the platform treats email as the primary key, access histories fragment and duplicate records appear.

This is not a theoretical edge case. It is the same class of identity ambiguity that shows up when downstream systems cannot reliably match a returning principal to the record that already holds roles, approvals, or entitlements. NIST’s NIST Cybersecurity Framework 2.0 emphasizes identity and access control as operational safeguards, but email alone does not give a stable trust anchor. In practice, many security teams discover this only after a migration, a merger, or a support escalation has already created duplicate access paths rather than through intentional identity design.

How It Works in Practice

The safer pattern is to separate the durable subject from the mutable contact attribute. A service should store an immutable identifier such as an IdP subject, enterprise directory GUID, or other stable claim as the primary key, then treat email as a mutable profile field. That lets JIT provisioning reconnect a returning user to the same account even if the inbox changes, while preserving the historical link between approvals, roles, and activity.

This matters most when the system performs automated account creation, token issuance, or cross-platform correlation. In an identity flow, the application should evaluate the login assertion, map it to the durable subject, then update email if the directory says it changed. The operational goal is continuity of access without conflating identity with a mailbox value. The guidance aligns with the identity assurance and access governance principles in NIST Cybersecurity Framework 2.0 and with current NHI practice described in NHIMG’s DeepSeek breach analysis, where credential and identity handling failures amplified downstream exposure.

• Use a stable subject ID from the IdP or directory as the account key.
• Store email as an attribute that can change without creating a new account.
• Reconcile updates through directory sync or verified claims, not self-service edits alone.
• Preserve audit history by linking old and new email values to the same subject.

This same design choice reduces confusion when access is paired with secrets handling, because the account that receives a token or api key remains the same even if the person’s email does not. NHIMG’s JetBrains GitHub plugin token exposure coverage shows how quickly credential misuse becomes operational when identity binding is weak. These controls tend to break down in federated environments with multiple IdPs because inconsistent subject mapping causes collisions, ghost accounts, or failed re-linking across domains.

Common Variations and Edge Cases

Tighter identity binding often increases migration overhead, requiring organisations to balance clean data model design against legacy integration constraints. That tradeoff is especially visible in partner portals, B2B SaaS tenants, and mergers where email is the only common field across systems. Current guidance suggests using email for communication and recovery, not as the authoritative key, but there is no universal standard for every legacy stack yet.

One common exception is a constrained application that only receives email from an upstream IdP and cannot persist richer claims. Even then, the application should create an internal immutable identifier on first login and store email as a changeable attribute. Another edge case is shared mailboxes or role accounts, which should not be treated as human user identities at all. Those should be governed as NHI or service account with separate controls, because the ownership model and lifecycle are different.

For teams building stronger identity governance, the practical lesson is simple: the user key must survive name changes, domain changes, and account recovery events. Frameworks such as NIST Cybersecurity Framework 2.0, OWASP NHI guidance, and CSA MAESTRO all point toward durable identifiers, clear ownership, and least-privilege access as the baseline. Email can remain an attribute, but it should never be the thing that decides whether the same person is recognised tomorrow.

Related resources from NHI Mgmt Group

• What makes a super NHI different from an ordinary service account?
• When do service accounts become a higher risk than ordinary user accounts?
• What is the difference between service account risk and user account risk in AD?
• Should organisations treat service accounts like user accounts in Dynamics controls?