Microsoft Entra ID (Azure AD): The Front Door and Doorman for Everything You Run in the Cloud
An intermediate, plain-English guide to Microsoft Entra ID, the identity service formerly called Azure Active Directory — how people, apps and machines prove who they are, how access decisions are made, how hybrid and external users fit in, and how to keep the whole system secure, observable and affordable.
Picture a large office building with hundreds of rooms, thousands of employees, regular visitors, delivery robots and a few contractors who come only on Tuesdays. Somebody has to decide who gets a badge, which doors each badge opens, what extra checks are needed for the server room, and what happens on the day an employee leaves. If every room had its own lock and its own list of people, the building would be chaos. Instead there is a single security desk that issues badges, checks identities and records every entry. Microsoft Entra ID is that security desk for your digital building.
In this guide we will go step by step through what the service is, how its parts fit together, how a sign-in travels from a user’s screen to an application and back, how access policies are decided, how apps and machines get their own identities, how on-premises directories connect, and how to run all of it safely. We will also be clear about the recent name changes and retirements, because many older tutorials still describe tools and products that have since moved on.
1What Entra ID Is and Why It Exists
Every digital action starts with the question “who is asking?”
When you open your work email, join a video meeting, deploy to a cloud subscription or call an internal service, the system you reach must answer two questions. First, authentication: are you really who you claim to be? Second, authorization: are you allowed to do what you are trying to do? Doing this separately in every application would mean thousands of passwords, inconsistent security rules and no central place to switch someone off.
Microsoft Entra ID is Microsoft’s cloud-based identity and access management service. It stores identities for people, groups, devices and applications, verifies them when they sign in, issues secure tokens that applications trust, and applies policies that decide whether access is granted. It is the identity backbone behind Microsoft 365, Azure, Dynamics, Teams and thousands of third-party applications that support standard sign-in protocols.
The name change in plain words
The service was long known as Azure Active Directory, or Azure AD. In 2023 Microsoft renamed it Microsoft Entra ID as part of a wider family of identity and network access products called Microsoft Entra. Only the name changed. The service, the licences, the features and the data stayed the same, which is why you will still see old names in screenshots, scripts and documentation. If you read “Azure AD” anywhere, mentally replace it with “Entra ID”.
Think of a country’s passport office. It issues a trusted document once, and every airport, hotel and bank accepts it instead of inventing its own identity check. Entra ID issues the passport, and applications are the airports that trust it.
It is not the same as Windows Server Active Directory
The old name caused real confusion, because the product is quite different from the traditional on-premises Active Directory that has run in company server rooms since 1999. The on-premises version uses protocols such as Kerberos and LDAP and manages domain-joined computers with group policy. Entra ID is a modern internet-scale service using web protocols such as OpenID Connect, OAuth 2.0 and SAML. Many organisations use both, joined by synchronisation, which we will cover in the hybrid chapter.
2The Big Picture: The Entra Family and the Tenant
One core service, surrounded by capabilities that solve neighbouring problems.
Entra ID is the heart of a larger family. Understanding how the members relate to each other makes licence and design conversations much easier.
Entra ID
The directory, sign-in service, single sign-on, multi-factor authentication, conditional access and application integration.
ID Protection
Detects risky sign-ins and risky users using signals from across Microsoft and can respond automatically.
ID Governance
Access reviews, entitlement management and lifecycle workflows so that access stays appropriate over time.
Privileged Identity Management
Makes powerful roles available only when needed, for a limited time and often with approval.
External ID
Identity for customers and partners outside your organisation, successor to the older consumer identity service.
Workload ID
Secure identities and policies for applications, services and automation rather than people.
Global Secure Access
Identity-aware network access to internet and private resources, combining network and identity controls.
Verified ID
Issues and checks portable digital credentials, such as proof of employment, that users can hold themselves.
The tenant: your private identity universe
Everything lives inside a tenant. A tenant is a dedicated, isolated instance of Entra ID that belongs to one organisation. It holds that organisation’s users, groups, applications, policies and settings. When a company signs up for Microsoft 365 or Azure, a tenant is created for it. Users sign in to their company tenant, and applications are registered inside it.
flowchart TD
T["Entra tenant"] --> U["Users and groups"]
T --> D["Devices"]
T --> A["Applications and service principals"]
T --> P["Policies: conditional access, authentication methods"]
T --> R["Roles and administrative units"]
U --> M365["Microsoft 365"]
U --> AZ["Azure subscriptions"]
U --> SAAS["Third-party SaaS apps"]
A --> API["Your own APIs"]
An Azure subscription trusts exactly one tenant for identity. The tenant is the identity layer, while the subscription is the billing and resource layer. Moving a subscription to another tenant is possible but has consequences for access assignments.
3Core Concepts You Must Know
A small vocabulary unlocks every portal blade and every document.
Identity has more jargon than most areas of technology. Learning the following terms once will save you from confusion for years.
Identity
A digital representation of something that can sign in or be granted access: a person, a device, an application or a workload.
Principal
Any identity that can be given permissions. Users, groups, service principals and managed identities are all principals.
Group
A collection of identities managed together. Assigning access to a group is far easier than to individuals.
App registration
The definition of an application in the tenant: its identifier, how it signs in and what permissions it asks for.
Service principal
The local instance of an application inside a tenant, which is what actually receives permissions and shows up as an enterprise application.
Managed identity
An identity that Azure creates and manages for a resource, so code can authenticate without any stored secret.
Token
A signed, time-limited statement about who someone is and what they may do, which applications validate instead of asking for passwords.
Claim
A single fact inside a token, such as the user’s identifier, their tenant or the groups they belong to.
Scope and permission
A named piece of access an application requests, such as the right to read a user’s calendar.
Consent
Approval, by a user or an administrator, for an application to act with specific permissions.
An app registration is like a company’s registration certificate: it describes the company in general. A service principal is like the company’s employee badge inside one particular building: it is what the building’s doors actually recognise. The same company may hold badges in many buildings, but there is one certificate.
People often mix up app registrations and enterprise applications. The registration is the blueprint, created where the app is developed. The enterprise application is the instance in a tenant, where you manage who can use it and how it signs in.
4Architecture and Components
What Microsoft runs, and what you decide.
Entra ID is a globally distributed service run by Microsoft. Your responsibility is the configuration of your tenant: who exists in it, which applications trust it, which policies apply and how it connects to other directories. The table below separates the layers.
| Component | Responsibility | Who operates it |
|---|---|---|
| Global identity service | Stores directory data, authenticates sign-ins, issues tokens at huge scale with built-in redundancy | Microsoft |
| Your tenant configuration | Users, groups, roles, policies, authentication methods and settings | Your administrators |
| Application integrations | Registrations and enterprise applications that trust the tenant | App owners and administrators |
| Protocols and endpoints | OpenID Connect, OAuth 2.0, SAML and related standards | Microsoft implements, apps consume |
| Synchronisation tools | Bring identities from on-premises directories into the tenant | You install, Microsoft supplies |
| Policy engines | Conditional access, identity protection and governance decisions at sign-in time | Microsoft runs, you set the rules |
| Logs and reporting | Sign-in and audit records, health and usage insights | Microsoft collects, you route and review |
Control plane and data plane thinking
It helps to separate management from runtime. Management is what administrators do in the portal or through automation: creating users, writing policies, registering applications. Runtime is what happens millions of times a minute: a user signs in, a token is issued, an application validates it. Problems in management are usually mistakes in configuration. Problems at runtime are often about policies, tokens, network access or a user’s device.
Management example
An administrator accidentally removes a group from a conditional access exclusion list, and suddenly an automation account is blocked. The fix lies in configuration, not in the application.
Runtime example
A user can sign in at the office but is blocked at home because a policy requires a compliant device. The behaviour is correct runtime enforcement of a policy that the administrator wrote.
5Internal Working: The Life of One Sign-in
Follow a user from a browser tab to a working application.
The journey of a single sign-in is the most useful thing to understand about the entire service. It explains tokens, single sign-on, policy checks and many error messages. Here is the modern flow using OpenID Connect, the most common protocol for new applications.
sequenceDiagram
participant User
participant App as Application
participant Entra as Entra ID
participant API as Protected API
User->>App: Opens the application
App->>Entra: Redirect user to sign in
Entra->>User: Ask for credentials and extra proof
User->>Entra: Provides password, prompt or passkey
Entra->>Entra: Evaluate policies and risk
Entra-->>App: Return signed tokens
App->>App: Validate token signature and claims
App->>API: Call API with access token
API->>API: Validate token and check permissions
API-->>App: Return data
App-->>User: Show personalised page
The application redirects the user
The app never sees the password. It sends the user to the Entra sign-in page with a request describing who the app is and what it needs.
The user proves who they are
Entra asks for whatever the policy and the user’s registered methods require, such as a password plus a notification, or a passkey on its own.
Policies and risk are evaluated
Conditional access rules look at the user, application, device, location and risk level and decide to allow, require more proof or block.
Tokens are issued
Entra returns an identity token that says who signed in, and an access token that lets the app call a specific API. Both are digitally signed.
The app and API validate the tokens
They check the signature, the issuer, the audience, the expiry and the claims. Only if everything matches is access granted.
Single sign-on makes the next app instant
A session is kept by the browser and Entra, so a second application can obtain its own tokens without prompting the user again, unless policy requires a fresh check.
Three kinds of token
ID token
Tells the application who the user is. It is meant for the app itself and should not be sent to other services.
Access token
Tells an API what the caller is allowed to do. Short-lived, typically around an hour, and sent with each API request.
Refresh token
Lets the app quietly obtain new access tokens without making the user sign in again. It is long-lived and must be stored with great care.
Never build your own token validation or sign-in screen. Use the Microsoft authentication libraries and standard middleware, which handle token caching, renewal and the many subtle security checks correctly.
6Identities: Users, Groups, Guests and Devices
Different things sign in, and each needs a sensible home.
A directory is only useful if it models the real world accurately. Entra ID represents several kinds of identity, and choosing the right kind for each situation avoids security gaps.
Member users
Employees and regular members of your organisation, either created in the cloud or synchronised from an on-premises directory.
Guest users
People from partner organisations invited to collaborate. They sign in with their own organisation’s identity and are limited by default.
Security and Microsoft 365 groups
Security groups grant access to resources. Microsoft 365 groups also bring a shared mailbox, calendar and workspace.
Dynamic groups
Membership is calculated automatically from attributes such as department, so people join and leave groups as their job changes.
Devices
Laptops, phones and tablets known to the tenant, which can be required to meet security standards before access.
Service principals and managed identities
Non-human identities for applications and automation, discussed in their own chapter.
Three ways a device can be known
| State | Meaning | Typical use |
|---|---|---|
| Registered | A personal device added to the tenant for lightweight access to work resources | Bring your own device on phones and personal laptops |
| Joined | A company device that signs in to Windows directly with a work account and is managed by the organisation | Cloud-first corporate laptops |
| Hybrid joined | A company device joined to the on-premises directory and also known to Entra ID | Organisations still running traditional domains |
A registered device is like a visitor’s laptop allowed into the guest lounge. A joined device is a company-issued laptop that works in every office. Hybrid joined is a company laptop that works both with the old badge system and the new one.
Give access to groups, never directly to individuals, and use dynamic membership where attributes are reliable. When someone changes role, their access changes automatically, and nobody forgets to remove an old permission.
7Authentication Methods: Proving Who You Are
The weakest credential decides the strength of the whole system.
Passwords are the oldest and weakest way to prove identity. They get reused, guessed, phished and leaked. Modern identity strategy is therefore about adding stronger methods and gradually reducing dependence on passwords altogether. Entra ID supports a range of methods, and the central authentication methods policy lets administrators choose which ones each group of users may register and use.
Password only
Weakest. One stolen or guessed secret gives full access. Should not be used alone for anything important.
Password plus text message or call
Better than nothing, but messages can be intercepted or redirected through number swapping. Microsoft has announced changes to how SMS and voice are used for multi-factor authentication, so check current guidance and avoid building new plans around them.
Authenticator app with number matching
The user approves a sign-in on their phone and must enter a number shown on the sign-in screen, which defeats casual approval of fraudulent prompts.
Passwordless with passkeys and security keys
Credentials based on public key cryptography that cannot be typed into a fake website. Includes FIDO2 security keys, passkeys on devices and Windows Hello for Business.
Certificate-based authentication
Uses smart cards or certificates, common in government and highly regulated settings.
Phishing resistance is the goal
Attackers increasingly use fake sign-in pages that relay a user’s password and approval to the real service in real time. Methods whose proof is bound to the genuine website, such as passkeys and security keys, defeat this trick because the credential simply refuses to work on the fake site. For administrators and other high-value accounts, phishing-resistant methods are the target state.
Helpful supporting features
Self-service password reset
Lets users fix their own forgotten passwords after proving identity, reducing help desk load. Registration must be completed before the day it is needed.
Temporary access pass
A time-limited code issued by an administrator so a new employee can sign in once and register a strong method without ever using a password.
Password protection
Blocks commonly used and company-specific weak passwords, and can extend the checks to on-premises directories.
A password is like a key anyone can copy if they see it once. A passkey is like a lock that only opens for your fingerprint on your own device and refuses to even try on a stranger’s door.
A strong policy is useless if users never register strong methods. Run registration campaigns, make registration part of onboarding and watch reports for users still relying only on weak methods.
8Conditional Access: The Policy Brain
Not every sign-in deserves the same level of trust.
A sign-in from a managed laptop on the office network is quite different from a sign-in from an unknown device in a distant country at three in the morning. Conditional access is the policy engine that makes this difference count. Each policy follows an “if this, then that” shape: if certain conditions are true, then require certain controls.
flowchart LR
S["Sign-in attempt"] --> C{"Evaluate signals"}
C -->|"Who: user, group or role"| P["Matching policies"]
C -->|"What: application"| P
C -->|"Where: location or network"| P
C -->|"Device: compliant or not"| P
C -->|"Risk: user or sign-in risk"| P
P --> D{"Decision"}
D -->|"Allow"| A["Grant access"]
D -->|"Require more"| M["Multi-factor, compliant device or terms of use"]
D -->|"Block"| B["Deny access"]
M --> A
Signals in, decisions out
User and role
Target everyone, selected groups, guests or administrators, with exclusions for emergency accounts.
Application
Apply stricter rules to sensitive applications such as finance or administration portals.
Location and network
Treat trusted office networks differently from unknown countries, or block countries where you have no staff.
Device state
Require compliant or hybrid-joined devices for sensitive data.
Risk
Use risk scores from ID Protection to demand a password change or extra proof when something looks suspicious.
Grant or session controls
Require multi-factor authentication, a compliant device, an approved app, a terms-of-use acceptance, or limit session length and download rights.
Security defaults for small tenants
Organisations without a premium licence can switch on security defaults, a ready-made baseline that requires multi-factor registration, challenges administrators and blocks legacy sign-in methods that cannot support modern protections. It is a sensible start, though it cannot be customised the way conditional access can.
Conditional access is like an airport security desk with intelligent rules. A frequent traveller with a trusted pass on a regular route walks through quickly. Someone arriving with unusual luggage on a one-way ticket to a high-risk destination gets extra screening.
A badly written policy can lock out every administrator, including you. Always keep at least two emergency access accounts that are excluded from policies, protected by very strong credentials, monitored for any use and tested regularly. Use report-only mode to preview a policy before enforcing it.
Organisations that connected external multi-factor providers through the older custom controls feature should note that Microsoft is retiring it in favour of External MFA, a standard integration now generally available. Check the official timeline and plan the move.
9Applications and Single Sign-on
One identity, many applications, one set of rules.
The real payoff of a central identity service shows when applications connect to it. Users sign in once and move between applications without retyping credentials, while administrators control access from one place and see sign-ins in one log.
Protocols in everyday language
| Protocol | Purpose | Typical use |
|---|---|---|
| OpenID Connect | Modern sign-in for users, built on OAuth 2.0 | New web apps, mobile apps and single-page apps |
| OAuth 2.0 | Delegated authorisation to call APIs | Apps calling Microsoft Graph or your own APIs |
| SAML | Older, XML-based single sign-on | Many established software-as-a-service products |
| Password-based or linked sign-on | Fallback for apps without modern protocols | Legacy web apps, used sparingly |
| Application proxy | Publishes internal web apps securely without opening inbound firewall ports | Internal sites reached from outside |
Three paths to connect an application
Gallery applications
Thousands of popular products have preconfigured entries. You add the app, set up single sign-on with a guided wizard, assign users and finish.
Your own applications
Developers create an app registration, choose the sign-in method, define permissions and use Microsoft’s libraries. The matching enterprise application controls who can use it.
On-premises web applications
Application proxy publishes them securely, putting modern sign-in and conditional access in front of apps that never knew about them.
Consent: who approves what an app may do
When an application asks to read mail or files on a user’s behalf, someone must agree. Some permissions can be approved by users; powerful ones need an administrator. Attackers sometimes trick people into approving a malicious application, so administrators should restrict user consent to low-risk permissions from verified publishers and offer a review workflow for everything else.
A fake application can ask a user to “allow access” and then read their data with no password ever stolen. Limit user consent, review granted permissions regularly and remove applications nobody recognises.
Applications that read the directory should use Microsoft Graph. The older Azure AD Graph interface has been retired, so any tools still calling it need to be updated.
10Workload Identities: Giving Machines Their Own Badges
Code needs to sign in too, and secrets in code are a disaster waiting to happen.
Applications, scripts and pipelines also need to authenticate, for example to read from storage or call a database. For years the standard answer was to create a client secret, paste it into a configuration file and hope nobody noticed. Secrets leak, expire at inconvenient moments and are rarely rotated. Entra ID offers better options, ordered here from best to worst.
Managed identities
For code running on Azure resources. Azure creates and rotates the credentials, and the code simply asks the platform for a token. No secret exists anywhere for a developer to leak.
Workload identity federation
For code running outside Azure, such as a deployment pipeline or another cloud. The external platform’s own identity token is exchanged for an Entra token under strict trust rules, with no stored secret.
Certificates
A stronger credential than secrets, kept in a protected store and rotated on a schedule.
Client secrets
Last resort. Short lifetimes, secure storage and expiry alerts are essential if they must be used.
sequenceDiagram
participant Ext as External workload, such as a pipeline
participant Idp as Its own identity provider
participant Entra as Entra ID
participant Res as Azure resource
Ext->>Idp: Request identity token
Idp-->>Ext: Signed token describing the workload
Ext->>Entra: Present token and ask for access
Entra->>Entra: Check trust configuration and claims
Entra-->>Ext: Short-lived Entra access token
Ext->>Res: Call resource with access token
Advantages of managed identity and federation
- No secrets to store, leak or rotate
- Credentials are short-lived
- Access can be limited to a specific workload
- Fewer midnight outages from expired secrets
Things to handle carefully
- Trust rules written too loosely let unintended workloads in
- Not every external system supports federation
- Permissions granted to the identity still need least privilege
A client secret is like a spare key hidden under a flowerpot: anyone who finds it can use it, and nobody notices if it gets copied. A managed identity is like a smart badge built into the door itself, which opens for the right worker and cannot be taken away in a pocket.
One of the most common outages in cloud systems is a client secret that quietly expired. Inventory every app registration with a secret, track expiry dates and aim to replace them with managed identities or federation.
11Authorization: Roles, RBAC and Privileged Access
Knowing who someone is differs from deciding what they may do.
Authentication says who you are. Authorization says what you can do. Entra ID has two separate role systems, and mixing them up is one of the most common beginner errors.
| Aspect | Entra roles | Azure role-based access control |
|---|---|---|
| Controls | Managing the directory and Microsoft 365 services: users, groups, policies, applications | Managing Azure resources: virtual machines, storage, databases, networks |
| Scope | Tenant, administrative unit or single object | Management group, subscription, resource group or resource |
| Example role | User administrator, Conditional access administrator | Reader, Contributor, Owner |
| Managed in | Entra admin centre | Azure portal access control pages |
Administrative units
In large organisations you may want a regional help desk to reset passwords only for users in their own region. An administrative unit is a container of users, groups or devices to which a role can be limited. It lets you delegate power narrowly rather than making everyone a global administrator.
Privileged Identity Management
Permanent powerful access is a standing risk. If an administrator’s account is stolen, the attacker inherits everything. Privileged Identity Management, often called PIM, turns permanent assignments into eligible ones. An administrator who needs a powerful role requests activation, gives a reason, perhaps obtains approval, completes multi-factor authentication and receives the role for a few hours only. Every activation is logged and can be reviewed.
Make the role eligible, not permanent
The administrator holds no active power by default.
Request activation with a reason
The person explains why they need the role and for how long.
Prove identity again and obtain approval if required
Multi-factor authentication and, for the most sensitive roles, a second person’s approval.
Work with time-limited power
The role expires automatically, and the activation record is kept for audit.
Permanent administrator rights are like carrying the master key to the whole building on your belt all day, every day. PIM is like checking the master key out from a locked cabinet only when you need it, signing the logbook and returning it afterwards.
Administrators should use dedicated accounts for administrative work, without a mailbox or everyday browsing, so that a phishing email read on the normal account cannot hand an attacker the keys.
12Hybrid Identity: Bridging On-premises and the Cloud
Most organisations did not start in the cloud, and many have not left the data centre completely.
Many companies already have an on-premises Active Directory with years of users, groups and computers. Throwing it away would be impractical, so Microsoft provides tools to synchronise it with Entra ID, giving users one identity for both worlds.
flowchart LR
AD["On-premises Active Directory"] --> SY["Synchronisation: Entra Connect or Cloud Sync"]
SY --> E["Entra ID tenant"]
E --> M["Microsoft 365"]
E --> Z["Azure and SaaS apps"]
U["User signs in"] --> V{"How is the password verified?"}
V -->|"Password hash sync"| E
V -->|"Pass-through authentication"| AG["Agent checks on-premises"]
V -->|"Federation"| F["On-premises federation service"]
Two synchronisation tools
Microsoft Entra Connect
The long-established synchronisation server with the richest feature set, suited to complex environments with many forests or special requirements.
Microsoft Entra Cloud Sync
A lightweight alternative using small agents managed from the cloud. Simpler to run and recommended where its capabilities are sufficient.
How are passwords verified?
| Method | How it works | Consideration |
|---|---|---|
| Password hash synchronisation | A secure, non-reversible fingerprint of the password hash is synchronised so sign-in happens in the cloud | Simplest and most resilient; also powers leaked credential detection |
| Pass-through authentication | The cloud passes the sign-in to an on-premises agent that checks the password | Needs agents running at all times |
| Federation | Sign-in is redirected to an on-premises federation service | Most complex; failure of that service stops sign-in |
Synchronisation is like keeping a copy of the staff register in two buildings. Password hash sync gives the new building its own guard who can check badges, while pass-through and federation make the new building phone the old one every time someone arrives.
Most organisations are best served by password hash synchronisation, even as a backup to other methods, because it keeps sign-in working if on-premises systems are unavailable.
The synchronisation server holds powerful credentials. Treat it as one of the most sensitive systems you own, patch it promptly, restrict access and monitor it closely.
13Identity Governance: Keeping Access Appropriate Over Time
Giving access is easy. Taking it back at the right moment is where organisations fail.
Access tends to accumulate. People change teams, projects end and contractors leave, yet permissions remain. Over years this creates an enormous hidden risk. Governance features keep access matched to current need.
Entitlement management
Bundles groups, applications and sites into access packages that people request, with approval rules and automatic expiry.
Access reviews
Asks managers, owners or the users themselves to confirm periodically that access is still needed, and removes it if not.
Lifecycle workflows
Run tasks automatically when people join, move or leave, such as sending welcome messages, adding to groups or disabling accounts.
Terms of use
Requires users to read and accept conditions before accessing sensitive systems.
The joiner, mover, leaver mindset
Identity professionals often think in three events. A joiner needs the right access on day one. A mover should gain the new role’s access and lose the old role’s access. A leaver must lose everything quickly. Good governance automates all three, using the human resources system as the trusted source of truth, so that access follows the real world without relying on someone remembering to raise a ticket.
Without governance, access is like a coat check where nobody ever returns the tickets: the pile only grows. Access reviews are the evening staff walking the cloakroom and returning every coat that no longer has an owner present.
Begin reviews with privileged roles, guest users and access to your most sensitive applications. You get the largest risk reduction for the smallest effort.
14Identity Protection and Threat Detection
Assume some attacks will get through, and make them noisy.
Even with strong authentication, attackers keep trying. ID Protection uses signals from across Microsoft’s global network to detect suspicious behaviour and attach a risk level to both sign-ins and users.
Examples of what it notices
Leaked credentials
Credentials found for sale or published online matching your users, which marks those users as at risk.
Impossible travel and unfamiliar locations
A sign-in from one continent minutes after another from a different continent, or from a place the user has never signed in before.
Anonymous networks and malicious addresses
Sign-ins from known hiding networks or sources associated with attacks.
Token theft and unusual sessions
Signs that a token was stolen and replayed from another machine.
Risk-based responses
The power of these signals comes from linking them to conditional access. A policy can say “if sign-in risk is medium or higher, require multi-factor authentication” and “if user risk is high, require a secure password change”. The system then responds in seconds without waiting for a person to read an alert.
A reported risky user is often a stolen account that has not yet been used loudly. Review the risky user report regularly and automate remediation where you can.
15External Identities: Partners and Customers
People outside your organisation need access too, safely.
Businesses rarely work alone. Suppliers need to see orders, consultants need access to project sites and customers need to sign in to portals. Entra provides two related approaches, and it is important to know which one fits.
Business collaboration with partners
- Invite people from other organisations as guests
- They sign in with their own company identity
- You control what they can see and when access ends
- Cross-tenant settings can trust their security checks
Customer-facing identity
- Sign-up and sign-in experiences for large numbers of consumers
- Social sign-in, email codes and custom branding
- Designed to scale to millions of accounts
- Kept separate from workforce identities
What changed with consumer identity
Microsoft’s customer identity platform has evolved. The older Azure AD B2C service stopped being sold to new customers in May 2025, and Microsoft Entra External ID is the recommended platform for new customer-facing applications. Existing B2C customers remain supported for a stated period but are in maintenance mode, and some premium features of the old service were retired in 2026. Migrating is not trivial, because user accounts can be moved but passwords cannot be exported and the old custom policy model does not translate directly. Confirm current dates and guidance on official Microsoft pages before planning.
Partner access is like issuing visitor badges to people from friendly companies, who also carry their own company badge. Customer identity is like running a public shop with a loyalty card system that has to work for millions of walk-in customers.
Guests quietly accumulate. Set expiry on guest access, run access reviews and restrict which domains you invite, so partner access does not become a permanent open door.
16Monitoring, Logging and Metrics
If you cannot see sign-ins, you cannot defend them.
Identity is the new perimeter, so the records it produces are among the most valuable security data you have. Entra ID collects several kinds of logs, and knowing which answers which question speeds up both investigations and audits.
| Log or report | What it records | Typical question answered |
|---|---|---|
| Sign-in logs | Every interactive and non-interactive sign-in, including policy results and failure reasons | Why was this user blocked, or from where did they sign in? |
| Audit logs | Changes made in the directory, such as role assignments and policy edits | Who changed this setting and when? |
| Provisioning logs | Activity of automatic account creation and updates in connected apps | Why did this user not appear in the application? |
| Risk reports | Risky users and risky sign-ins from ID Protection | Which accounts may be compromised? |
| Usage and insights reports | Application usage, authentication method registration and policy impact | Which apps are unused, and who still lacks strong methods? |
Send logs where you can analyse and keep them
The portal keeps logs for a limited period that depends on your licence. For longer retention and richer analysis, route them through diagnostic settings to a Log Analytics workspace, a storage account or a security information and event management platform. In a workspace you can write queries, build workbooks and create alerts on events such as an emergency account signing in, a new global administrator being added or a spike in failed sign-ins.
Create an alert that fires immediately whenever an emergency access account signs in. Such accounts should almost never be used, so any use deserves instant attention.
Logs contain user names, locations and device details. Restrict who can read them, set sensible retention and treat them as sensitive data in their own right.
17Licensing, Cost, Scaling and Reliability
What you pay for, and how to stay available when things break.
Entra ID is offered in tiers. Exact names, bundles and prices change over time and often arrive inside larger Microsoft 365 packages, so check the official licensing pages for the current picture. The overall shape has been stable for a while.
| Tier | Typical capabilities |
|---|---|
| Free | Core directory, basic single sign-on, security defaults, basic reports |
| Premium P1 | Conditional access, dynamic groups, self-service password reset with writeback, application proxy, hybrid features |
| Premium P2 | Everything in P1 plus ID Protection and Privileged Identity Management |
| Governance add-ons | Access reviews at scale, entitlement management, lifecycle workflows |
| Workload ID and other add-ons | Conditional access and protection for applications and services, plus other specialised capabilities |
Cost habits
License by need
Use group-based licensing so people receive exactly the tier their role requires, and remove licences automatically when they leave.
Review unused licences
Check usage reports for assigned but inactive licences, and for features paid for but never configured.
Plan for external users
Pricing for guest and customer identities is usage-based and different from workforce licensing, so estimate it separately.
Designing for reliability
Entra ID is built as a highly available global service, but identity is a single point of dependency for almost everything, so your own configuration should plan for trouble. Keep emergency access accounts that do not depend on the same strong method as everyone else. Use password hash synchronisation as a fallback in hybrid setups. Avoid policies that depend on a single network location or a single service that, if unavailable, would lock everyone out. Know the contact route and status page for service incidents, and rehearse your recovery steps.
Resilience habits
- Two tested emergency access accounts
- Report-only mode before enforcing new policies
- Documented recovery steps for sign-in failures
- Backup of policy configuration as code
Common weak spots
- Policies that exclude nobody, including administrators
- Single synchronisation server with no plan
- Expired secrets and certificates
18Design Patterns and Anti-patterns
Shapes that scale, and shortcuts that hurt later.
Patterns worth adopting
Zero trust: verify explicitly
Treat every request as untrusted until identity, device and risk have been checked, regardless of network location.
Least privilege with time limits
Grant the smallest role needed, at the narrowest scope, for the shortest time, using eligible assignments.
Group-based access
Assign applications, licences and roles to groups driven by attributes, never by individual favours.
Passwordless first
Move users towards passkeys and security keys, starting with administrators and the most targeted staff.
Keyless workloads
Use managed identities and federation for every workload that supports them.
Policy as code
Keep conditional access and configuration definitions in version control with review, so changes are tracked and reproducible.
Anti-patterns to avoid
Problem
Many people hold permanent Global Administrator rights for convenience.
Why It’s Harmful
Each such account is a master key. One phished or reused password hands an attacker the whole tenant, and activity cannot easily be traced to a justified need.
Correct Approach
Keep very few permanent top-level roles, use narrower roles at limited scope and make everything else eligible through PIM with approval and logging.
Problem
Long-lived client secrets are shared across applications and stored in code repositories.
Why It’s Harmful
Secrets leak through source control, logs and chat. They expire without warning and cannot be traced to one workload.
Correct Approach
Use managed identities or workload identity federation, and where secrets are unavoidable, store them in a vault with short lifetimes and expiry alerts.
Problem
Conditional access policies are enforced immediately without testing and without emergency accounts.
Why It’s Harmful
A single mistake can lock out all administrators and stop the business until Microsoft support helps recover access.
Correct Approach
Preview in report-only mode, exclude monitored emergency accounts, roll out in stages and review the sign-in impact before widening scope.
Problem
Anyone may consent to any application, and guests are invited without expiry.
Why It’s Harmful
Malicious applications gain access to data through user approval alone, and former partners keep access forever.
Correct Approach
Limit user consent to low-risk permissions from verified publishers, add an admin consent workflow and run regular reviews of applications and guests.
19Best Practices and Common Mistakes
Habits that separate calm identity operations from constant firefighting.
Best practices
- Require multi-factor authentication for everyone. Start with administrators, then expand to all users and all applications.
- Move towards phishing-resistant methods. Passkeys and security keys for privileged and high-risk users first.
- Keep two emergency access accounts. Exclude them from policies, secure them heavily and alert on any use.
- Use groups and dynamic rules. Let attributes drive access so changes of role are handled automatically.
- Make admin access just-in-time. Use PIM and separate admin accounts.
- Prefer keyless workloads. Managed identities and federation over secrets and certificates.
- Test before enforcing. Use report-only mode and pilot groups for every new policy.
- Send logs to your analysis platform. Retain them and alert on high-risk events.
- Review regularly. Access reviews for guests, privileged roles and sensitive applications, and clean up unused applications.
- Watch the retirements. Follow Microsoft’s announcements so you migrate before a deadline forces your hand.
Common mistakes
Trusting a corporate network as proof of safety. Attackers inside a network or using stolen credentials look identical to staff. Verify identity and device regardless of location.
Mixing up the two role systems. Giving someone an Azure resource role does not make them a directory administrator, and the reverse is also true. Review both.
Leaving legacy authentication enabled. Older protocols cannot perform multi-factor checks and are a favourite route for password-spray attacks. Block them with a policy once you have confirmed what still uses them.
Forgetting about service accounts and app registrations. Non-human identities often have broad access, no owner and no multi-factor protection. Give each an owner, minimise permissions and review them.
Relying on old documentation. Product names, scripting modules and interfaces have changed, and several older tools have been retired. Always confirm steps against the current official pages.
When a user cannot sign in, check in this order: Does the sign-in log show the failure reason? Which conditional access policy applied and what did it require? Is the account enabled and is the user assigned to the application? Is the device compliant if required? Is the credential or method registered and valid? Is a risk detection blocking access? The sign-in log answers most of these in one place.
20Real-world and Industry Examples
How different organisations put the doorman to work.
The following scenarios are typical patterns rather than descriptions of specific companies. They show how the same building blocks combine for very different needs.
Global company moving to a remote-first model
A company with offices in a dozen countries replaces its VPN-based trust with conditional access. Staff on managed laptops sign in with passkeys and reach applications from anywhere, while unmanaged devices receive limited, browser-only access. Sign-in logs flow into the security team’s monitoring platform.
Hospital with strict privacy obligations
A hospital uses dynamic groups tied to clinical roles, requires compliant devices for patient records and runs access reviews for staff who rotate between departments. Break-glass procedures give emergency access to clinicians, with every use audited.
Bank securing administrators
A bank removes permanent administrator rights. All privileged roles are eligible through PIM with approval and phishing-resistant authentication. Separate admin accounts and alerts on every activation give the auditors a complete trail.
Manufacturer with a legacy domain
A factory operator keeps its on-premises directory for plant systems and synchronises it to the cloud. Password hash synchronisation allows cloud sign-in even if the plant network is down, and application proxy publishes internal portals to remote engineers.
Consulting firm with many partners
A consulting firm invites clients as guests to project workspaces through access packages that expire when the project ends. Quarterly reviews remove stale guests, and cross-tenant settings trust the partners’ own multi-factor checks.
Software team running deployment pipelines
A development team replaces stored deployment secrets with federation between their build platform and Entra ID. Each pipeline gets a narrow role on one environment, nothing is stored in the repository, and expired-secret outages disappear.
Retailer with a customer portal
A retailer builds its loyalty portal on Entra External ID, offering social sign-in and email codes, while employees continue to use the workforce tenant. Customer and workforce identities are kept separate by design.
21Frequently Asked Questions
Quick answers to questions that come up again and again.
Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The service, features and data are the same, and only the name changed.
No. The on-premises directory uses protocols such as Kerberos and LDAP and manages domain computers. Entra ID is a cloud service using web protocols. Many organisations run both and synchronise them.
A tenant is your organisation’s dedicated, isolated instance of Entra ID, holding its users, groups, applications and policies.
The registration defines the application and lives where it is developed. The enterprise application, which is based on a service principal, is the instance in a tenant where you manage access and sign-in behaviour.
If you want policies that vary by user, device, location and risk, yes, and it needs a premium licence. Smaller tenants can start with security defaults, which provide a fixed baseline.
Prefer managed identities for code running in Azure and workload identity federation for code running elsewhere. Avoid stored secrets wherever you can.
Entra roles manage the directory and Microsoft 365 services. Azure roles manage Azure resources. They are separate systems and need separate review.
It replaces permanent powerful access with time-limited, justified and logged activation, shrinking the window in which a stolen account is dangerous.
For most organisations, password hash synchronisation is simplest and most resilient, and it is a good backup even if another method is chosen.
It stopped being sold to new customers in May 2025, with Entra External ID as the recommended successor. Existing customers continue under a stated support period with no major new features, and some premium capabilities were retired. Check official guidance for exact dates and migration steps.
Retention is limited and depends on your licence. For longer retention and analysis, send logs to a Log Analytics workspace or storage account through diagnostic settings.
Maintain tested emergency access accounts excluded from policies, preview every policy in report-only mode and roll changes out in stages.
22Summary and Key Takeaways
Microsoft Entra ID is the identity backbone of the Microsoft cloud, a global service that holds your tenant’s identities, verifies them when they sign in, issues tokens that applications trust and applies policies that decide who gets in and how. Around that core sit protection, governance, privileged access, external identity and workload identity capabilities that together form a complete identity strategy. The craft lies in the choices: strong and phishing-resistant authentication, conditional access tuned to real risk, least privilege with time limits, keyless workloads, hybrid synchronisation that stays resilient, and logs that you actually watch. Keep an eye on product retirements and renames, because this area changes quickly.
Key Takeaways
- Azure AD is now Entra ID — the name changed in 2023 while the service stayed the same, and it is different from on-premises Active Directory.
- The tenant is the boundary — users, groups, applications, policies and roles all live inside it, and Azure subscriptions trust one tenant for identity.
- Sign-in is a token exchange — applications redirect to Entra, receive signed tokens and validate them; never build your own sign-in or token checks.
- Conditional access decides, with context — combine user, application, device, location and risk to allow, challenge or block, and always keep emergency accounts and use report-only mode.
- Move beyond passwords — register strong methods for everyone and use passkeys and security keys for administrators and other high-value accounts.
- Machines need identities too — prefer managed identities and workload identity federation over client secrets, and keep least privilege on every role.
- Govern and observe continuously — use PIM, access reviews and lifecycle automation, send logs to an analysis platform, and track retirements such as B2C, custom controls and legacy interfaces.