Entra ID makes sense only when a few simple ideas are clear.

Identity

An identity is a digital record that represents something that needs access: a person, an application, a server, a phone, or a piece of automation. The identity has a name and attributes, and it can hold credentials, which are proofs such as passwords, security keys, or certificates. Everything in cloud security starts with knowing which identity is asking.

Authentication and authorization

Authentication answers the question “who are you?” It is the act of proving identity. Authorization answers “what are you allowed to do?” It is the act of checking permissions after identity is known. The two are separate steps, and confusing them is the root of many design mistakes.

Directory

A directory is a database that stores identities and their relationships: which users belong to which groups, which devices belong to whom, which applications exist. Older companies ran Active Directory on their own servers inside the office network. Entra ID is a directory built for the internet and the cloud, where users, applications, and devices may be anywhere.

Single sign-on

Single sign-on, abbreviated SSO, lets a person sign in once and then open many applications without typing credentials again. The applications trust the identity service, which vouches for the user. SSO improves security as well as comfort, because fewer passwords exist to be forgotten, reused, or stolen.

Entra ID is Microsoft’s cloud identity and access management service.

Definition and history

Microsoft Entra ID is the cloud-based directory and identity platform that signs in users and applications and controls access to resources. It was previously named Azure Active Directory, often shortened to Azure AD. Microsoft renamed it in 2023 as part of the Entra product family. The functions are the same service under a new name, and you will still see the old name in older articles, tools, and some settings.

Not the same as classic Active Directory

Beginners often assume Entra ID is Active Directory running in Azure. It is not. Classic Active Directory Domain Services uses protocols such as Kerberos and LDAP and organizes computers in domains and organizational units. Entra ID uses web protocols such as OAuth 2.0, OpenID Connect, and SAML, and it is flat, with no organizational units and no group policy. The two can be connected, which is the subject of the hybrid identity chapter, but they are different technologies.

What it provides

Scale and availability

Entra ID runs as a globally distributed service with data centers across many regions, designed so that the failure of one location does not stop sign-ins. Customers do not size servers, apply patches, or schedule upgrades. The service handles very large volumes of authentications every day. This shared responsibility matters in planning: Microsoft operates the platform, while you remain responsible for configuration, policy, and the accounts and applications inside your tenant. Most real incidents come from the second part, not from failure of the platform itself.

A trustworthy guide must describe the service as it is now, including the dated changes that affect real tenants. Verify every date on Microsoft’s current pages before acting, because schedules shift.

Mandatory multifactor authentication

Microsoft is requiring multifactor authentication for Azure management. Phase 1 covers sign-ins to the Azure portal, the Entra admin center, and the Intune admin center, and began rolling out in the second half of 2024, with the Microsoft 365 admin center following in February 2025. Phase 2 began on 1 October 2025 and rolls out gradually. It covers create, update, and delete operations through the Azure command-line tools, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools that use those clients, the control-plane REST interface, and the Azure SDK. Read operations do not require it. According to Microsoft’s documentation, workload identities such as managed identities and service principals are not affected, but user accounts used as service accounts are, and the page lists no exemptions for user accounts.

Other dated changes from Microsoft’s what’s-new page

Agents become identities

Microsoft introduced Entra Agent ID, which treats autonomous AI agents as first-class identities with owners called sponsors, lifecycle controls, and Conditional Access. The platform reached general availability in April 2026 according to Microsoft’s page, while the earlier agent registry in the Entra admin center was retired on 1 May 2026 in favor of Agent 365. Organizations building agents should treat them as identities that need governance, not as scripts.

Older programming interfaces retire

Microsoft has been retiring Azure AD Graph and the older PowerShell modules built on it, in favor of Microsoft Graph and the Microsoft Graph PowerShell tools. Older versions of the Azure command-line tools and Azure PowerShell needed updates because of the Azure AD Graph retirement. Treat any script that mentions the old module names as technical debt with a deadline, and check Microsoft’s announcements for the current status.

The relationship between a tenant and Azure subscriptions confuses nearly every beginner.

The tenant

