Configuring Conditional Access for a Microsoft 365 Tenant: The Complete Policy Map

Why Policy Design Matters

Conditional Access is powerful but unforgiving. A misconfigured policy can lock out your entire tenant — including administrators. A policy that is too permissive provides no protection. This guide builds a baseline policy map that is defensible, recoverable, and covers the most common attack vectors against Microsoft 365 tenants.

Tested environment: Entra ID P1 and P2 tenants, Microsoft 365 Business Premium and E3/E5 licensing, April 2026.

Before deploying any CA policy: Create an emergency access account (break-glass account) that is excluded from all CA policies and stored in a physical safe. This is non-negotiable.

What I Check First

Before building policies, map the sign-in patterns that will be affected:

1. Identify emergency access accounts and confirm they are cloud-only, monitored, and excluded from every existing CA policy.
2. Export or review the last few weeks of sign-in logs for legacy authentication, service accounts, guest users, and admin sign-ins.
3. Confirm Intune compliance is already reliable before using compliant device requirements. A broken compliance policy will become a sign-in outage when CA enforces it.
4. List non-browser flows such as scan-to-email, PowerShell automation, Azure CLI, hybrid Exchange, and third-party backup products.
5. Decide how rollback will work before enforcement. The person enabling a policy should know which account can still sign in and which policy to disable first.

Prerequisites

Before deploying any of these policies, confirm:

• Emergency access accounts exist: At least two cloud-only Global Administrator accounts excluded from all CA policies, with credentials stored offline. If you do not have these, create them first.
• Entra ID P1 or P2 licensing: CA requires at least P1. The risk-based policies (Policy 5, Policy 6) require P2.
• MFA registration baseline: Ensure all users have completed MFA registration before enforcing MFA. Use the MFA registration campaign to drive adoption before switching any policy from Report-only to On.
• Service accounts identified: Applications using password-based authentication (shared mailboxes, MFP scan-to-email, legacy connectors) must be identified and handled before blocking legacy auth or requiring compliant devices.
• Intune compliance policies in place: Policy 2 (require compliant device) will immediately block users on non-compliant or unchecked-in devices. Run compliance reports first.

Report-Only Mode: Your Safety Net

Every policy in this guide should be deployed in Report-only mode first. Report-only lets CA evaluate and log the policy outcome without enforcing it. Use the sign-in logs to identify what would have been blocked before you switch to enforcement.

1. In Entra admin centre → Protection → Conditional Access, create the policy and set the Enable policy toggle to Report-only.
2. Wait 7–14 days and review Sign-in logs → Filter: CA Result = Report-only failure.
3. Investigate any failures — these are sign-ins that would be blocked when you switch to enforcement.
4. Only after resolving all unexpected failures should you switch the policy to On.

Policy 1: Require MFA for All Users

What it does: Requires multi-factor authentication for any sign-in to Microsoft 365 resources.

Configuration:

• Users: All users
• Cloud apps: All cloud apps
• Conditions: None (apply to all)
• Grant: Require multi-factor authentication

Exclusions: Emergency access accounts, service accounts using certificate-based authentication.

Deploy in Report-only mode first. Review the CA sign-in logs for 7–14 days before switching to enforcement.

Policy 2: Require Compliant or Hybrid-Joined Device

What it does: Blocks access from devices that are not Intune-compliant or hybrid-joined. This prevents BYOD access from unmanaged endpoints.

Configuration:

• Users: All users (excluding emergency access accounts and service accounts)
• Cloud apps: All cloud apps
• Conditions: None
• Grant: Require device to be marked as compliant OR require hybrid Azure AD joined device (choose based on your environment)

Warning: Before enabling, ensure all users have at least one compliant device. Use Report-only mode and review the affected sign-ins — devices that have not checked in recently will show as non-compliant.

Known issue: iOS and Android users accessing Microsoft 365 apps must have Intune Company Portal installed and enrolled. BYOD users accessing only web apps via a browser may be able to satisfy the policy with the browser-based compliant registration if Intune app protection policies are deployed.

Policy 3: Block Legacy Authentication

What it does: Blocks authentication protocols that do not support MFA (SMTP AUTH, IMAP, POP3, Basic Auth). Legacy auth is used in the majority of password spray attacks.

Configuration:

• Users: All users
• Cloud apps: All cloud apps
• Conditions: Client apps — select Exchange ActiveSync clients, Other clients
• Grant: Block access

Test first: Check your sign-in logs for any legitimate legacy auth usage (shared mailboxes, old MFP devices scanning to email, older applications). Migrate or exclude these before enabling.

Verification: After enabling, run this query in the Entra sign-in logs:

Filter: Client app = Exchange ActiveSync / Other clients
Filter: Status = Failure
Filter: Failure reason = Conditional Access policy 'Block legacy auth'

If you see unexpected legitimate services blocked, create an exclusion using a Named Location or a specific service account group.

Policy 4: Require MFA for Azure Management

