Flat tenant trust breaks enterprise IAM: lessons from Microsoft on Microsoft

At a glance

What this is: This is an IAM analysis of how flat multi-tenancy and weak tenant validation can turn valid tokens into unauthorised access.

Why it matters: It matters because identity teams need architecture and policy boundaries that prevent issuer confusion, tenant spoofing, and overbroad trust from breaking application isolation.

👉 Read SecureAuth's analysis of flat multi-tenancy and tenant validation risk

Context

Flat multi-tenancy in IAM becomes risky when applications trust a signed token without validating the tenant context that issued it. In that model, authentication succeeds, but authorisation boundaries collapse because the app cannot distinguish an intended tenant from an attacker-controlled one. This is a human IAM and federation problem first, not just an application bug.

The article's core finding is that identity architecture can either absorb developer mistakes or amplify them. When trust is global and validation is manual, one missed control can expose internal applications to any external tenant that can produce a valid token. That is a classic governance failure: the access model assumes code will enforce what the platform should have enforced by design.

Key questions

Q: What breaks when a multi-tenant app trusts signed tokens without checking the Tenant ID?

A: The application loses tenant isolation. A valid token can still represent the wrong identity boundary, so an attacker-controlled tenant may be treated as trusted if issuer and tenant context are not both verified. That turns authentication into a false signal and gives external users a path into internal applications that should have remained inaccessible.

Q: Why does flat multi-tenancy create risk in federated IAM architectures?

A: Flat multi-tenancy makes trust too broad. If the same endpoint and token validation logic apply across tenants, the application can no longer distinguish a legitimate internal user from an external tenant presenting a valid token. The result is issuer confusion, overbroad trust, and a much larger blast radius when one validation step is missed.

Q: How can security teams reduce the chance of tenant spoofing in SSO flows?

A: They should enforce tenant-bound validation at the application layer and not rely on the identity provider alone. That means checking the token issuer, Tenant ID, and application scope together, then rejecting any login attempt that does not match the expected trust boundary for that app or workspace.

Q: When should organisations reconsider a flat multi-tenant identity model?

A: They should reconsider it when internal applications need strong tenant isolation, delegated administration, or high-value access control. If the architecture depends on developers remembering to add manual checks for every login path, the model is already too brittle for sensitive environments.

Technical breakdown

Why flat tenant trust breaks issuer validation

In a flat multi-tenant model, a token signed by the identity provider can still be unsafe if the application does not verify which tenant issued it. The issuer signature confirms authenticity, not business context. The Tenant ID binds a token to a specific identity boundary, and when that check is omitted, an external tenant can present a legitimate-looking identity assertion that the application treats as internal access. This is not cryptographic failure. It is trust-context failure, where the application confuses validly signed with legitimately authorised.

Practical implication: Require tenant-bound authorisation checks wherever a multi-tenant application accepts federated tokens.

How the /common endpoint creates issuer confusion

A shared login endpoint simplifies federation, but it also creates a broad trust surface if the application assumes the endpoint itself enforces tenant separation. In the attack described, the /common path allowed a request to be redirected into a global trust flow, after which the application accepted a token without confirming the tenant lineage. The problem is architectural: the endpoint acts as a universal door unless the app imposes context checks after authentication. That makes isolation dependent on developer discipline instead of platform design.

Practical implication: Eliminate generic trust flows where tenant lineage cannot be enforced inside the authentication path.

Why role claims are not enough for access decisions

Role-based access control only works when the role is evaluated inside the correct authority boundary. An 'Admin' claim from an attacker-controlled tenant is meaningless unless the application validates that the tenant, issuer, and workspace context all match the intended trust domain. This is where flat identity models fail most visibly: they treat claims as portable across tenants when they are not. The resulting mistake is a policy decision based on identity shape rather than identity scope.

Practical implication: Bind administrative claims to the correct tenant scope before any privilege is granted.

Threat narrative

Attacker objective: The objective is to convert a valid external identity token into internal application access by exploiting missing tenant validation.