A tenant is a dedicated, isolated instance of Entra ID that an organization receives when it signs up for a Microsoft cloud service. It holds that organization’s users, groups, applications, and policies. Each tenant has a unique identifier and at least one domain name, such as the company’s own domain. People often use the words tenant and directory interchangeably, and they refer to the same thing.

Subscriptions trust one tenant

An Azure subscription is a billing and resource container. Every subscription trusts exactly one tenant to provide identities and to hold the role assignments for its resources. A tenant can be trusted by many subscriptions. You can move a subscription to a different tenant, but the role assignments and managed identities do not carry over cleanly, so plan carefully.

flowchart TD
  T["Entra ID tenant: users, groups, apps, policies"] --> MG["Management group hierarchy"]
  MG --> S1["Subscription: production"]
  MG --> S2["Subscription: development"]
  MG --> S3["Subscription: shared services"]
  S1 --> RG1["Resource groups and resources"]
  S2 --> RG2["Resource groups and resources"]
  T --> M365["Microsoft 365 services"]
  T --> SAAS["Third party applications"]
  T --> EXT["Guest users from other tenants"]
        

One tenant or several?

The usual guidance is to use one production tenant and create separate tenants only for strong reasons such as legal separation, a merger in transition, or a safe place to test tenant-wide settings. Many companies keep a small non-production tenant for experiments with Conditional Access and tenant settings, because mistakes at tenant level affect everyone.

A tenant is made of a small number of object types. Knowing them makes the portal feel familiar.

Groups and dynamic membership

Assigning access to groups instead of individuals is a foundation of manageable identity. Dynamic groups compute their membership automatically from user or device attributes, so that everyone in a department, or every managed laptop, joins the group without manual work. When an attribute changes, the person moves in or out. This relies on accurate attributes, so data quality in the directory becomes a security control.

Administrative units and delegation

Not every administrator should control the entire tenant. Administrative units let you give a regional helpdesk the power to reset passwords only for users in its region. This supports least privilege and reduces the damage if a helpdesk account is compromised.

Naming and attribute quality

Because dynamic groups, access packages, and lifecycle workflows depend on attributes, the directory is only as good as its data. Department, job title, manager, employee type, and country should come from the authoritative human resources source and be kept consistent. A typing mistake in a department name can quietly leave a person out of a group or put them in the wrong one. Agree a data standard, automate attribute flow from the source system where possible, and report on missing or inconsistent values regularly.

How a person proves identity is the biggest factor in whether an account can be taken over.

The three kinds of proof

Authentication factors fall into three families: something you know, such as a password or PIN; something you have, such as a phone or a security key; and something you are, such as a fingerprint or face. Multifactor authentication combines at least two different families, so that stealing one is not enough.

Methods available in Entra ID

Why phishing-resistant matters

Most multifactor methods can be defeated by a convincing fake sign-in page that relays the user’s code to the real service. Phishing-resistant methods, such as passkeys and security keys, tie the proof to the real website address, so a fake site simply cannot obtain a working response. Microsoft’s own what’s-new page shows heavy investment here: synced passkeys, passkey profiles, passkey registration campaigns, and a move toward letting users with passkeys sign in without a password.

Authentication methods policy

Administrators control which methods are allowed and for whom through the authentication methods policy. Newer designs use passkey profiles to set different requirements for different groups, for example allowing only hardware-bound keys for administrators, while allowing synced passkeys for general staff. Combine this with registration campaigns that nudge users to enroll better methods.

Applications do not see your password. They receive tokens, which are issued through standard protocols.

Three standards

The tokens

Access tokens are signed by Entra ID and contain claims, which are statements such as the user’s identifier, the tenant, the application, the permissions granted, and the time of expiry. A receiving service checks the signature and the claims instead of calling the directory every time. This is why short lifetimes matter: a stolen access token works until it expires.

Continuous access evaluation

Because tokens live for a while, Microsoft added continuous access evaluation. Supporting services can react to critical events, such as a user being disabled, a password change, or a location change, and demand fresh authentication in near real time instead of waiting for tokens to expire. This narrows the window in which a stolen token is useful.

