The application can confuse a mutable contact attribute with a stable identity, which allows cross-tenant impersonation when an attacker can present an unverified email claim. In practice, that means the wrong person can be merged into the wrong account, and the customer has little visibility into the failure once sign-in succeeds.
Why email is the wrong identifier for federated sign-in
Email is a contact attribute, not a durable account key. In a federated model, the assertion from the identity provider should bind to a stable subject identifier, while email remains an attribute that can change when a person changes employers, gets renamed, or reclaims an address. If the SaaS app keys accounts on email instead, it turns a mutable field into the basis for trust and account linkage.
That design works until the same mailbox value can be presented by more than one real-world person over time, or across tenants. At that point, the application is no longer matching “who this is” on a stable identity claim, it is matching “which address is present right now,” which is a much weaker security property.
How cross-tenant account confusion happens
The failure mode usually appears during first login, account linking, or just-in-time provisioning. If the app treats an incoming email claim as proof of identity, a federated user from one tenant can land in an existing account that was created for a different tenant or a previous owner of the same address. The break is not authentication itself, it is the account-resolution step after authentication.
Good implementations separate authentication from account correlation. They rely on a stable issuer plus subject pair, or another non-reassignable identifier, then store email as profile data that can be updated independently. For identity-layer context on that separation, the Identity Provider and SSO Security Guide and OAuth 2.0 and OpenID Connect Guide for Identity Teams both reinforce why the token subject and federation trust matter more than a mutable profile field.
What the application must trust instead
The safer pattern is to treat federation as an assertion about a subject from a trusted issuer, then map that subject to an internal user record with explicit tenant and issuer boundaries. Email can still be shown to users, used for notifications, or searched by support staff, but it should not be the primary join key for authorization or account ownership. This is especially important when the same SaaS app serves multiple customers, because tenant boundaries and identity boundaries are not the same thing.
When teams need implementation guidance on identity and provisioning, IAM and IGA Basics is useful for separating authentication, authorization, provisioning, and entitlement governance. For the protocol layer behind federated sign-in, OpenID Connect Core 1.0 shows why the ID token subject claim, not email, is the stable reference point for the relying party.
Risk and Threat Considerations
Using email as the user identifier creates a real impersonation and account-takeover risk when an attacker can obtain a trusted-looking email claim or when a mailbox is reassigned across tenants. The danger grows in SaaS environments with automatic account creation, weak tenant isolation, or support workflows that merge accounts on first sign-in.
Failure mechanism: The application binds access to a mutable attribute, then accepts a federated assertion that matches that attribute even when the underlying subject is different, which can merge the wrong identity into the wrong account.
Impact: A user can inherit another person’s entitlements, data, and tenant membership, while the compromise is hard to spot because the login appears valid from the app’s perspective.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Federated sign-in depends on stable subject binding and identity assertions. |
| Recommendation — Bind accounts to stable subject identifiers and treat email as a mutable attribute. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OIDC federation defines the claims used to authenticate and map users. |
| Recommendation — Use OIDC subject claims for account mapping, not email. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The issue is a user-authentication and account-binding failure in enterprise sign-in. |
| Recommendation — Require strong federation validation before creating or linking user accounts. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity records must be managed so mutable attributes do not become primary identifiers. |
| Recommendation — Define and govern unique identifiers separately from contact attributes. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Broken trust in federated identity claims can let the wrong user authenticate into an account. |
| Recommendation — Validate federated identity assertions before granting session creation. | ||
Practitioner Guidance
What to verify: Confirm that the SaaS app stores a stable federated subject identifier and issuer for account binding, and that email is not used as the authoritative lookup key. If your product supports multiple identity providers, verify tenant-scoped uniqueness, not just global uniqueness of email.
Common mistake: Teams often allow “helpful” auto-linking on first login because it reduces support tickets, but that convenience becomes a security flaw when mailbox ownership changes or when different tenants share the same email format. If account linking is unavoidable, require an explicit, controlled linking flow rather than silent merge behavior.
Practitioner takeaway: In federated sign-in, the safe unit of trust is the stable identity claim, not the email address; if you bind access to email, you are trusting a field that can change hands.
Related resources from NHI Mgmt Group
- How should security teams handle Microsoft OAuth logins when an app uses email as the user identifier?
- What breaks when a B2B SaaS app uses user-centric auth instead of organisation-centric tenancy?
- What breaks when a webmail app passes user-controlled email fields into mail delivery commands without strict sanitization?
- What breaks when a SaaS app can reuse Microsoft 365 tokens after sign-in?