In the world of Identity and Access Management (IAM), we often talk about "multi-tenancy" as a universal good—it's how the cloud scales. But as security researcher Visha Bernard demonstrated at Black Hat, not all multi-tenancy is created equal.
His presentation, "Microsoft on Microsoft," revealed a startling reality: if your identity provider is "flat," a single developer oversight can turn your internal tools into an open house for any attacker with a credit card and a personal tenant.
The Core Vulnerability
The Problem: The "Flat" Identity Pitfall
In the Microsoft Entra ID (Azure AD) model, multi-tenancy is essentially a flat, global pool. When a developer clicks "Multi-tenant" on an application registration, they are essentially telling that app: "I will trust any token signed by Microsoft."
The vulnerability Bernard exploited relied on the fact that an attacker could:
The "Microsoft on Microsoft" Attack Flow
Attacker Creates Tenant
Personal tenant with self-assigned 'Admin' role
Targets /common Endpoint
Redirects login request to flat global endpoint
Valid Token Issued
Microsoft signs token with 'Admin' claim
App Trusts Token
No Tenant ID check = unauthorized access
Result: 22 compromised high-value Microsoft internal applications discovered at Black Hat, all because developers forgot to validate the Tenant ID.
Because the architecture is flat and uses a global /common endpoint, the application receives a validly signed token, sees the "Admin" role, and lets the attacker in. The only thing preventing this is the developer manually writing code to check the Tenant ID.
As Bernard proved with 22 compromised high-value apps, developers often forget that step.
The SecureAuth Difference: Hierarchical Tenancy
SecureAuth approaches identity with a fundamentally different blueprint: Hierarchical Multi-Tenancy. Instead of a flat pool where everyone is a peer, SecureAuth organizes identity into a structured "tree" of Workspaces and Realms.
Flat Multi-Tenancy
Hierarchical Multi-Tenancy
Here is why this hierarchy is the ultimate defense against the "Microsoft on Microsoft" attack:
Isolation by Inheritance, Not Filtering
Flat model: open by default, write code to filter out the world
Hierarchical model: isolated by default, apps only trust IdPs within their lineage
Scope-Bound Administrative Roles
Flat model: 'Admin' role from any tenant is trusted
Hierarchical model: roles scoped to workspace branch—'Is this person admin within MY branch?'
No 'Common' Door to Intercept
Flat model: global /common endpoint enables issuer confusion
Hierarchical model: unique dedicated endpoints per organization, context baked into URL
How SecureAuth Prevents This Attack
Isolation by Inheritance, Not Filtering
In a flat model, you are open by default and must write code to filter out the rest of the world. In SecureAuth's hierarchical model, you are isolated by default.
An application lives within a specific "branch" of the hierarchy. It only recognizes and trusts identity providers (IdPs) within its own lineage. An attacker spinning up a separate SecureAuth instance is effectively on a completely different "tree." There is no "common" endpoint that allows their branch to talk to yours unless you explicitly build a bridge between them.
Scope-Bound Administrative Roles
The Black Hat attack worked because the application trusted "Admin" roles defined in the attacker's tenant.
In SecureAuth's hierarchical structure, roles are scoped to the workspace. Even if an attacker manages to intercept a request, they cannot "spoof" a role that your application recognizes because the application is bound to a specific hierarchy level. It doesn't just ask "Is this person an admin?"—it asks "Is this person an admin within my specific workspace branch?"
No 'Common' Door to Intercept
The "Microsoft on Microsoft" attack relied heavily on the ability to swap a legitimate Tenant ID for a "common" ID during the login handshake.
SecureAuth doesn't use a global, shared "common" door for all users. Each hierarchy or organization has its own unique, dedicated endpoints. Because the "door" itself is specific to your organization's hierarchy, there is no generic endpoint for an attacker to redirect to. The "identity context" is baked into the URL and the hierarchy, leaving no room for the "issuer confusion" that Bernard exploited.
The Verdict: Architecture > Oversight
Microsoft's response to this research was to issue "best practices" telling developers to be more careful. But as any security professional knows, "be more careful" is not a security strategy.
The real takeaway from Black Hat is that your IAM architecture should protect your developers from making mistakes. By using Hierarchical Multi-Tenancy, SecureAuth ensures that even if a developer forgets to "validate the issuer," the system's own logical boundaries prevent a random outsider from ever being considered a valid user.
In the battle between a flat world and a hierarchical one, the hierarchy provides the walls that keep the "common" riff-raff out.
Key Architectural Advantage
Flat vs. Hierarchical: At a Glance
| Aspect | Flat Model (Entra ID) | Hierarchical (SecureAuth) |
|---|---|---|
| Default Trust | Trust all Microsoft-signed tokens | Trust only within workspace lineage |
| Role Validation | Global role claims accepted | Roles scoped to workspace branch |
| Authentication Endpoint | Global /common endpoint | Unique per-organization endpoints |
| Developer Burden | Must manually validate Tenant ID | Isolation enforced by architecture |
| Attack Surface | Single oversight = full compromise | Architectural boundaries prevent access |
Explore Related SecureAuth Solutions
Ready to transform your identity security?
See how SecureAuth's Continuous Authority platform can protect your organization.
About SecureAuth
SecureAuth provides identity and access management solutions that enable enterprises to implement customized, resilient authentication infrastructure. Through Continuous Authority, flexible deployment options, and deep composable capabilities, SecureAuth helps organizations defend against modern identity threats while maintaining usability and operational efficiency.