How should security teams handle OAuth account merging when the identity provider email claim cannot be trusted?

Security teams should treat the returned email as an untrusted attribute, not a proof of identity. A safer pattern is to verify the user through a separate step, then merge identities only after that verification succeeds. Preserve a stable login identifier, because the email may change while the underlying account relationship should remain controlled and auditable.

Why email cannot be treated as the merge key

OAuth gives you an identity assertion from the provider, but not every claim in that assertion has the same trust value. If the email claim can be user-editable, recycled, or otherwise unverified, it should not be used as the sole basis for account linking. The merge decision should rest on a stronger proof path, plus a stable internal identifier that outlives email changes.

The core design choice is to separate who the user is from which email address they currently present. In practice, that means preserving a durable subject identifier from the provider, then treating email as a contact attribute unless the provider contract explicitly guarantees it as verified and immutable for your use case. That distinction prevents accidental cross-account merges when two people share a mailbox pattern, an address is reassigned, or the provider profile changes over time.

A useful mental model is to treat merge logic like access governance, not convenience glue. The account relationship should remain controlled and auditable even when the visible login attribute changes. For teams that manage broader identity lifecycle issues, the same discipline appears in Ultimate Guide to NHIs, where stable identity handling and lifecycle control are central to preventing unmanaged account relationships.

Safer merge patterns that reduce trust in the claim

The safest pattern is to require an additional verification step before merging, such as a confirmed existing session, a previously enrolled factor, a signed-in account recovery flow, or another control that ties the person to the destination account. The merge should happen only after that step succeeds, and it should be recorded as a deliberate account-linking event rather than an automatic side effect of login.

Where possible, anchor the account to an immutable provider subject and store email as a mutable profile field. If the provider exposes a stable subject identifier, use that as the foreign key for future logins. If not, create your own internal subject record and maintain an explicit mapping between the external identity and the local account. That makes merges reversible, reviewable, and easier to investigate when a user changes email or an upstream directory changes semantics.

Operationally, teams should also decide whether email collisions are ever allowed to trigger auto-merge. In most environments, the answer should be no. Auto-merge can be appropriate only when the provider supplies a verified, non-reassignable email claim and the application’s risk tolerance is low enough to accept that trust model. When the claim quality is uncertain, manual or step-up verification is the safer default.

For practitioners building identity controls around external login flows, the broader principle is the same as the one documented in Top 10 NHI Issues: treat identity-bearing data as something to govern, not something to assume. And because OAuth linkage is often part of a larger identity lifecycle, The State of Non-Human Identity Security is a useful companion for understanding how poor lifecycle controls turn into account sprawl and control loss.

Risk and Threat Considerations

When email is treated as proof of identity, the main risk is account takeover through false linkage, not just login inconvenience. A recycled address, a provider profile edit, or an unverified email claim can cause two distinct accounts to be merged incorrectly, which may expose private data, alter authorisation history, or let an attacker inherit an established account relationship.

Failure mechanism: The application trusts an attribute that is easy to change or insufficiently bound to the actual account holder, then uses that attribute to join identities without a second proof step. Once merged, the attacker does not need to defeat the original account directly, because the system has already rewritten the relationship in their favour.

Impact: Incorrect merges can lead to silent privilege transfer, data exposure, broken audit trails, and difficult recovery because the damage looks like a legitimate account action. In higher-value systems, a bad merge can become the starting point for lateral movement across linked services or for abuse of previously trusted access paths.

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, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication and Access Control	Stable subject mapping and controlled account linking are core identity access controls.
	PR.AC-4 — Access Permissions and Authorizations	Account merges can transfer effective access, so authorization must remain explicit and reviewable.
	GV.OC-3 — Mission Objectives and Risk Considerations	Merge trust assumptions should reflect business risk and identity assurance requirements.
Recommendation — Use PR.AC-1 to bind external identities to a durable internal account and gate merges on stronger proof. Apply PR.AC-4 to keep merged-account permissions explicit and prevent unintended privilege inheritance. Use GV.OC-3 to define when email is sufficient and when step-up verification is mandatory.
CIS Controls v8	5.3 — Manage Account Lifecycle	Account linking and merge events are part of lifecycle governance, not just login behavior.
	6.3 — Data Recovery Processes	Bad merges can require rollback and restoration of account state and audit context.
Recommendation — Use Control 5.3 to require explicit approval and auditability for identity merges. Use Control 6.3 to ensure you can recover from an incorrect account-linking event.
NIST SP 800-63	5.2.3 — Federation and Assertion Processing	Federated assertions require validated attributes and controlled mapping to local accounts.
	6.3.2 — Binding and Rebinding	Account binding must resist unsafe relinking when identity attributes change.
Recommendation — Use 5.2.3 to validate assertion semantics before using email to bind or merge accounts. Use 6.3.2 to require re-binding safeguards before associating a new federated identity with an existing account.
NIST Zero Trust (SP 800-207)	AC-3 — Session and Access Authorization	Zero Trust expects access decisions to rely on current, verified context rather than a single mutable claim.
Recommendation — Apply AC-3 to re-evaluate access when identity evidence changes and avoid implicit trust in email.
OWASP Non-Human Identity Top 10	NHI-01 — Identity and Ownership	The same identity governance problem appears when external account relationships are not anchored to stable ownership.
	NHI-06 — Identity Lifecycle and Offboarding	Incorrect merges create lifecycle confusion and make reversal, revocation and audit harder.
Recommendation — Use NHI-01 to separate identity ownership from mutable attributes like email. Use NHI-06 to require explicit lifecycle records for every merge and unmerge event.

Practitioner Guidance

What to verify: Verify which upstream claims are actually guaranteed by the provider contract, and whether email is immutable, verified, or merely present. If the provider does not give a durable subject identifier, treat the merge design as high risk and require explicit user proof before linking accounts.

Decision rule: If the claim can change, be reassigned, or be supplied without strong verification, do not let it auto-merge accounts. Use a separate confirmation path, then store the merge event with the provider subject, timestamp, and operator or user action that authorised the linkage.

Practitioner takeaway: The right control is not “trust OAuth less”, it is “trust the right OAuth data for the right purpose”, with email kept as a mutable attribute and account linking gated by stronger evidence.