Email-based identities create risk because email addresses are not stable identifiers. Name changes, domain migrations, rebrands, and acquisitions can all change the upstream record without changing the person behind it. If the application does not receive that update, identity drift appears, and teams end up with mismatched records across systems that should agree.
Why This Matters for Security Teams
Email looks convenient because it is human-readable, already present in directories, and often reused as the login name in SSO. The problem is that an email address is an attribute, not a durable identity anchor. When it becomes the primary identifier, downstream applications inherit instability from HR changes, mergers, domain changes, and mailbox reassignments. That creates identity drift across the IdP, the directory, and the application layer.
This matters because drift is not just an admin nuisance. It can produce duplicate accounts, stale entitlements, broken joins, and incorrect deprovisioning logic. In environments where SCIM, directory sync, and just-in-time provisioning all depend on the same email value, a simple rename can look like a new person or, worse, hide the fact that an old account still has access. NIST’s Cybersecurity Framework 2.0 treats identity management as an operational control problem for exactly this reason.
NHIMG research on the Ultimate Guide to NHIs also shows how quickly weak identity hygiene becomes a security issue when records stop matching reality. In practice, many security teams encounter identity drift only after access reviews, support tickets, or an offboarding failure has already exposed the mismatch.
How It Works in Practice
The safest pattern is to treat email as a contact attribute and use an immutable identifier as the system of record. That usually means an employee ID, a directory object GUID, or an external subject identifier from the IdP. The application then maps email to the person, but does not rely on email as the authoritative key for authorization or lifecycle actions.
In SSO and directory sync environments, this distinction matters at every step. If the IdP sends the same person with a new email after a domain migration, the app should update the profile rather than create a second account. If SCIM is in use, the sync job should match on the stable identifier and treat email changes as profile updates. If the app cannot do that, teams need compensating controls such as manual reconciliation, alias handling, and step-up review for renamed accounts.
- Keep one immutable identifier for join, sync, and deprovisioning decisions.
- Allow email aliases for sign-in convenience, but do not use them as the primary key.
- Track rename events, domain changes, and mergers as identity lifecycle events.
- Reconcile stale accounts after every sync failure or directory schema change.
For practitioner guidance on where identity assumptions fail, NHIMG’s Top 10 NHI Issues is a useful reference because the same pattern appears whenever a system confuses a convenience label with a control-grade identifier. These controls tend to break down when legacy applications only support email-based matching because the directory can no longer distinguish a renamed user from a newly provisioned one.
Common Variations and Edge Cases
Tighter identity binding often increases operational overhead, requiring organisations to balance clean governance against legacy compatibility and user friction. That tradeoff is unavoidable in mixed estates, especially when some SaaS apps only accept email addresses for login or account linking. Current guidance suggests preserving email for user experience while moving authorization, audit trails, and account lifecycle decisions to stable identifiers.
There is no universal standard for this yet, but the direction of travel is clear: best practice is to separate identity proof, login alias, and account key. This becomes especially important during acquisitions, rebrands, and mailbox consolidation, where the same person may appear under multiple emails over time. If an application cannot store a durable subject identifier, teams should document the limitation, tighten offboarding checks, and test whether a rename causes account duplication or entitlement loss.
One useful rule is to ask whether the system can answer three questions without email changing the result: who is this, what is this account allowed to do, and how is it revoked? If the answer is no, the environment is relying on a mutable attribute as if it were an identity control. That is a design flaw, not just a directory hygiene issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity drift breaks reliable identification and access decisions across systems. |
| NIST SP 800-63 | AAL | Email is a weak subject key when identity proofing and account binding must stay stable. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous identity validation beyond a mutable email alias. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Mutable identifiers cause lifecycle and ownership errors for non-human and human identities alike. |
| NIST AI RMF | Identity drift creates governance and accountability gaps in automated environments. |
Bind accounts to immutable subjects, not mutable email values, during identity lifecycle changes.