Following one sign-in from start to finish shows where every control fits.

Step one: redirect to the identity provider

A user opens an application. The application sees no valid session and redirects the browser to the Entra ID sign-in endpoint, naming itself and the permissions it wants.

Step two: primary authentication

Entra ID identifies which tenant the user belongs to, usually from the sign-in name. It then verifies the first factor, such as a passkey or password. For federated or synchronized domains, this step may be delegated to an on-premises system, as described in the hybrid chapter.

Step three: policy evaluation

Now the policy engine takes over. Entra ID collects signals: who the user is, which group memberships apply, which application is requested, the device state, the network location, the client type, and the real-time risk assessed by Identity Protection. It evaluates every Conditional Access policy that applies and combines the outcome. The result may be allow, block, or allow only after more proof, such as multifactor authentication, a compliant device, or acceptance of terms.

Step four: token issuance

If all requirements are met, Entra ID issues tokens and the browser returns to the application. The application validates the tokens and creates its own session. Every step is written to the sign-in logs, which administrators can query later.

sequenceDiagram
  participant U as User
  participant A as Application
  participant E as Entra ID
  participant P as Policy engine
  participant L as Sign in logs
  U->>A: Open application
  A->>U: Redirect to Entra sign in
  U->>E: Present first factor
  E->>P: Evaluate signals and Conditional Access
  P-->>E: Require multifactor and compliant device
  E->>U: Request second factor
  U->>E: Complete second factor
  E->>L: Record result and applied policies
  E->>A: Issue ID and access tokens
  A->>U: Signed in session
        

Where delays and failures hide

Most sign-in trouble is not in the first factor. It hides in the policy step, where a device is unmanaged, a location is not recognized, or a required method is not registered, and in the application step, where the app rejects a token because of a missing claim or an expired certificate. Knowing the four steps tells you which log to open first. If the sign-in log shows success but the user still cannot work, the problem is in the application. If it shows failure with a policy reason, adjust the policy or the user’s situation. If the attempt does not appear at all, the request never reached Entra ID.

Two portal blades with similar names cause endless confusion. They are two views of two linked objects.

The application object

When a developer creates an app registration, Entra ID stores an application object in the tenant where it was created, called the home tenant. This object is the global blueprint. It describes the application’s name, identifiers, redirect addresses, the permissions it requests, and the credentials it uses to prove itself.

The service principal

For an application to be used in a tenant, a service principal must exist in that tenant. It is the local instance, and it is what actually receives role assignments, user assignments, consent grants, and Conditional Access. In the portal, service principals appear under enterprise applications. An application used in many tenants has one application object and one service principal per tenant.

Permissions and consent

Applications ask for permissions to call interfaces such as Microsoft Graph. There are two kinds. Delegated permissions let the application act as the signed-in user, limited to what that user can do. Application permissions let the application act as itself with no user, which is powerful and usually requires administrator consent. Consent is the act of approving what an application asks for.

Credentials of applications

Applications prove themselves using client secrets, certificates, or federated credentials. Secrets are strings that expire and leak easily. Certificates are stronger. Federated credentials, covered in the workload identity chapter, remove stored secrets entirely. Set a short expiry on any secret, track expirations, and migrate to federation or managed identities wherever possible.

Entra ID connects to thousands of applications. The method depends on what the application supports.

Ways to integrate

The application gallery

The gallery lists thousands of prebuilt integrations with step-by-step setup. Choosing a gallery application usually creates the service principal and pre-fills common settings, which saves time and errors. For custom applications, register the app and choose the protocol that the code supports.

Assigning access

Conditional Access is where Entra ID turns signals into decisions. It is the single most important control to understand.

The shape of a policy

Every Conditional Access policy follows an if-then pattern. The assignments say who and what the policy applies to. The access controls say what must happen. If a sign-in matches the assignments, the controls are enforced.

Policies worth having

Safe rollout

Authentication strengths and session controls

