Identity and Access Management (IAM) in Azure is the framework of policies and technologies that ensures the right people (and software) have the appropriate access to technology resources.
In 2026, Azure IAM is primarily managed through Microsoft Entra ID (formerly Azure AD). It is built on the philosophy of Zero Trust: “Never trust, always verify.”
ποΈ The Core Architecture
Azure IAM is governed by two separate but integrated systems:
- Entra ID Roles: Control access to “Identity” tasks (e.g., creating users, resetting passwords, managing domain names).
- Azure RBAC (Role-Based Access Control): Control access to “Resources” (e.g., starting a VM, reading a database, managing a virtual network).
π The Three Pillars of IAM
To understand any IAM request, Azure looks at three specific components:
1. Who? (The Security Principal)
This is the “Identity” requesting access. It can be:
- User: A human (Employee or Guest).
- Group: A collection of users (Best practice: always assign permissions to groups, not individuals).
- Service Principal: An identity for an application/tool (e.g., a backup script).
- Managed Identity: The “most secure” ID for Azure-to-Azure communication.
2. What can they do? (The Role Definition)
A “Role” is a collection of permissions.
- Owner: Can do everything, including granting access to others.
- Contributor: Can create/manage resources but cannot grant access.
- Reader: Can only view resources.
- Custom Roles: You can create your own if the “Built-in” ones are too broad.
3. Where? (The Scope)
Scope defines the boundary of the access. Azure uses a hierarchy:
- Management Group: Multiple subscriptions.
- Subscription: The billing and resource boundary.
- Resource Group: A logical container for related resources.
- Resource: The individual VM, SQL DB, or Storage Account.
Note: Permissions are inherited. If you are a “Reader” at the Subscription level, you are a “Reader” for every single resource inside that subscription.
π‘οΈ Advanced IAM Tools (The “Pro” Features)
Privileged Identity Management (PIM)
In a modern setup, no one should have “Permanent” admin access. PIM provides:
- Just-In-Time (JIT) Access: You are “Eligible” for a role, but you only activate it for 2 hours when you need to do work.
- Approval Workflows: A manager must approve your request to become an Admin.
Conditional Access (The “Smart” Gatekeeper)
Conditional Access is like a “Check-in Desk” that looks at signals before letting you in:
- Signal: Is the user in a weird location? Is their device unmanaged?
- Decision: Require MFA, Block access, or allow it.
ABAC (Attribute-Based Access Control)
As of 2025/2026, Azure has expanded into ABAC. This allows you to add “Conditions” to roles.
- Example: “User can only read storage blobs if the blob is tagged with
Project=Blue.”
β Best Practices
- Principle of Least Privilege: Give users only the bare minimum access they need.
- Use Groups: Never assign a role to a single user; assign it to a group so you can easily audit it later.
- Enable MFA: 99.9% of identity attacks are blocked by Multi-Factor Authentication.
- Use Managed Identities: Avoid using passwords or “Client Secrets” in your code.