Microsoft Entra ID - The Evolution of AD
In this article
Summary
In July 2023, Microsoft renamed Azure Active Directory to Microsoft Entra ID. The change landed as a cosmetic exercise, a marketing decision wrapped around what looked like the same product. It was neither.
Three years on, the Entra family has nine services covering human, partner, workload, and agent identities. The same authentication surface that handles 1.2 billion daily sign-ins now also issues credentials to autonomous AI agents, brokers connections to private corporate apps, scores risk against 78 trillion daily signals, and verifies cryptographic credentials presented at a helpdesk. The word "directory" no longer covers any of that.
The rename was Microsoft's way of telling the market that the product had outgrown its category. Most CISO architecture diagrams have not yet caught up. Entra ID is still drawn as the box on the left labeled "users and groups." That mental model is two architectural generations out of date.
The Journey From Directory to Control Plane
A directory stores users, groups, and the relationships between them. A control plane is something else: the engine that decides who or what can do what, where, when, and with what evidence, and then applies that decision in real time across every resource the organization owns.
Microsoft Entra ID is now the second. Every identity-adjacent capability, risk scoring, governance, network access, credential verification, agent permissions, reads from and writes to the same control plane. Conditional Access is the policy engine that all of them obey. Microsoft Graph is the API surface that all of them automate against. Below we explore each of the four identity categories it spans, the universal policy engine that ties them together, the unified API surface that automates them, and the hybrid bridge that connects on-prem AD to the cloud.
Four Identity Categories, One Control Plane
Microsoft now organizes the Entra family around four identity categories. The lines between them used to require separate products from separate vendors. Today they share one policy engine, one admin surface, one audit trail, and one Graph API.
| Category | What it covers | Key resources in 2026 |
|---|---|---|
| Workforce | Employees and contractors signing into corporate resources | /users, /groups, ID Protection, ID Governance, Verified ID |
| External | Partners, business guests, and consumer customers | External ID (B2B in workforce tenant; CIAM in external tenant) |
| Workloads | Applications, services, scripts, and containers | /applications, /servicePrincipals, managed identities, federated credentials |
| Agents | Autonomous AI systems acting on behalf of users or organizations | Agent ID under Microsoft Agent 365 (new for 2026) |
Network enforcement across all categories: Global Secure Access (Internet Access + Private Access) | ||
Table 1 - Describes the four identity categories of of Microsoft Entra.
The Agent ID category is the consequential addition. As autonomous agents proliferate, Microsoft's own Copilot, AWS Bedrock workloads, third-party agent frameworks, every one of them needs a governed identity. Agent ID gives each agent a credential, an enforced human sponsor, and a lifecycle. Conditional Access for agents enforces the same kind of risk-based decisions Microsoft has been making for human sign-ins since 2018.
Conditional Access - The Universal Policy Engine
Conditional Access is what turns Entra from a directory into a control plane. Every authentication request flowing through the platform, workforce or external, human or workload or agent, is evaluated against the tenant's Conditional Access policies before any token is issued. The policy model has four parts.
| Policy element | Examples |
|---|---|
| Assignments (who/what) | User or group, directory role, workload identity, agent identity, target app, action type |
| Conditions (context) | Sign-in risk, user risk, network location, device platform, device state (compliant, hybrid-joined), client app, authentication flow |
| Grant controls | Block; require MFA; require authentication strength (phishing-resistant, passkey, certificate-based); require compliant device; require Terms of Use; require approved client app |
| Session controls | Sign-in frequency, persistent browser, app-enforced restrictions, Conditional Access App Control, customize Continuous Access Evaluation |
Table 2 - Describes the four policy models for Conditional Access.
Policies are evaluated in aggregate, every applicable policy must grant access; any one that blocks wins. Authentication strength is a separate primitive that plugs into the grant control: "Require FIDO2 keys only" and "Require passkey or certificate-based auth" are pre-built strengths, with custom strengths available. Continuous Access Evaluation provides protocol-level token revocation when policy conditions change mid-session. The entire policy model is exposed via Microsoft Graph at /identity/conditionalAccess/policies, making policy-as-code workflows possible at tenant scale.
Microsoft Graph - The Unified API Surface
Every signal, policy, role assignment, lifecycle event, and audit record across all four identity categories is queryable and automatable through one HTTPS endpoint: graph.microsoft.com. The same OAuth 2.0 token model that handles user authentication handles API authorization, and every resource speaks the same OData-derived REST conventions.
| Resource path | What it manages |
|---|---|
| /users, /groups | Workforce and external user identity; group membership and dynamic group rules |
| /applications, /servicePrincipals | Workload identity: app registrations, service principals, federated identity credentials |
| /identity/conditionalAccess/policies | Conditional Access policies, named locations, authentication strength policies |
| /identityProtection/riskyUsers, /riskDetections | Risk state model (per user and per event), used by Conditional Access and the SOC |
| /identityGovernance/* | Lifecycle workflows, entitlement management, access reviews, privileged identity management |
| /policies/authenticationMethodsPolicy | Per-method enablement: passkey, FIDO2, certificate-based, Windows Hello, OATH, SMS |
| /auditLogs, /signIns | Audit and sign-in logs with $count, $filter, $select for high-cardinality querying |
Table 3 - Describes the resource paths and what it manages.
Permissions are delegated (acting on behalf of a user) or application (acting as itself with a workload identity). Change notifications via webhooks allow event-driven automation, a riskyUser state change can trigger an external workflow without polling. $count, $filter, and $select on high-cardinality endpoints (notably /signIns) make Graph practical at tenant scale; these query parameters reached general availability in mid-2026 for identity-protection automation.
Hybrid Identity Architecture
For most enterprises, identity is still hybrid, Active Directory on-premises feeding Entra ID. The bridge has two implementations, and the strategic direction is shifting in 2026.
| Aspect | Entra Connect Sync (legacy) | Entra Cloud Sync (modern) |
|---|---|---|
| Hosting | On-premises Windows Server with sync engine and SQL | Lightweight agent on a Windows server; orchestration in Azure |
| Configuration | On-prem installer and sync-rules editor | Microsoft Entra portal; configuration travels with the tenant |
| High availability | Active server + staging-mode standby | Multiple agents native; no staging-mode complexity |
| Auth patterns | PHS, PTA, federation with AD FS | PHS, PTA (federation phasing out) |
| Strategic direction | Coexists; phased retirement begins April 2026 | Microsoft's recommended path forward |
Table 4 - Describes the difference between the different sync models.
Under either sync model, three authentication topologies are possible. Password Hash Sync (PHS), the default, replicates password hashes to Entra, so sign-in works even if on-prem AD is unavailable. Pass-Through Authentication (PTA) validates passwords against AD via a connector. Federation with AD FS remains supported but is being de-emphasized in favor of PHS or PTA. Microsoft's recommendation for most enterprises is PHS, which provides the broadest resilience and the simplest operational model.
Upcoming Shifts
Passkeys auto-enable in March 2026
Microsoft is auto-provisioning device-bound passkey profiles across every eligible Entra tenant starting March 2026, controlled by the Authentication Methods Policy at /policies/authenticationMethodsPolicy. The policy targets methods (FIDO2, passkey, Windows Hello, certificate-based, OATH, SMS) at specific user groups; auto-enable changes the default state for passkeys to enabled-for-all unless explicitly excluded. The default authentication posture for hundreds of millions of accounts shifts from password-plus-MFA to phishing-resistant by default , with the residual gap moving to AiTM token theft, which ID Protection is built to score.
Entra Cloud Sync replaces Entra Connect in April 2026
Microsoft begins phased migration from the on-premises Entra Connect Sync to cloud-native Entra Cloud Sync in April 2026. Phased transitions and assessment tooling roll out through 2026; hybrid authentication continues unchanged. The operational consequence is significant: a substantial piece of on-premises identity infrastructure begins to retire, and configuration moves from the on-prem installer to the Entra portal.
Agent 365 reaches general availability May 1, 2026
Agent ID is part of Microsoft Agent 365, which goes GA May 1, 2026 alongside Microsoft 365 E7. This is the first commercial release in which AI agents are a first-class identity category in the platform , not a workload, not a service principal, but their own SKU with their own lifecycle, sponsorship, and governance model.
Moving Forward
Most enterprises already pay for more of the Entra platform than they use. The fastest 2026 wins are usually a license tier or a Conditional Access policy away, not a procurement cycle.
| If your starting point is… | The first move is |
|---|---|
| Entra ID Free with M365 only | Add P1 for Conditional Access |
| Entra ID P2 deployed but limited use of capabilities | Enable risk-based Conditional Access policies |
| P2 with mature operational discipline | Add Entra Suite for Governance, GSA, Verified ID |
| Running Entra Connect on-premises today | Plan Cloud Sync migration before April 2026 |
| Hundreds of unmanaged service principals | Add Workload ID Premium for the privileged subset first |
| Planning to deploy AI agents in 2026 | Pilot Agent 365 ahead of GA; design agent sponsorship now |
Table 5 - Describes the decision framework for a business.
What Good Looks Like
The technical capabilities of Entra ID are the visible half. The operational shift is the half that determines whether the platform delivers what it can.
For two decades, identity in most enterprises has been run by an Active Directory team, a small group that handles user provisioning, group membership, and the occasional Conditional Access policy. Entra ID at scale is a different role. It requires platform thinking, policy-as-code through Graph, lifecycle workflows, automation against the risk and audit endpoints, governance over machine identities, and a posture toward AI agents that did not exist eighteen months ago. The deployments that succeed treat Entra as infrastructure to operate, not a service to provision, with an identity platform owner, a roadmap, and a budget that grows alongside the four identity categories, not just the human one.
Conclusion
Microsoft Entra ID stopped being a directory in July 2023. The market has been catching up ever since. The product family is now nine services, four identity categories, and one policy engine. Okta, Ping, and ForgeRock field comparable platforms; the right choice depends on existing platform commitments. What is not in dispute is what Entra has become. The 2026 question is not whether your organization uses it. It is whether you are operating it as a directory, or as the platform every other identity layer in your stack now plugs into.