Instead of simply requiring multifactor, a policy can require a named authentication strength, which is a set of allowed method combinations. Built-in strengths include basic multifactor, passwordless multifactor, and phishing-resistant multifactor, and custom strengths can be defined. Session controls shape how long a person stays signed in. A short sign-in frequency for administrators, and a longer one for low-risk applications on compliant devices, balances security with comfort. Too many prompts train users to approve anything, so aim for fewer, stronger checks.

Organizing policies so they stay understandable

Tenants with fifty overlapping Conditional Access policies become impossible to reason about. Use a clear naming convention that shows the target, the control, and the purpose, group policies by persona such as administrators, employees, guests, and workloads, and avoid creating a new policy for every complaint. Document the intent of each policy in its description, including the owner and the date of last review. Prefer fewer, broader policies with well-managed exceptions over many narrow ones, and retire policies that no longer apply. Clarity is itself a security control, because nobody can protect what nobody understands.

Microsoft’s enforcement affects people and automation, and the automation is where surprises happen.

What is covered

Phase 2 is enforced at Azure Resource Manager, so any tool that signs in as a user to change resources is affected. Microsoft Graph interfaces are generally out of scope. Break-glass emergency accounts are included, and Microsoft recommends passkeys or certificate-based authentication for them. Workload identities and sync accounts are not affected. Guests satisfy the requirement either in their home tenant, passing the claim through cross-tenant settings, or in the resource tenant.

Preparation steps

Not every sign-in is equally suspicious. Identity Protection scores risk so that policy can react.

Two kinds of risk

Risk levels are low, medium, or high. Conditional Access can use them directly. A common pair of policies requires multifactor for medium or high sign-in risk, and requires a secure password change for high user risk. Self-service remediation lets legitimate users clear their own risk by proving identity, reducing helpdesk load. This capability is part of the premium license tier.

Working with detections

Two separate permission systems exist, and mixing them up leads to either blocked work or hidden over-permission.

The two are independent. A Global Administrator of the tenant does not automatically have access to Azure subscriptions, but can elevate access to manage all subscriptions through a special setting. This elevation is powerful and should be rare, audited, and removed after use.

Principles for roles

The safest administrator permission is the one that does not exist until it is needed.

Eligible versus active

Privileged Identity Management, usually called PIM, turns permanent role assignments into eligible ones. An eligible administrator holds no power by default. When a task arises, the person activates the role for a limited time, perhaps one or two hours, after meeting requirements such as multifactor authentication, a written justification, a ticket number, or approval by another person. When time expires, the power disappears. All activations are logged and can trigger alerts.

flowchart LR
  E["Eligible administrator: no standing power"] --> R["Request activation with reason"]
  R --> C{"Requirements met?"}
  C -- "MFA and approval" --> A["Active for limited time"]
  C -- "No" --> D["Denied and logged"]
  A --> X["Time expires: role removed"]
  A --> L["Activation recorded in audit log"]
        

What PIM covers

Microsoft’s what’s-new page lists general availability, in May 2026, of enforcing Conditional Access, such as multifactor authentication, on every PIM activation. This closes a gap where a user who already satisfied multifactor earlier in a session could activate roles without a fresh strong check. PIM requires the governance-level premium licensing, so confirm what your agreement includes.

Approval, alerts, and reviews around PIM

The strongest PIM setups pair activation with oversight. Sensitive roles require approval from a named group, and notifications go to the security team on each activation. Alerts highlight roles assigned outside PIM, roles that are never used, and too many people holding the same role. Periodic reviews remove eligible assignments that are no longer justified. Over time, the data shows which roles are truly used and which can be narrowed, turning a one-off project into a continuous reduction of risk.

Programs need identities too, and the best program identity has no secret to steal.

The secret problem

For years, applications authenticated with client secrets stored in configuration files, build systems, and vaults. Secrets expire, get copied into tickets, and are discovered in repositories. A leaked secret works from anywhere until someone notices. Workload identity features exist to eliminate this class of risk.

Managed identities

A managed identity is an identity that Azure creates and manages for a resource such as a virtual machine, a web app, a function, or a container app. The resource asks the platform for a token, and the platform gives one without any password. There are two types.

Workload identity federation

