What Is Conditional Access? Microsoft Entra Conditional Access Explained

What Is Conditional Access? Microsoft Entra Conditional Access Explained

Originally published 4 October 2020 · Reviewed 5 November 2026

Conditional Access is how Microsoft Entra ID, formerly Azure Active Directory, decides whether a sign-in is allowed, and what must happen first. It is the main control point for zero trust access to Microsoft 365 and other applications. This article explains the idea, the building blocks and a safe way to start. If you already have policies, our Conditional Access review checklist is the next read.

The idea in one sentence

A Conditional Access policy is an if-then statement: if a user, in a given context, tries to reach an application, then require something or block them. For example, if an administrator signs in to the Azure portal, then require multifactor authentication. Policies are enforced after the first factor, the password or other primary method, has succeeded. Microsoft is clear that Conditional Access is not designed as a first line of defence against attacks such as denial of service, though it can use signals from them.

Signals

Signals are the conditions a policy looks at:

• Users, groups and roles. Include or exclude, for example, all users, administrator roles or guests.
• Target resources. Which applications or actions the sign-in is for.
• Device. Platform, and state such as compliant or hybrid joined.
• Location. Named locations or countries and regions, based on IP address.
• Client app. Browser, mobile app or legacy protocol.
• Sign-in and user risk. Detections from Microsoft Entra ID Protection, which needs P2.

Decisions

Each policy ends in a decision. The most restrictive is block access. Grant access can be conditional on one or more controls:

• require multifactor authentication, or a stronger authentication strength such as a phishing-resistant method;
• require the device to be marked compliant;
• require a Microsoft Entra hybrid joined device;
• require an approved client app or an app protection policy;
• require a password change for high user risk.

Session controls can also limit what happens after access is granted, such as sign-in frequency or restrictions in supported apps.

Policies most organisations need

Microsoft publishes templates for common cases. A sensible first set looks like this:

1. Require MFA for administrator roles.
2. Require MFA for all users, with documented exclusions.
3. Block legacy authentication, which cannot do MFA.
4. Require MFA to register security information, ideally from trusted conditions.
5. Require a compliant or hybrid joined device for sensitive applications.
6. Block or restrict access from countries where you have no users or business.
7. Respond to risk by requiring MFA or a password change, if you have P2.

Licensing

Microsoft's licensing page states that Conditional Access needs Microsoft Entra ID P1 licences. Microsoft 365 Business Premium customers also have access to Conditional Access features. Risk-based policies need Microsoft Entra ID Protection, which is a P2 feature. Microsoft also notes that if the licences expire, existing policies are not automatically disabled or deleted, which gives you time to migrate without a sudden change to your security. Free-tier tenants can use security defaults instead.

Rollout steps

1. Check what exists. Review current policies, security defaults, and legacy per-user MFA, because these interact.
2. Create emergency access accounts that are excluded from every policy, protected with a strong method, and monitored with alerts. Test them.
3. Build policies in report-only mode. This logs what would have happened without enforcing it.
4. Read the sign-in logs and use the What If tool to find users, apps and service accounts that would be affected.
5. Pilot with a group before enforcing for everyone.
6. Enforce, one policy at a time, and record every exclusion with an owner and a review date.
7. Review regularly, at least quarterly, and after any change to applications or devices.

Common mistakes

• Locking out the whole tenant. Always exclude and test emergency access accounts.
• Too many exclusions. Every exclusion is a gap. Prefer a separate, stricter policy for the exceptions.
• Forgetting legacy authentication and service accounts. Block legacy protocols and move services to workload identities.
• Overlapping policies without a plan. Policies are combined: the most restrictive requirements apply, so test combinations.
• Setting and forgetting. Policies drift as apps and teams change. Schedule a review.

A worked example

Suppose a small firm with Microsoft 365 Business Premium wants to protect its finance application. It creates a policy that targets the finance group and the finance application. The condition is any location except the office named location. The grant control is multifactor authentication on a compliant device. It runs the policy in report-only mode for two weeks, reads the sign-in logs, finds that one scanner account would fail, and moves that account to a separate, narrower policy. Then it enforces the finance policy for a pilot group, and finally for everyone in finance. Each step is small, reversible and recorded, which is the pattern to copy for every policy.

Where Conditional Access fits with other controls

Conditional Access is one control in a stack. Multifactor authentication supplies the proof, device management supplies the device state, Microsoft Entra ID Protection supplies the risk signal, and the sign-in logs supply the evidence. Conditional Access ties these together and enforces the outcome, so it is only as good as the signals feeding it. A policy that requires a compliant device is meaningless if no devices are enrolled, and a risk-based policy does nothing without P2. Build the foundations first, then add policies that rely on them.

Microsoft references

• Microsoft Entra Conditional Access overview, reviewed 5 November 2026.
• Microsoft Entra licensing, reviewed 5 November 2026.

This article was first published on 4 October 2020. It was rewritten on 5 November 2026 with current product names and licensing. Microsoft's live documentation takes precedence if it has changed.