Notifications
Clear all
Topic starter
02/09/2026 3:57 pm
TL;DR: A flat multi-tenant trust model can let an attacker with a personal tenant and a valid Microsoft-signed token reach internal apps, according to SecureAuth research, because tenant ID validation was missing and 22 high-value applications were found compromised. The issue is not token signing, but the assumption that issuer trust alone is enough for multi-tenant IAM.
NHIMG editorial — based on content published by SecureAuth: Microsoft on Microsoft and the flat multi-tenancy identity pitfall
Questions worth separating out
Q: What breaks when a multi-tenant app trusts signed tokens without checking the Tenant ID?
A: The application loses tenant isolation.
Q: Why does flat multi-tenancy create risk in federated IAM architectures?
A: Flat multi-tenancy makes trust too broad.
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.
Practitioner guidance
- 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.
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
👉 Read SecureAuth's analysis of flat multi-tenancy and tenant validation risk →
Flat tenant trust and issuer confusion: what IAM teams should fix?
Explore further
02/09/2026 3:58 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Flat tenant trust breaks enterprise IAM: lessons from Microsoft on Microsoft
