Entra Conditional Access: Policies and Rollout Guide

Microsoft Entra Conditional Access is the policy engine that decides whether a sign-in to Microsoft 365, Azure, or any connected app is allowed, challenged with MFA, limited, or blocked. The safest way to deploy it is in phases: exclude break-glass accounts, start every policy in report-only mode, block legacy authentication first, then enforce strong MFA for everyone and add risk-based controls last.

If you secure Azure or Microsoft 365 for a living, Conditional Access is where identity security actually happens. It is also one of the easiest places to lock an entire organization out of its own tenant. This guide walks through how Conditional Access works, the policies most organizations start with, and the mistakes that cause outages.

What is Conditional Access?

Conditional Access is Microsoft's Zero Trust policy engine for identity. Every time a user or app signs in to Microsoft Entra ID, Conditional Access evaluates signals such as who the user is, which app they want, what device they are on, where they are signing in from, and (with the right license) how risky the sign-in looks. It then applies an access decision.

Think of each policy as an if-then statement:

• If a user in Finance accesses the payroll app, then require MFA and a compliant device.
• If a user is not in Finance and accesses the payroll app, then block access.
• If user risk is high, then require MFA and a secure password change.

This is the practical version of the Zero Trust principle "never trust, always verify." If you want the broader architecture picture, read our Zero Trust in the cloud guide.

Licensing: what you need before you start

Conditional Access is a per-user licensed feature. According to Microsoft, any user governed by a Conditional Access policy needs a Microsoft Entra ID P1 license or higher. Risk-based policies, which use sign-in risk and user risk from Microsoft Entra ID Protection, require Microsoft Entra ID P2.

Tenants without P1 or P2 rely on security defaults, a baseline set of protections Microsoft enables for you. Security defaults and Conditional Access are not meant to be combined. Once you create Conditional Access policies, you cannot turn security defaults back on, so plan the switch deliberately.

Capability	Security defaults	Conditional Access (P1)	Conditional Access + ID Protection (P2)
Require MFA	Yes, tenant-wide	Yes, granular by user, app, and condition	Yes
Block legacy authentication	Yes	Yes	Yes
Location and device conditions	No	Yes	Yes
Report-only testing	No	Yes	Yes
Sign-in risk and user risk policies	No	No	Yes

The building blocks of a policy

Every Conditional Access policy has two halves: assignments (the "if") and access controls (the "then").

Assignments

• Users or workload identities: users, groups, directory roles, guests, and service principals to include or exclude.
• Target resources: cloud apps, user actions (such as registering security info), or authentication contexts.
• Conditions: device platform, named locations, client app type, device filters, and sign-in or user risk.

Grant controls

Grant controls decide what a user must satisfy to get in. Common options include:

• Require multifactor authentication or a specific authentication strength
• Require a device marked as compliant (through Intune)
• Require a Microsoft Entra hybrid joined device
• Require an approved client app or app protection policy
• Require a password change
• Block access

Session controls

Session controls shape what happens after sign-in: sign-in frequency, persistent browser sessions, app enforced restrictions, Conditional Access App Control, and continuous access evaluation.

One behavior trips up new admins: if no policy triggers an access control, the user gets a token by default. A policy that requires MFA for the Finance group does nothing to stop someone outside Finance. You need a second policy that blocks everyone else if that is your intent.

Before you build: three non-negotiables

1. Exclude emergency access accounts

Microsoft recommends excluding emergency access (break-glass) accounts from Conditional Access policies so a misconfiguration cannot lock out every administrator. Put these accounts in a dedicated security group and exclude that group from any policy that blocks or restricts sign-in. Protect the accounts themselves with strong, phishing-resistant credentials, monitor every sign-in, and test them on a schedule.

2. Handle service accounts properly

User-scoped policies do not block calls made by service principals. If scripts still use regular user accounts as "service accounts," replace them with managed identities, and use Conditional Access for workload identities where you need to govern service principals.

3. Use least privilege for policy admins

Creating and editing policies requires the Conditional Access Administrator role; reading them only needs Security Reader. Assign these roles just in time through Privileged Identity Management, and enable protected actions so changing a policy requires fresh MFA.

A phased rollout that avoids outages

Microsoft's own deployment guidance recommends a phased approach, with each policy running in report-only mode for at least a week before enforcement. Here is a practical version.

Phase 1: Foundation

1. Block legacy authentication. Older protocols cannot perform MFA, which makes them a favorite path for password spray attacks.
2. Secure MFA registration. Protect the security info registration page so an attacker with a stolen password cannot enroll their own MFA method.
3. Require phishing-resistant MFA for privileged roles. Target Global Administrator and other privileged Entra roles with an authentication strength such as FIDO2 security keys, passkeys, or Windows Hello for Business.

