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.

CategoryWhat it coversKey resources in 2026
WorkforceEmployees and contractors signing into corporate resources/users, /groups, ID Protection, ID Governance, Verified ID
ExternalPartners, business guests, and consumer customersExternal ID (B2B in workforce tenant; CIAM in external tenant)
WorkloadsApplications, services, scripts, and containers/applications, /servicePrincipals, managed identities, federated credentials
AgentsAutonomous AI systems acting on behalf of users or organizationsAgent 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 elementExamples
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 controlsBlock; require MFA; require authentication strength (phishing-resistant, passkey, certificate-based); require compliant device; require Terms of Use; require approved client app
Session controlsSign-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 pathWhat it manages
/users, /groupsWorkforce and external user identity; group membership and dynamic group rules
/applications, /servicePrincipalsWorkload identity: app registrations, service principals, federated identity credentials
/identity/conditionalAccess/policiesConditional Access policies, named locations, authentication strength policies
/identityProtection/riskyUsers, /riskDetectionsRisk 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/authenticationMethodsPolicyPer-method enablement: passkey, FIDO2, certificate-based, Windows Hello, OATH, SMS
/auditLogs, /signInsAudit 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.

AspectEntra Connect Sync (legacy)Entra Cloud Sync (modern)
HostingOn-premises Windows Server with sync engine and SQLLightweight agent on a Windows server; orchestration in Azure
ConfigurationOn-prem installer and sync-rules editorMicrosoft Entra portal; configuration travels with the tenant
High availabilityActive server + staging-mode standbyMultiple agents native; no staging-mode complexity
Auth patternsPHS, PTA, federation with AD FSPHS, PTA (federation phasing out)
Strategic directionCoexists; phased retirement begins April 2026Microsoft'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 onlyAdd P1 for Conditional Access
Entra ID P2 deployed but limited use of capabilitiesEnable risk-based Conditional Access policies
P2 with mature operational disciplineAdd Entra Suite for Governance, GSA, Verified ID
Running Entra Connect on-premises todayPlan Cloud Sync migration before April 2026
Hundreds of unmanaged service principalsAdd Workload ID Premium for the privileged subset first
Planning to deploy AI agents in 2026Pilot 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.