Teams often assume that a matching email means the same person, when it only means the same address value. If the application does not verify ownership before linking accounts, an attacker can collide with the victim identity and inherit the victim’s access inside the app.
Why This Matters for Security Teams
Account merging sounds like a convenience feature, but in multi-IdP applications it becomes an identity-binding control point. The real risk is not authentication, but mistaken account correlation across identity providers, tenants, or trust domains. If an application merges profiles on email alone, it can silently convert an unverified overlap into a privilege transfer. That is an authorization failure disguised as a login feature.
Current guidance from NIST Cybersecurity Framework 2.0 and NHI governance research from Ultimate Guide to NHIs both point to the same operational lesson: identity assertions must be verified, contextual, and continuously governed, not assumed to be equivalent because they look similar. In multi-IdP environments, the same email can appear in different administrative domains, be recycled, or be attacker-controlled during onboarding. Once an app links identities incorrectly, downstream entitlements, audit trails, and session history can all become misleading.
In practice, many security teams discover account-linking flaws only after a support ticket, a takeover attempt, or an unexpected access review reveals that two different people were treated as one.
How It Works in Practice
Safe account merging starts by separating identity proof from profile convenience. The application should not treat a shared email address as a unique global identifier unless it has first verified control of that mailbox and confirmed the issuer trust path. In multi-IdP designs, the primary binding should be a stable subject identifier from the IdP plus an explicit link approval workflow, not just a matching claim.
Practitioners usually need three layers of control:
- Verified ownership: require re-authentication or step-up verification before any merge or link action.
- Binding rules: tie the local account to issuer, subject, tenant, and assurance level, not email alone.
- Reviewable exceptions: route ambiguous collisions to human approval and log the full decision trail.
This is where Ultimate Guide to NHIs is relevant even for human-account workflows: identity lifecycle hygiene, offboarding discipline, and visibility into linked credentials are the same governance problems in different form. For implementation, teams often align with NIST Cybersecurity Framework 2.0 by treating account linking as an access control event, not a profile update. That means logging the source IdP, assurance strength, timestamp, and approver, then revoking the merge if the proof of ownership expires or is later disproven.
Where this guidance tends to break down is in applications that auto-link legacy directories, SaaS SSO, and social login accounts into one record without preserving issuer-specific provenance and verification state.
Common Variations and Edge Cases
Tighter merge controls often increase user friction and helpdesk load, requiring organisations to balance takeover resistance against onboarding speed. That tradeoff matters most when the same person legitimately uses multiple IdPs, such as a corporate SSO account, a contractor identity, and a personal recovery login.
There is no universal standard for this yet, but current guidance suggests treating edge cases as policy decisions, not engineering shortcuts. For example, email recycling, plus-addressing, aliases, and federated identity changes after mergers or acquisitions can all create false matches. A user may also arrive through two IdPs that assert the same email with different assurance levels. In those cases, the safer pattern is to keep accounts separate until the user proves continuity, then merge only the local application profile while retaining distinct external identifiers.
Teams should also be cautious with administrative overrides. A support agent who force-merges accounts without strong verification can create irreversible privilege inheritance and audit ambiguity. The practical rule is simple: if the application cannot explain exactly why two identities are linked, security teams should assume the link is unsafe. This becomes especially fragile in high-volume consumer apps, partner portals, and B2B platforms where identities are frequently reused, delegated, or provisioned outside central control.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity binding errors create unauthorized access paths through merged accounts. |
| NIST CSF 2.0 | PR.AC-1 | Account merging is an access control decision that must be verified and logged. |
| NIST AI RMF | Identity-risk decisions need governed, traceable processes aligned to AI risk principles. |
Document merge policy, exception handling, and oversight so identity decisions remain explainable.
