Conditional Access is Microsoft's policy engine for deciding whether a sign-in should be allowed, and Microsoft describes the policies as if-then statements: if a user wants to reach a resource, then they must satisfy something first.
It gathers signals about who is asking, from where, on what device and for which application, and returns one of two kinds of decision, block or grant with conditions attached.
That is how a zero trust intention turns into something that actually runs. It is also the one control in a Microsoft tenant capable of locking every administrator out at once, including the person who just saved the policy.
- Policies are if-then statements evaluated at sign-in
- Signals include the user, location, device, application and risk
- Decisions are block, or grant subject to requirements
- A policy with no exclusions can lock out every administrator
- Report-only mode shows the effect before anything is enforced
On this page
The engineThe engine, in Microsoft's own terms
Worth quoting the shape rather than paraphrasing it, because the simplicity is the point.
Microsoft describes Conditional Access as its Zero Trust policy engine, taking signals from various sources into account when enforcing policy decisions, and says that at their simplest the policies are if-then statements: if a user wants to access a resource, then they must complete an action. The example given is the ordinary one, that reaching Microsoft 365 requires multifactor authentication.
Older articles call the same engine Azure AD Conditional Access, from before Microsoft renamed Azure Active Directory to Microsoft Entra ID. Nothing about how the policies work changed with the name.
That framing of if-then statements is more useful than it looks. A policy is not a setting and not a permission. It is a conditional rule evaluated at sign-in, and everything difficult about the feature comes from the fact that many rules evaluate at once against one request.
SignalsThe signals it can see
These are the inputs to the if half. Microsoft lists the following as common signals.
| Signal | What it lets a policy say |
|---|---|
| User, group or agent | Target specific people or groups, rather than everybody |
| IP location information | Named address ranges, or whole countries and regions |
| Device | Platform, and state such as compliant or hybrid joined |
| Application | Different rules for different cloud or on-premises apps |
| Real-time and calculated risk | Signals from Entra ID Protection about risky users and sign-ins |
| Defender for Cloud Apps | Session-level monitoring and control in real time |
The device row is the one that changes an organization's posture most, because it is what makes the difference between requiring a second factor and requiring a managed machine. A password plus a code from any laptop in the world is a much weaker statement than the same thing from a device your management tooling says is compliant.
The risk row is the one people enable last and often want first: policies that react to a sign-in the platform already considers suspicious, rather than applying the same requirement to everybody all the time.
DecisionsThe decisions it can make
The then half is smaller than the if half, which is a useful thing to know before designing anything.
Block access is, in Microsoft's words, the most restrictive decision. There is nothing below it and nothing to negotiate.
Grant access is the less restrictive one, and it can be made conditional on one or more requirements. Microsoft lists requiring multifactor authentication, requiring an authentication strength, requiring the device to be marked as compliant, requiring a Microsoft Entra hybrid joined device, requiring an approved client app, and requiring an app protection policy.
Two things follow. First, most useful policy is grant with conditions rather than block, because blocking is a blunt instrument and the conditions are where the judgment lives. Second, requiring a compliant device and requiring multifactor authentication are different controls and combining them is materially stronger than either.
Policy anatomyHow a Conditional Access policy is built and evaluated
Microsoft's documentation describes every Conditional Access policy as two parts: assignments and access controls. The signals and decisions above are the contents. This is the container they go in.
Assignments define who, what and where. Users and groups, including directory roles and guest users, with both include and exclude lists. Target resources, meaning the cloud apps or user actions the policy covers. Network locations. Conditions such as sign-in risk, device platforms, client apps and a filter for devices.
Access controls define what happens. Grant controls either block or require something, and an administrator chooses whether users must satisfy all the selected controls or one of them. Session controls limit what users can do once inside, such as sign-in frequency, persistent browser sessions, or app enforced restrictions in Exchange Online and SharePoint Online.
Three evaluation rules from the same documentation explain most surprises.
- Policies do not have an order. Several policies can apply to one user at once, and all of them must be satisfied. If one requires MFA and another requires a compliant device, the user needs both.
- Block wins. If any applicable policy is configured to block, enforcement stops there.
- The password comes first. Microsoft states that policies are enforced after first-factor authentication is completed, so Conditional Access is not a defense against password guessing by itself.
On licensing, Microsoft's overview page says the feature requires Microsoft Entra ID P1 licenses, that Microsoft 365 Business Premium customers can also use it, and that risk-based policies require Microsoft Entra ID Protection, a P2 feature. Tenants without those get security defaults, compared further down.
The riskThe policy that locks everyone out
This is the failure mode that makes people afraid of the feature, and it is entirely avoidable.
A Conditional Access policy evaluates at sign-in, including the sign-in of the administrator who wrote the policy. A rule requiring a compliant device for all users, written by somebody on a machine that is not enrolled, takes effect and immediately excludes its author along with everybody else.
There is no undo from inside a tenant you can no longer sign in to.
The standard safeguard is break-glass accounts: a small number of cloud-only accounts, excluded from Conditional Access policies, with long random credentials stored somewhere physical, and alerting on any use at all. They exist for exactly one occasion and are otherwise never touched. Two is the usual number, so that one being unavailable is not the end of it.
The second safeguard is report-only mode, which evaluates a policy against real sign-ins and records what would have happened without applying it. Enabling a policy directly, without watching a week of report-only data, is how the surprises happen: the service account nobody remembered, the contractor on an unmanaged device, the conference room display that signs in as a user.
The third is scope. A policy targeted at a pilot group behaves the same as one targeted at everybody, and tells you the same things at a fraction of the risk.
Where to startA first set of policies, in the order that hurts least
Most tenants converge on a similar set, and Microsoft Entra Conditional Access offers template policies in the portal as a starting point. The order below is the one that puts the highest value and the lowest breakage first, and every step assumes report-only mode ran before it was enforced.
| Policy | Why it belongs here | What it breaks if rushed |
|---|---|---|
| Require MFA for administrators | The smallest group and the highest value target | Almost nothing, if break-glass is excluded first |
| Block legacy authentication protocols | They cannot present a second factor, so they bypass everything above | Old mail clients, scanners and line of business tools |
| Require MFA for all users | The single largest reduction in credential risk | Shared accounts and anything without a phone |
| Require a compliant device for sensitive apps | Turns the statement from who knows the password into which machine | Contractors, personal devices and anything unenrolled |
| Restrict by location, or react to risk | Narrower, and needs the earlier layers to be stable first | Travel, and anybody the risk engine misjudges |
The second row is the one people leave out and it undoes the first. A protocol that cannot present a second factor is a protocol that a policy requiring one cannot apply to, so an account reachable that way is reachable without the control you just deployed.
Finding what still uses it is the work, and it is the reason this row breaks more things than the rest.
The fourth row is where the real gain sits, and it is also where an organization discovers how many devices it does not manage. That discovery is worth having, and it is much cheaper in report-only mode than in a Monday morning.
PitfallsWhere people go wrong
Writing a policy for all users on the first day. All users includes the author, every service account and every guest. Pilot it, then widen it.
Skipping report-only mode. It costs a week and it is the only way to find what a policy would break before it breaks it.
Having no break-glass account, or one that is covered by policy. An excluded account that is not actually excluded is the same as not having one, and this is worth verifying rather than assuming.
Forgetting that accounts are not all people. Service accounts, shared mailboxes and device identities sign in too, and most cannot complete a second factor.
Treating it as a license-level feature and stopping. Turning on a default policy is a start. The value is in the device and risk conditions, which take design.
Assuming it protects on-premises applications automatically. It applies where identity flows through Entra ID. Anything authenticating another way is outside the policy, and that gap is where legacy protocols live.
ComparisonConditional Access, security defaults and Group Policy, side by side
| Criterion | Conditional Access | Security defaults | Group Policy |
|---|---|---|---|
| Where it applies | Any sign-in through Entra ID | Any sign-in through Entra ID | Domain joined Windows machines |
| Granularity | Per user, app, device, location, risk | One preset, on or off | Per organizational unit |
| Can require MFA | Yes, conditionally | Yes, for everyone | No |
| Sees the device state | Yes, if it is managed | No | It is the device |
| Needs a license | Yes | No | No, it comes with the domain |
| Fails toward | Whatever the policy says, including locked out | A working default | The last applied setting |
Three ways of imposing rules that get compared, usually by somebody deciding whether the licensed engine is needed at all. The bottom row is the honest summary.
Security defaults are a preset that cannot be misconfigured into an outage, which for a small tenant with no dedicated administrator is a genuine advantage over a policy engine that can. Group Policy is not an alternative to either; it configures machines that have already authenticated, and the two operate on different sides of the sign-in.
FAQFrequently asked questions
What is Conditional Access?
Microsoft's policy engine in Entra ID for deciding whether a given sign-in is allowed. Microsoft describes it as its Zero Trust policy engine, and the policies as if-then statements.
How does a Conditional Access policy work?
It evaluates signals about the request, the user, their location, the device, the application and any risk detected, and then either blocks access or grants it subject to requirements such as multifactor authentication.
What signals can Conditional Access use?
User, group or agent; IP location information including countries and regions; device platform and state; the application being accessed; real-time and calculated risk from Entra ID Protection; and Defender for Cloud Apps session signals.
What decisions can it make?
Block access, which Microsoft describes as the most restrictive, or grant access with one or more requirements attached, such as multifactor authentication, a compliant device or an approved client app.
Can Conditional Access lock me out?
Yes, and this is the main operational risk. A policy applying to all users applies to the administrator who wrote it, and there is no way to undo it from inside a tenant you cannot sign in to.
What is a break-glass account?
A cloud-only account excluded from Conditional Access policies, with long random credentials held somewhere physical and alerting on any use. Most organizations keep two, and they are used only in an emergency.
What is report-only mode?
A state where a policy is evaluated against real sign-ins and the result recorded, without being enforced. It is how you find what a policy would break before it breaks anything.
Is Conditional Access the same as MFA?
No. Multifactor authentication is one requirement a policy can impose. Conditional Access is the engine that decides when to impose it and on whom.
Does it work for on-premises applications?
Where authentication flows through Entra ID, yes. Applications authenticating another way are outside its reach, which is a common gap with older protocols.
Should every policy block, or grant with conditions?
Mostly grant with conditions. Blocking is the blunt end and is right for specific cases; the useful judgment usually lives in what a grant requires.
What about service accounts?
They sign in like anyone else and usually cannot complete a second factor. They need deliberate handling in policy design rather than being discovered by an outage.
Which condition improves security most?
Requiring a compliant or managed device, because it changes the statement from somebody who knows the password and has the phone to somebody on a machine you control.
Is Entra Conditional Access the same as Azure AD Conditional Access?
Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023, so Azure AD Conditional Access became Microsoft Entra Conditional Access. The policies, the licensing requirement and the portal location carried over. Older documentation and many admins still use the Azure AD name.
What is a Conditional Access break glass account?
A break glass account is an emergency administrator account that is excluded from every Conditional Access policy, so a misconfigured policy or an outage in multi-factor authentication cannot lock everyone out. Keep two, with long random passwords stored offline, and alert on every sign-in.
Keep readingRelated concepts
Read next · Identity and access What Is MFA? The requirement most policies impose, and the difference between a second factor and the engine deciding when to demand one. Open this next16 min- Identity and access · 13 min Zero Trust Explained The idea this implements, and why the position of a device on a network stopped being evidence of anything.
- Endpoint management · 13 min MDM Explained What makes a device compliant, which is the signal that turns a password-and-code policy into a managed-machine one.
- Cloud security · 12 min Cloud Security Architecture, and What the Providers Actually Publish The wider design that conditional access enforces one request at a time.
- Identity and access · 10 min IAM vs PAM, and What PAM Looks Like Without a PAM Suite IAM and PAM compared, and the order a small company should build identity controls in.
- Cloud and data security · 9 min Posture Management, and the Family of Tools Behind It The access controls a posture assessment repeatedly flags as too loose.
- Endpoint management · 9 min UEM vs MDM, and Where EMM Sits Between Them How managed-device state gates access to resources.