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.
Editorial analysis by NHI Mgmt Group, based on content published by SecureAuth: “"Microsoft on Microsoft" Hack: Why Hierarchical Tenancy Wins Over Flat Multi-Tenancy”.
Key questions
Q: What breaks when an IAM application trusts issuer signatures without tenant validation?
A: The application loses the ability to prove that a valid token belongs to the correct organisational boundary.
Q: Why does tenant-scoped authorisation matter even when tokens are correctly signed?
A: Because a signed token only proves origin, not eligibility for a specific tenant or workspace.
Q: How do security teams detect risky flat multi-tenant trust patterns?
A: Look for applications that rely on shared login endpoints, broad issuer acceptance, or manual code comments reminding developers to 'validate Tenant ID.' Those are signs that tenancy boundaries are being reconstructed in application logic instead of enforced by the identity model.
Practitioner guidance
- Enforce Tenant ID validation at every federation entry point Make tenant context a required decision input before accepting any signed token, especially where a shared /common endpoint or equivalent global trust surface exists.
- Separate issuer trust from authorisation logic Treat signature validation as authentication only, then apply tenant-bound checks and role evaluation before authorising access to internal applications.
- Review multi-tenant application registrations for flat trust assumptions Inventory applications that accept broadly scoped identity provider tokens and identify where one oversight could expose multiple high-value internal tools.
Bottom line: A valid signed token is not enough if the application cannot prove the correct tenant context before authorising access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/09/2026 3:58 pm
Flat tenant trust is a governance defect, not a cloud convenience. When an IAM programme accepts any valid issuer token without binding it to tenant context, it has outsourced authorisation logic to the assumption that the signature is enough. That assumption fails in federated and multi-tenant environments because a valid token can still belong to the wrong organisational boundary. The practical implication is that tenant scoping must be part of the trust contract, not a developer afterthought.
A question worth separating out:
Q: Should organisations use hierarchical tenancy or patch flat multi-tenant trust with code checks?
A: Hierarchical tenancy is the stronger control because it makes isolation structural rather than procedural. Code checks can reduce risk, but they depend on every implementation being correct forever. A hierarchy bakes context into the system, which is far more reliable than asking each application to remember the right trust rules.
👉 Read our full editorial: Flat tenant trust breaks enterprise IAM: lessons from Microsoft on Microsoft
This post was modified 2 days ago by NHI Mgmt Group