nOAuth abuse exposes a cross-tenant account takeover gap

At a glance

What this is: This research shows how nOAuth abuse turns mutable email attributes and weak OIDC handling into cross-tenant account takeover in Entra-connected SaaS.

Why it matters: It matters because IAM teams cannot treat SaaS account linking, tenant trust, and claim handling as developer details when those choices decide whether identity is stable enough to govern.

Context

nOAuth is a cross-tenant identity abuse pattern in which a SaaS application treats a mutable email attribute as a stable user identifier. When that application also trusts an unverified email claim from Entra ID, an attacker can impersonate another tenant’s user if the app’s account-linking logic is weak.

The governance problem is not just a bad claim choice. It is a broken trust model between Entra tenants and the SaaS application, where identity stability, verification, and ownership are assumed rather than enforced. For IAM and SaaS governance teams, that makes the application’s authentication design part of the control surface, not a developer-only implementation detail.

Key questions

Q: What breaks when a SaaS app uses email as the user identifier in federated sign-in?

A: 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.

Q: Why does nOAuth create account takeover risk even when Entra ID authenticates the user?

A: Because authentication and account binding are not the same control. Entra ID may authenticate the session correctly, but the application can still map that session to the wrong local account if it trusts email rather than immutable OIDC identifiers. The failure is in the SaaS layer’s identity correlation logic.

Q: What are the signs that a SaaS application is vulnerable to nOAuth abuse?

A: Look for applications that merge accounts by email, accept unverified email claims, or cannot clearly explain how they bind federated identities across tenants. If the vendor cannot describe the exact identifier logic, assume the application needs deeper testing before it is trusted for sensitive data.

Q: Should organisations rely on certifications to rule out nOAuth risk?

A: No. Generic certifications do not prove that a SaaS application rejects unverified email claims or binds identities correctly across tenants. Organisations need targeted testing and vendor-specific assurance because the vulnerability lives in the application’s authentication design, not in the presence of an attestation logo.

Technical breakdown

How mutable email claims become a cross-tenant identity flaw

nOAuth abuse works because email is often treated as if it were a stable identifier, even though email addresses can change, be reassigned, or exist without verified ownership in federated contexts. In the flow described by Semperis, an attacker can set or present an unverified email address, then rely on an application that maps accounts by email rather than by the immutable issuer plus subject pair defined by OIDC. The failure is not token theft. It is the app’s decision to equate a mutable contact attribute with identity.

Practical implication: applications must not use email as the unique account key for federated sign-in.

Why Entra tenant boundaries do not protect weak SaaS account linking

Entra ID can emit claims that are valid for authentication but still unsafe for authorization if the application builds its own account merge or matching logic on top. That is why multi-tenant SaaS designs are especially exposed: the identity provider may authenticate the sign-in correctly, but the application then joins that identity to the wrong local account. The result is cross-tenant impersonation, not because federation failed, but because the SaaS layer substituted convenience for stable identity binding.

Practical implication: validate how every SaaS app binds federated identities before trusting tenant boundaries.

Why detection is weak once the application accepts the wrong identity

Once the application accepts the attacker as the victim, the abuse looks like a legitimate session from the app’s point of view. That makes customer-side detection extremely limited, especially when the SaaS vendor does not log the linking decision, the claims used, or the original trust failure in a way customers can inspect. Semperis also notes that customers have little to no remediation leverage unless the vendor changes the application to stop trusting unverified email claims. This shifts the control point to application design and vendor assurance.

Practical implication: treat claim handling and account-linking telemetry as vendor assurance requirements, not optional debugging data.

Threat narrative

Attacker objective: The attacker aims to impersonate a legitimate user inside the target SaaS application and inherit that user’s access to data and actions.

1. Entry begins with access to an Entra tenant and knowledge of the target user’s email address, which is enough to start the abuse path when the SaaS application trusts email as identity.
2. Credential or identity abuse occurs when the application accepts an unverified email claim or maps a federated account to the wrong local user record.
3. Escalation follows when the attacker inherits the victim’s application session and can operate with that user’s in-app permissions.
4. Impact is account takeover inside the SaaS application, with potential persistence, lateral movement, and data exfiltration across whatever data the victim can access.

