Microsoft's identity service was named Azure Active Directory until 2023, when it became Microsoft Entra ID. Same product, same APIs, mostly the same documentation paths — just a new name. If you administer Microsoft 365, you administer Entra ID, whether or not you ever touch the Azure portal.
This page covers four ideas: the tenant as the root identity boundary, conditional access as the policy enforcement point, PIM for time-bound elevation, and managed identities for workloads that need to call Azure APIs.
The tenant is everything
An Entra ID tenant is a dedicated, isolated instance of the Microsoft identity service for one organization. It contains all your users, groups, applications, and policy. It is the security boundary: everything in your Microsoft 365, every Azure subscription you own, every SaaS app you've federated — all hang off the tenant.
Tenant — identity boundary
One per organization (usually). Holds users, groups, devices, applications, and policy. Has a default domain (contoso.onmicrosoft.com) plus any custom domains you verify (contoso.com).
If an attacker controls a tenant, they control everything inside it. Storm-0558 (2023) was severe because the breach happened at the tenant identity layer, not at any single application.
Users — members and guests
Member users are full employees: directly created or synced from on-prem AD. Guest users are external identities invited via B2B collaboration — they sign in with their home tenant's credentials and appear in your tenant as a guest.
Guests are the most-forgotten attack surface. Audit them: vendors who shipped projects three years ago still have access if no one cleaned up.
Groups — security and Microsoft 365
Security groups grant access to resources. Microsoft 365 groups additionally provide collaboration (mailbox, SharePoint, Teams). Dynamic groups change membership based on user attributes (e.g., everyone whose Department == Engineering).
Applications — app registrations
Every app that authenticates against your tenant is registered. Each registration has a client ID, optional client secret, redirect URIs, and a set of API permissions. Treat app registrations like users — they're identities too.
Service principal sprawl is the Entra version of IAM sprawl: thousands of app registrations from SaaS integrations, most with permissions nobody remembers granting.
Conditional Access — the policy engine
Conditional Access (CA) is Entra's policy engine. Every sign-in is evaluated against your CA policies, and the result is one of: allow, allow with conditions (require MFA, require compliant device, require app protection), or block.
A Conditional Access policy is a structured rule:
Who (Users)
All users, specific users, members of a group, guests, specific roles, or "anyone except this list." Almost always scoped to a group.
What (Cloud apps)
All apps, specific apps (Exchange, Teams, custom registrations), or user actions (registering security info, joining a device).
Where (Conditions)
Sign-in risk level (from Entra ID Protection), device platform, location (named locations, country, IP range), client app (browser vs. desktop client), device state.
How (Grant controls)
Block access, require MFA, require compliant device, require approved client app, require terms of use acceptance. Multiple controls AND together by default.
How (Session controls)
Sign-in frequency, persistent browser session, app-enforced restrictions (e.g., SharePoint download blocked from unmanaged devices), Conditional Access App Control via Defender for Cloud Apps.
Exclusions
Every policy should have a break-glass account excluded so a misconfigured CA policy doesn't lock you out. Store break-glass credentials in a vault; alert on their use.
A common baseline policy set: require MFA for everyone, block legacy authentication protocols (POP/IMAP/SMTP-AUTH), require compliant devices for admins, block sign-ins from countries you don't operate in. Microsoft's "Security Defaults" enables a starter version of this for free tenants.
Privileged Identity Management — just-in-time admin
Standing administrative access is the single biggest blast-radius problem in identity. If a user has Global Administrator 24/7, then a single phished session is a full tenant compromise. Privileged Identity Management (PIM) fixes this by making admin roles eligible rather than active:
- Eligibility > assignment. Users are assigned roles they can activate, not roles they hold permanently. The role does nothing until activated.
- Activation requires action. User logs in, opens PIM, requests activation. May be required to provide justification, complete MFA, or wait for approval from another admin.
- Time-limited. Activation is for a window (default 1–8 hours). When the timer expires, the role goes back to eligible-but-inactive.
- Auditable. Every activation is logged. Periodic access reviews surface unused eligibility.
- Approval workflows. Sensitive roles (Global Admin, Privileged Role Admin) can require approval from a second admin before activation.
Managed Identities — no secrets for workloads
When an Azure workload (a VM, an App Service, a Function, a Container App) needs to call Azure APIs (read a Key Vault, write to a Storage Account, query SQL Database), the question is: how does it authenticate? The wrong answer is "store an API key in a config file." The right answer is a managed identity.
A managed identity is an automatically-managed service principal that Azure attaches to a resource. The workload calls a local metadata endpoint (similar to AWS IMDS, but with header-based protection by default), gets a token, and uses it to call other Azure APIs. No secrets ever live in your code or configuration.
System-assigned managed identity
Tied to the lifecycle of one specific resource (the VM, the App Service). Created when the resource enables it; deleted when the resource is deleted. The simplest model.
User-assigned managed identity
A standalone identity you create once and attach to many resources. Useful when several workloads should share the same identity (e.g., a scaled-out app fleet). Survives deletion of any single resource.
Combine managed identities with Azure RBAC and Key Vault: the managed identity has read access to a specific Key Vault, the Key Vault holds the connection strings the app actually needs, and the access is scoped to one identity that exists only as long as the resource exists. Lost laptops, expired access keys, accidentally-committed secrets — all become non-issues.
Azure's security model is identity-first. The tenant is the boundary, Conditional Access is the policy engine, PIM removes standing privilege, and managed identities take secrets out of the workload's hands entirely. Configure these four well and the majority of common Azure breach patterns are closed before they start.
Storm-0558 (2023) is the cautionary tale of what happens when the identity layer itself is compromised: every defense above the identity layer is bypassed at once. There is no fix at the application layer for a compromised tenant identity provider — only detection, response, and the discipline of monitoring sign-in patterns for anomalies.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Microsoft. (n.d.-a). Conditional access overview. Microsoft Entra ID documentation. https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
- Microsoft. (n.d.-b). Managed identities for Azure resources. Microsoft Entra ID documentation. https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview
- Microsoft. (n.d.-c). What is Microsoft Entra Privileged Identity Management? Microsoft Entra ID documentation. https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
- Microsoft Security Response Center. (2023, September 6). Results of major technical investigations for Storm-0558 key acquisition. https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/