Phase 2: Core authentication

1. Require strong MFA for all users across all resources.
2. Require strong authentication for guests.
3. Require approved client apps or app protection on mobile devices.
4. Require MFA to join or register devices using the user action target.

Phase 3: Advanced protection

1. Restrict high-risk sign-ins and high-risk users (requires P2).
2. Restrict device code flow and block authentication transfer, both of which attackers abuse in phishing campaigns.
3. Enable token protection where supported to reduce token theft and replay.
4. Build policies for privileged access workstations once you have a PAW strategy.

Always verify three things before flipping any policy from report-only to on: break-glass accounts are excluded, a pilot group has tested it, and users have already registered the required authentication methods.

Test, monitor, and troubleshoot

• Report-only mode: the policy is evaluated on real sign-ins but not enforced. Open any event in the sign-in logs and check the Report-only tab to see what would have happened.
• Insights and Reporting workbook: stream sign-in logs to a Log Analytics workspace to see aggregate policy impact over time. This pairs naturally with Microsoft Sentinel; see our Sentinel setup guide.
• What If tool: simulate a sign-in for a specific user, app, location, and device to see which policies apply and why.
• Test your exclusions: an excluded user can still be prompted for MFA by a different policy. Test the combined result, not just a single policy.

If users report problems, collect the user principal name, time stamp, target app, client type, and correlation ID. The correlation ID is the fastest route to the exact sign-in event.

Common mistakes to avoid

• Combining "block" with "all resources" carelessly. This combination can lock out admins, and some critical endpoints cannot be excluded.
• One policy per app. Conditional Access has a limit of 240 policies per tenant, counting report-only and disabled policies. Group apps with the same requirements into a single policy.
• Listing individual users. Use groups, roles, and filters for applications instead. It scales better and keeps policies under size limits.
• No naming standard. Name policies with a sequence number, target apps, response, audience, and condition, for example CA01 - All apps - Require MFA - All users.
• No contingency plan. Keep disabled "ENABLE IN EMERGENCY" policies ready for scenarios such as an MFA provider outage.
• Clicking instead of coding. At scale, manage policies with the Microsoft Graph conditionalAccessPolicy API or Microsoft Graph PowerShell and keep them in source control, so every change is reviewable and reversible.

Why this skill matters for your career

Identity is the control plane of the cloud, and Conditional Access is where Azure security engineers prove they understand it. Interviewers routinely ask how you would roll out MFA without an outage, how you protect break-glass accounts, or why a user was prompted unexpectedly. Hands-on experience with report-only testing, sign-in log analysis, and policy-as-code is what separates candidates who have read about Zero Trust from those who have deployed it. It also maps directly to Microsoft's security certification track, which is changing; see our SC-500 transition guide.

In the PrimeSec program, you build and break Conditional Access policies in a real tenant, alongside AWS and GCP identity labs, so you can explain the tradeoffs with evidence. Explore the full curriculum to see where identity and Zero Trust fit into the 20-week path. For a broader Azure overview first, start with our Azure security fundamentals article. Microsoft's official Conditional Access deployment plan is also worth bookmarking.

Frequently asked questions

What license do I need for Microsoft Entra Conditional Access? Conditional Access requires Microsoft Entra ID P1 for every user governed by a policy. Risk-based policies that use sign-in risk or user risk from Microsoft Entra ID Protection require Microsoft Entra ID P2.

What is report-only mode in Conditional Access? Report-only mode evaluates a policy against real sign-ins without enforcing it. Results appear on the Report-only tab of each sign-in log entry, so you can see who would have been blocked or challenged before you turn the policy on.

Should emergency access accounts be excluded from Conditional Access? Yes. Microsoft recommends excluding break-glass accounts from policies that block or restrict sign-in so a misconfiguration cannot lock out every administrator. Place them in a dedicated group, use strong credentials, and monitor every sign-in.

Can I use security defaults and Conditional Access together? No. They are not meant to be combined. Creating Conditional Access policies prevents you from enabling security defaults, so plan to replicate and extend those protections with your own policies.

What Conditional Access policies should I create first? Start by blocking legacy authentication, securing MFA registration, and requiring phishing-resistant MFA for privileged roles. Then require strong MFA for all users and guests, and add risk-based and token protection policies last.

How many Conditional Access policies can a tenant have? Microsoft documents a limit of 240 policies per tenant, including policies that are on, off, or in report-only mode. Consolidate apps with the same requirements into shared policies to stay well under the limit.

Ready to build real identity security skills across Azure, AWS, and GCP? Enroll in PrimeSec Academy and start the hands-on path to becoming a Cloud and AI Platform Security Engineer.