Breaches seen in the wild

• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mutable email trust is an identity design failure, not a claim-formatting issue. The core problem is that some SaaS applications still treat email as if it were a stable proof of user identity. That assumption breaks under federation because email can be unverified, mutable, and tenant-dependent, while OIDC already defines issuer plus subject as the stable pair. The practical implication is that identity binding has to move away from contact attributes and toward immutable federated identifiers.

Cross-tenant account takeover shows that application-layer identity logic is part of IAM governance. This is not a pure protocol issue and not a pure appsec issue. The failure sits where Entra authentication ends and SaaS account correlation begins, which is exactly where many governance programmes hand off responsibility too early. Teams need to treat account-linking behaviour, merge logic, and claim consumption as governed identity decisions, not implementation trivia.

nOAuth exposes a governance gap in vendor assurance and customer due diligence. If a customer cannot observe how a SaaS vendor binds federated identities, the customer cannot assume the application is safe simply because it supports Entra ID. Certifications and generic trust statements do not answer whether the app consumes unverified email as identity. The result is a control blind spot that belongs in procurement, security review, and ongoing assurance.

Tenant-aware identity needs immutable correlation, not convenience-based merges. SaaS teams built around frictionless sign-up and account merge logic are especially vulnerable when they prioritise user convenience over identity stability. The better named concept here is mutable-claim identity drift: the application drifts away from the user’s real identity by letting a changeable attribute anchor authentication. Practitioners should treat that drift as a structural flaw in federated identity governance.

The most important lesson is that customers cannot compensate for a broken authentication design they do not control. Semperis’ findings show that once the vendor has made the wrong identifier choice, customer-side detection and remediation become weak or impossible. That places the burden on architecture review, vendor testing, and prevention at design time rather than after compromise.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Mutable-claim identity drift: When a SaaS application lets a changeable email attribute anchor identity, the programme loses the stability assumption that federation depends on. That means vendor review must examine account-linking logic and claim handling, not just whether Entra ID is supported.

For IAM and SaaS governance teams, the useful question is no longer whether sign-in works, but whether the application can prove it binds the right person to the right account across tenants. If it cannot, the control failure sits in the identity design itself.

For practitioners

• Enforce immutable federated identifiers Require SaaS applications to bind accounts on issuer plus subject, not on email or any other mutable claim used as a primary identifier.
• Test account-linking and merge logic Validate how each SaaS application handles first sign-in, account matching, and multi-identity-provider merge flows before allowing production use.
• Review app registrations for unverified email handling Check whether the application consumes unverified email claims and whether its configuration still permits them to drive identity decisions.
• Add vendor assurance questions to procurement Ask vendors whether they have specifically tested for nOAuth abuse and whether they can explain exactly how their application prevents email-based impersonation.

Key takeaways

• nOAuth abuse turns a familiar federation feature into a cross-tenant takeover path when applications trust mutable email claims as identity.
• Semperis found 9 vulnerable applications in a test set of 104, showing that the pattern is not theoretical or rare enough to ignore.
• The critical control is immutable identity binding on issuer plus subject, backed by vendor testing and procurement review.

Key terms

• Cross-Tenant Account Takeover: A cross-tenant account takeover happens when an attacker uses identity confusion between organisations or directories to enter a target user’s account in another tenant. In federation scenarios, the weakness often sits in how the application correlates the external identity to a local account rather than in the login itself.
• Mutable Identity Attribute: A mutable identity attribute is a user value that can change over time, such as an email address, and therefore should not be treated as a stable proof of personhood. In federated applications, using it as the primary identifier creates identity drift and impersonation risk.
• Issuer and Subject Pair: The OIDC identity pair that uniquely identifies a user in a specific application relationship. Issuer identifies the token source, while subject identifies the user within that relationship. Together they provide the stable binding needed to avoid cross-tenant impersonation.
• Account linking: Account linking is the process of tying multiple login methods or sessions to one user profile so the same person does not become several separate records. In consumer IAM, it preserves identity continuity across email, social login, device handoff, and guest-to-registered transitions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.