Azure
Azure IAM Jargon: Tenants, Entra ID, Subscriptions and Core IAM Principles
June 17, 2026 · 5 min read
I spent far too long confused with Azure's IAM system trying to make sense of everything. Azure’s identity ecosystem has its own highly specific architectural quirks and the documentation feels like an actual mess, at least to me, but I'm figuring a lot out at the moment myself.
Things like why I can be the owner of a subscription but still can't create a simple user account, or why moving a subscription completely broke your databases, but all of it is just my own explanation of everything Azure IAM.
Microsoft Entra ID Roles vs Azure RBAC Roles
Azure has two completely separate role-assignment planes that do not overlap by default.
• Microsoft Entra ID Roles (Directory Level): These control the identity brain itself. Roles like Global Administrator or User Administrator live here. They let you create users, delete groups, and manage app registrations.
• Azure RBAC Roles (Resource Level): These control the infrastructure. Roles like Owner, Contributor, and Reader live here. They let you spin up VMs, create SQL databases, or delete storage accounts.
It's worth noting that with this in mind, you can be a subscription Owner (Resource plane) and have absolutely zero power to create a user in Entra ID (Directory plane). Conversely, you can be a Global Administrator of the tenant and literally not even see the virtual machines running inside a subscription until someone grants you explicit RBAC access or you toggle the "Access management for Azure resources" switch in your Entra settings.
The Tenant-to-Subscription Trust Relationship
Another thing that kept me confused was the literal dependency between an Entra ID Tenant and an Azure Subscription. Subscriptions are not standalone accounts and its quite important to think of it as a downstream dependent.
A subscription has a strict 1:1 trust relationship with exactly one Entra ID Tenant.
[ Entra ID Tenant ] <-- The Authentication Anchor ▲ ▲ │ └────────────────────────┐ (Trusts) │ (Trusts) │ [ Dev Subscription ] [ Prod Subscription ]
Implications
If a company restructures and you have to change the directory/tenant that your Azure subscription trusts, it tears down the entire authorization house of cards.
• Every single custom Azure RBAC role assignment you meticulously mapped out is instantly deleted.
• Your User-Assigned Managed Identities are completely severed.
• Your Azure Key Vaults will lock you out entirely until you manually update their tenant IDs.
When you move a subscription, you aren't just changing a setting; you are shifting the entire planetary gravity of your infrastructure's identity system.
System-Assigned vs. User-Assigned Managed Identities
Before Azure, I was used to the old, dangerous way of doing things: creating a service account, generating a massive API key or client secret, and shoving it into an .env file or GitHub secret. It always felt risky.
Azure's specific antidote to this is Managed Identities. They are essentially Azure-managed service principals that completely eliminate the need for credentials.
System-Assigned
Tied directly to a single Azure resource. Perfect for isolated workloads like a web app reading from a Key Vault.
User-Assigned
Independent resource. Perfect for scaling across clusters that need identical permissions.
Conditional Access
If you're coming from a background with some other cloud provider like AWS its easy to focus on network isolation, Network Security Groups (NSGs), private endpoints, and hub-spoke VNet architectures.
In Azure, the network firewall is not meant to be a primary line of defense; Entra ID Conditional Access is.
Conditional Access is an "If/Then" policy engine specific to Microsoft's cloud. It stops bad actors before they can even try to look at your resource control plane.
It turns identity into a dynamic, programmable perimeter that moves with your users, rather than a static IP fence around a virtual network.
My own distillation of these concepts
1. Entra ID checks who you are (Authentication).
2. Azure RBAC checks where you are allowed to look (Authorization via Scopes).
3. Subscriptions dictate who gets the bill for the resources you build.
4. Managed Identities let your code talk to your databases without a single hardcoded password.
I'm still learning myself, but I do hope this is a helpful explanation of the core concepts for anyone else trying to wrap their head around Azure IAM. I also wrote this half so that I can see what I do and don't understand myself so take all of this with a grain of salt. Please do reach out to me for any suggestions or corrections.