Programs running outside Azure, such as pipelines on a code platform or workloads in another cloud or a Kubernetes cluster, can use federated credentials. You configure Entra ID to trust tokens from an external identity provider that meet stated conditions, such as a particular repository and branch. At run time, the program presents the external token and exchanges it for a short-lived Entra token. No secret is stored anywhere.

flowchart LR
  EXT["External workload: pipeline or cluster"] --> TOK["Gets signed token from its own platform"]
  TOK --> EX["Presents token to Entra ID"]
  EX --> V{"Matches federated credential trust?"}
  V -- Yes --> AT["Short lived Entra access token"]
  V -- No --> DN["Rejected"]
  AT --> RES["Azure resources and Graph"]
        

Governing workload identities

Most established companies run both worlds, and the bridge between them deserves careful design.

Synchronization

Microsoft Entra Connect Sync is a server-based tool installed on premises that copies users, groups, and selected attributes from Active Directory to Entra ID. Microsoft Entra Cloud Sync is a lighter alternative using lightweight agents and cloud-based configuration, supporting multiple disconnected forests. Microsoft’s what’s-new page says notifications begin in July 2026 for a phased migration from Connect Sync to Cloud Sync, with customers needing advanced features or having large directories not in the first waves. Review feature parity before planning.

Three sign-in options

Microsoft generally recommends password hash synchronization, optionally with seamless single sign-on, for most organizations, and treats federation as the option to move away from when possible.

Operational care

Planning a move to cloud-first authentication

Organizations that still federate sign-in often run a federation farm, load balancers, certificates, and proxy servers, all of which can fail or be attacked. Moving to password hash synchronization is usually a staged process: enable synchronization, test with a pilot group, verify that all applications and policies work, switch the domain to managed authentication, and later decommission the federation servers. Keep a rollback plan and communicate changes to support teams. The reward is fewer servers, fewer outages, and access to cloud-based detections such as leaked credentials.

Business happens across organizations. Collaboration should not mean losing control.

B2B collaboration

Business-to-business collaboration lets you invite people from other organizations as guest users. They sign in with their own work identity, or with a one-time code or social account where allowed, and receive access to your applications and documents. You never manage their passwords. Their account lifecycle remains with their home organization, which is both an advantage and a risk, since you may not know when they leave that company.

Cross-tenant access settings

Customer-facing identity

For apps used by customers, Microsoft Entra External ID provides sign-up, sign-in, and profile management at large scale, separate from the workforce tenant. It supports social accounts, branded experiences, and customizable flows. Keep customer identities out of the workforce tenant, since their security and lifecycle needs are different.

Access tends to grow and never shrink. Governance is the discipline that makes it shrink.

The joiner, mover, leaver cycle

These capabilities require governance-level licensing in addition to the premium tiers. Even without them, you can adopt the habit using groups, manual reviews, and consistent offboarding. The tooling automates the habit, and the habit matters more than the tooling.

Making reviews meaningful

Reviews fail when reviewers cannot tell what they are approving. Show them clear names, last sign-in dates, and the reason access was granted. Choose reviewers who actually know the work, such as managers and resource owners, rather than a central team that guesses. Set a sensible default for unanswered reviews, usually removal for guests and privileged access. Keep campaigns short and focused, and report the results to leadership. When people see that access truly disappears, the process earns respect and participation rises.

Identity is stronger when the device is known and healthy.

Three device states

Compliance and Conditional Access

Device management with Intune evaluates devices against compliance rules, such as disk encryption, a minimum operating system version, and active protection. A Conditional Access policy can then demand a compliant device before allowing access to sensitive data. The result links user, device, and application in one decision. Microsoft’s June 2026 note says the Authenticator app blocks rooted and jailbroken devices for work accounts, which adds a further device-health signal.

Features are gated by license. Knowing the tiers prevents design on features you do not own. Always check Microsoft’s current licensing pages, as bundles change.

Licensing habits

An identity system without logs is a locked door with no camera.

The core logs