What it does: Requires MFA specifically for Azure portal, Azure CLI, and PowerShell access to Azure management APIs.

Configuration:

• Users: All users
• Cloud apps: Microsoft Azure Management
• Conditions: None
• Grant: Require multi-factor authentication

This is separate from Policy 1 because it targets Azure administration specifically and should be applied before the all-users MFA policy is fully enforced.

Policy 5: Sign-in Risk Policy (Requires Entra ID P2)

What it does: Requires MFA step-up or blocks sign-in when Entra ID Identity Protection detects a risky sign-in (atypical travel, known malicious IP, leaked credentials).

Configuration:

• Users: All users
• Cloud apps: All cloud apps
• Conditions: Sign-in risk — High (block), Medium (require MFA)
• Grant: Block access (for High) / Require multi-factor authentication (for Medium)

Note: Blocking on High risk without an MFA-first fallback can permanently lock out legitimate users if Identity Protection misfires. Start with Require MFA for both Medium and High, then evaluate promotion to Block for High after reviewing false positives for 30 days.

Policy 6: Block High-Risk Users (Requires Entra ID P2)

What it does: Blocks sign-in entirely for users whose account shows high risk in Identity Protection — typically leaked credentials or confirmed account compromise.

Configuration:

• Users: All users
• Cloud apps: All cloud apps
• Conditions: User risk — High
• Grant: Block access

Remediation path: When a user is blocked, an admin must navigate to Entra admin centre → Identity Protection → Risky users, locate the user, investigate the risk detections, and either Confirm compromise (disable the account and investigate) or Dismiss user risk if the detection is a false positive.

Named Locations

Named Locations let you create IP range or country-based conditions for CA policies. Common uses:

• Trusted office IPs: Add your corporate egress IPs as a trusted Named Location, then exclude it from aggressive policies to reduce friction for on-network users.
• Country block list: Block sign-ins from countries you have no employees in. Useful as a defence-in-depth control against commodity credential attacks.

Create Named Locations at Entra admin centre → Protection → Conditional Access → Named locations.

Emergency Access Account Design

Your emergency access (break-glass) accounts must:

1. Be cloud-only accounts (not synced from on-premises AD)
2. Have Global Administrator role assigned directly (not via group)
3. Be excluded from all Conditional Access policies — check this exclusion every time you create a new policy
4. Use a long, randomly generated password (30+ characters) stored in a physical safe
5. Have no MFA device registered — or a FIDO2 hardware key stored with the credentials
6. Be monitored: Create a Diagnostic Setting alert or Sentinel rule that fires any time these accounts sign in

Validation: Reading Sign-in Logs

After any policy change, review the sign-in logs:

1. Navigate to Entra admin centre → Monitoring → Sign-in logs.
2. Filter by Date: Last 24 hours and Status: Failure.
3. Click any failed sign-in and expand Conditional Access to see which policy triggered and why.
4. For report-only policies, filter CA result = Report-only failure to see projected impact without enforcement.

What to Do If You Get Locked Out

If a CA policy blocks all administrator access:

1. Sign in using your emergency access account (which must be excluded from all CA policies).
2. Navigate to Entra admin centre → Conditional Access and set the offending policy to Off.
3. Investigate the cause before re-enabling with corrections.

If the emergency access accounts are also locked out (misconfiguration), you will need to open a Microsoft support case with proof of domain ownership — there is no self-service recovery path. This is why the break-glass accounts and their CA exclusion are non-negotiable.

Rollback Notes

Keep the first enforced version of each policy narrow enough that rollback is obvious. If a policy combines MFA, compliant device, location, client app, and risk conditions, troubleshooting becomes slow under pressure. Separate policies are easier to disable one at a time and easier to explain in the sign-in logs.

When moving from Report-only to On, change one policy at a time and watch sign-in logs for the affected group before enabling the next one. If users are blocked unexpectedly, set the policy back to Report-only, fix the assignment or exclusion, and re-test. Avoid fixing a live lockout by adding broad permanent exclusions that nobody revisits.

Known Limitations

• Service principals and workload identities: Standard CA policies do not apply to managed identities or service principals. Use Workload Identity policies (separate CA policy type) to enforce controls on those.
• Guest users: All-user policies apply to guests if not explicitly excluded. Guest users cannot register MFA through their home tenant — they use their home tenant's authentication. Plan guest-specific CA policies if you have significant B2B access.
• Legacy Exchange Online connectors: Some on-premises Exchange hybrid connectors authenticate with legacy protocols. Blocking legacy auth can break mail flow. Verify hybrid connector authentication before enforcing Policy 3.
• Report-only mode does not perfectly simulate enforcement: Some policy conditions (particularly compliance state) reflect real-time values that may differ between testing and enforcement periods.

Related Resources

• Entra ID P1 vs P2: Is the Upgrade Worth It?
• Intune Compliance Policy Not Evaluating
• Deploying Windows LAPS with Microsoft Intune
• Microsoft Conditional Access documentation
• Entra ID Identity Protection documentation