1. Entry occurs when an attacker creates a personal tenant and uses the /common endpoint to initiate a login flow against a multi-tenant application.
2. Escalation occurs when the application accepts a valid Microsoft-signed token and fails to validate the Tenant ID, allowing attacker-controlled 'Admin' claims to pass.
3. Impact occurs when the attacker reaches internal applications that were intended to be isolated, resulting in unauthorised access to high-value Microsoft environments.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Flat multi-tenancy is an identity governance assumption, not just an application pattern. It assumes that a signed token is sufficiently specific to a tenant boundary when the real trust question is who issued it, under what context, and for which application branch. That assumption breaks when applications accept federated identities without binding authorisation to tenant lineage. The implication is that IAM teams must treat tenant context as part of the identity decision, not as optional metadata.

Tenant ID validation is the missing control that turns federation into segmentation. The Black Hat finding shows that the threat is not Microsoft's signing model itself, but the gap between authentication success and tenant-scoped authorisation. If the application can accept a valid token from any tenant, then the control boundary exists only in developer intent. Practitioners should view this as a design failure in federation governance, not a one-off coding mistake.

Identity context must be inherited, not inferred: flat trust models force applications to infer legitimacy from a token alone, while hierarchical models make context part of the access path. This is the precise governance advantage of structured tenant boundaries. It reduces the chance that claims, roles, or endpoints are reused outside their intended branch. The practical lesson is that multi-tenancy should be designed so that the safe path is the default path.

Issuer confusion is a recurring pattern wherever the platform and application disagree on the trust boundary. The same failure mode appears in any federated environment where the login surface is broader than the authorisation model beneath it. That means IAM, IGA, and application security teams need a shared boundary model for tenant, issuer, and role scope. Without that shared model, access reviews and policy enforcement will keep missing the real control gap.

What this signals

Flat trust models push too much responsibility into application code, and that is where identity failures become inconsistent. A better operating model is to treat tenant lineage, issuer scope, and role scope as first-class governance objects, then align them with application registration policy and federation review.

Issuer-confusion risk: when a shared authentication surface accepts any tenant-signed identity, the security boundary exists only if downstream enforcement is precise. IAM programmes should map every multi-tenant app to the exact trust assumptions it makes and remove any dependency on manual developer memory.

For practitioners

• Bind token acceptance to tenant lineage Validate Tenant ID, issuer, and workspace context on every federated login flow before the application evaluates any role claim.
• Remove dependence on generic trust endpoints Where possible, replace shared /common-style login paths with organisation-specific endpoints that preserve identity context through the full auth sequence.
• Scope administrative claims to the correct trust boundary Treat any Admin-like role as valid only inside the tenant or workspace that issued it, and reject cross-tenant role reuse by policy.
• Review application registrations for flat multi-tenant defaults Inventory apps that were set to multi-tenant for convenience and verify whether the business case really requires open federation across tenants.

Key takeaways

• Flat multi-tenancy can collapse identity boundaries when applications trust signed tokens without checking tenant context.
• The failure mode is issuer confusion, where valid authentication is mistaken for valid authorisation across tenants.
• Tenant-scoped validation, scoped roles, and organisation-specific endpoints are the controls that prevent this pattern from becoming an access breach.

Key terms

• Tenant ID: A unique identifier that tells the system which customer a request, session, or data object belongs to. In secure SaaS design, every access decision depends on this value being present, correct, and consistently enforced across application and database layers.
• Issuer Confusion: Issuer confusion happens when an application accepts a token from a legitimate identity provider but misapplies it to the wrong trust boundary. The token is authentic, yet the access decision is incorrect because the application cannot distinguish who issued the assertion for which tenant or workspace.
• Multi-tenancy: Multi-tenancy is the design pattern that keeps multiple customer organisations isolated inside one application. For identity teams, the key issue is whether access, policy, and administration remain separable at the tenant level, or whether customer boundaries leak into support, logging, and provisioning workflows.
• Tenant-Scoped Authorization: Tenant-scoped authorisation means access decisions are evaluated within one customer boundary rather than globally. The same identity can have different roles or permissions in different tenants, so the session must carry the active organisation and every control must check it before allowing reads, writes, or administrative actions.

What's in the full article

SecureAuth's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact Microsoft on Microsoft attack flow, including the tenant spoofing sequence and token acceptance path
• The hierarchical multi-tenancy design choices behind SecureAuth's workspace and realm boundaries
• The platform-level differences between a shared /common login door and organisation-specific endpoints
• The practical implications of scoped administrative roles for federated application design

👉 SecureAuth's full post covers the Microsoft on Microsoft attack flow, hierarchy model, and access boundary design

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.