Portal retention is limited, commonly seven days on the free tier and thirty days on premium. For longer retention and richer analysis, send logs through diagnostic settings to a Log Analytics workspace, a storage account, or an event hub. In a workspace, you can write alerts for events such as new Global Administrator assignments, changes to Conditional Access, credential additions to applications, and spikes in failed sign-ins.

flowchart LR
  ENT["Entra ID logs"] --> DS["Diagnostic settings"]
  DS --> LAW["Log Analytics workspace"]
  DS --> ST["Storage account for archive"]
  DS --> EH["Event hub to SIEM"]
  LAW --> AL["Alerts on high risk changes"]
  LAW --> WB["Workbooks and reports"]
        

Building a short monitoring routine

Daily, glance at high-severity alerts such as emergency account use and risky administrator sign-ins. Weekly, review failed sign-ins by application, new application credentials, and changes to policies. Monthly, review the secure score, expiring certificates and secrets, guests added, and unused privileged roles. Quarterly, test emergency access and review the Conditional Access policy list for exclusions that no longer make sense. A routine measured in minutes per day catches the quiet changes that attackers rely on you not noticing.

A strong identity design includes a plan for the day the normal door is locked.

Emergency access accounts

Emergency access accounts, often called break-glass accounts, are cloud-only accounts holding the highest role, intended for the rare day when normal administrators are locked out by a misconfigured policy, a failed multifactor service, or an outage of the federation system. Keep at least two. Name them clearly, give them long random passwords stored securely in separate places, and, importantly, give them a phishing-resistant method because mandatory multifactor now applies to them as well. Microsoft recommends passkeys or certificate-based authentication for these accounts.

A baseline checklist

Software that acts on its own needs an identity, an owner, and limits, just like a person.

Why agents are different

An autonomous agent may call many services, read data, and take actions without a person approving each step. If it shares a developer’s credentials or a broad service account, nobody can tell what it did, or limit what it may do. Microsoft Entra Agent ID gives each agent its own identity in the directory, with a sponsor accountable for it, lifecycle controls, and eligibility for Conditional Access. According to Microsoft’s what’s-new page, the platform became generally available in April 2026, uses OAuth 2.0, and supports agent protocols. It also notes that sponsorship can transfer to a manager automatically through lifecycle workflows when a sponsor leaves, and that Conditional Access protections for agent accounts are in preview from June 2026.

Every tenant carries technical debt from the Azure AD years. A planned cleanup avoids deadline emergencies.

A cleanup method

Experience from many tenants shows recurring good and bad designs.

Four short stories show how the controls combine.

A quick reference of what experienced identity teams do and what they avoid.

A sensible first ninety days

For a tenant with weak controls, the first month should secure the highest-value accounts: create emergency accounts, require multifactor for administrators, and block legacy authentication in report-only mode before enforcing. The second month should widen coverage: multifactor for all users, passkey registration for administrators, restricted consent, and logging to a workspace. The third month should reduce standing power and secrets: PIM for roles, conversion of user-based automation to workload identities, and the first access reviews of guests. Each step is valuable on its own and makes the next safer.

Most identity problems fall into a few families. Work through them in order, and use the logs first.

flowchart TD
  S["User cannot sign in or reach app"] --> Q1{"Sign in attempt appears in logs?"}
  Q1 -- No --> F1["Check network, DNS, domain, and sync status"]
  Q1 -- Yes --> Q2{"Failure at authentication step?"}
  Q2 -- Yes --> F2["Check method registration, lockout, password, and TAP"]
  Q2 -- No --> Q3{"Conditional Access failed?"}
  Q3 -- Yes --> F3["Read policy result, device state, location, risk"]
  Q3 -- No --> Q4{"App denies after sign in?"}
  Q4 -- Yes --> F4["Check assignment, consent, app roles, certificate"]
  Q4 -- No --> F5["Check token claims and application configuration"]
        

Tools that help

Short answers to questions that beginners and architects ask most often.

Microsoft Entra ID is the identity control plane for Azure, Microsoft 365, and thousands of other applications. Good outcomes come from strong authentication, careful policy, minimal standing privilege, workload identities without secrets, and steady governance.