Topic starter
25/06/2026 1:16 am
TL;DR: Nine of 104 tested applications were found vulnerable to nOAuth abuse, a low-complexity cross-tenant attack that can enable account takeover, data exfiltration, persistence, and lateral movement in Entra-connected SaaS, according to Semperis. The governance failure is deeper than a misconfigured claim: applications that trust mutable email attributes as identity have already lost the stability assumption IAM depends on.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: nOAuth abuse turns a familiar federation feature into a cross-tenant takeover path when applications trust mutable email claims as identity.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 23 hours ago by NHI Mgmt Group
25/06/2026 10:35 am
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.
A few things that frame the scale:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
A question worth separating out:
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.
👉 Read our full editorial: nOAuth abuse exposes a cross-tenant account takeover gap
This post was modified 23 hours ago by NHI Mgmt Group