How do multiple Conditional Access policies interact?

All applicable policies are evaluated for every sign-in — there is no priority ordering or first-match behavior. If any policy blocks access, the sign-in is blocked regardless of other policies that might grant access. If multiple policies grant access with different controls, all controls must be satisfied (AND logic). For example, if one policy requires MFA and another requires a compliant device, the user must satisfy both. This means a single overly broad block policy can override all grant policies, so test carefully using report-only mode before enforcement.

What is report-only mode?

Report-only mode lets you evaluate the impact of a Conditional Access policy without enforcing it. Sign-in logs show what the policy would have done (grant, block, require MFA) without actually affecting the user. This is essential for testing new policies in production before enabling enforcement. Review the sign-in logs for several days to identify any unintended blocks or gaps before switching to on mode. You can have up to 20 policies in report-only mode simultaneously.

Conditional Access Policy Builder

IAM & SecurityAzure

Build Entra ID Conditional Access policies with MFA, risk, and session controls.

Last verified: May 2026

Conditional Access Policy Configuration

Display Name

State

Include Users (comma-separated)

Exclude Users (comma-separated)

Include Applications

Exclude Applications

Client App Types

browser mobileAppsAndDesktopClients exchangeActiveSync other

Grant Controls

Sign-in Frequency (optional)

Frequency Type

Persistent Browser

Generated Conditional Access Policy

Output will appear here...

About This Tool

Microsoft Entra ID Conditional Access policies are the decision engine for Zero Trust security, evaluating signals like user identity, device state, location, application, and real-time risk to decide whether to grant, block, or require additional verification for access requests. Policies combine conditions (who, what, where, device state, risk level) with access controls (block, grant with MFA, require compliant device, app protection policy, sign-in frequency). The Conditional Access Policy Builder helps you construct policies with the correct condition combinations and grant controls for common security scenarios.

Real-World Scenario

Your security team is rolling out Zero Trust principles. The builder helps draft 5 phased policies: (1) Block legacy auth for all users, (2) Require MFA for all admins (prioritized roles), (3) Require MFA for all users from outside corporate locations, (4) Require compliant device for high-risk apps (HR, Finance), (5) Block sign-ins from impossible-travel locations. Each deploys in report-only for 7 days first. After 6 weeks, all 5 are enforced. Sign-in incident rate drops 80%, and the security team has audit-grade documentation of access controls.

When to Use This Tool

•Building policies that require MFA for all users accessing Office 365 from outside the corporate network
•Creating risk-based policies that block sign-ins flagged as high risk and require MFA for medium-risk sign-ins
•Defining device-compliance policies that only allow access from Intune-enrolled devices for sensitive applications
•Configuring session controls that limit browser session duration and block persistent cookies for external users

Pro Tips

TIP

ALWAYS deploy new policies in report-only mode for at least 7 days before enforcing. The sign-in logs show what the policy WOULD have done — you'll find legitimate workflows that would have been blocked. Going straight to enforcement is the fastest way to lock out a critical user during a deploy or executive demo.

TIP

The 'block legacy authentication' policy is the highest-ROI policy to deploy first. Legacy auth (POP, IMAP, basic auth) bypasses MFA entirely and is the #1 attack vector for credential stuffing. Block it and you eliminate ~90% of automated attack noise immediately. Microsoft has been retiring legacy auth in stages — get ahead of it.

TIP

Always include emergency access ('break glass') accounts in the EXCLUDE filter of every block policy. Otherwise, a misconfigured Conditional Access policy can lock you out of your own tenant. Best practice: 2 break-glass accounts with very long passwords, MFA via FIDO2 keys stored in safes, monitored sign-in alerts, excluded from ALL policies.

How It Works Under the Hood

The builder constructs Conditional Access policy definitions with: assignments (users/groups, applications, conditions including platform/locations/client app/sign-in risk/user risk), access controls (block, grant with MFA/compliant device/hybrid Azure AD joined/approved client app/app protection policy/sign-in frequency/persistent browser), and state (enabled, disabled, report-only). Output is generated as az ad conditional-access policy commands and Microsoft Graph API JSON for automation.

Frequently Asked Questions

How do multiple Conditional Access policies interact?: All applicable policies are evaluated for every sign-in — there is no priority ordering or first-match behavior. If any policy blocks access, the sign-in is blocked regardless of other policies that might grant access. If multiple policies grant access with different controls, all controls must be satisfied (AND logic). For example, if one policy requires MFA and another requires a compliant device, the user must satisfy both. This means a single overly broad block policy can override all grant policies, so test carefully using report-only mode before enforcement.
What is report-only mode?: Report-only mode lets you evaluate the impact of a Conditional Access policy without enforcing it. Sign-in logs show what the policy would have done (grant, block, require MFA) without actually affecting the user. This is essential for testing new policies in production before enabling enforcement. Review the sign-in logs for several days to identify any unintended blocks or gaps before switching to on mode. You can have up to 20 policies in report-only mode simultaneously.

Related Learning Guides

Microsoft Entra ID (Azure AD)24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.