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.

Illustrative environment (no execution evidence recorded): Entra ID P1 and P2 tenants, Microsoft 365 Business Premium and E3/E5 licensing, April 2026.

Before deploying a new CA policy: Validate at least two cloud-only emergency accounts with phishing-resistant credentials, permanent active emergency roles and exclusions from blocking Conditional Access. Exclusions do not bypass Microsoft mandatory MFA. See the emergency access design.

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: The documented emergency access accounts. Certificate-based user authentication is not a reason for a blanket exemption. Service principals are a separate workload-identity scenario, not user accounts to exclude from this policy.

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. A hybrid-join grant alone does not require Intune compliance. If the security requirement is a compliant device, configure that requirement explicitly. Devices meeting an OR alternative do not need to meet both controls.

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.

Platform scope: MAM/app protection does not make an unmanaged device compliant. Mobile compliance requires supported enrolment and the appropriate platform/browser authentication path. Design a separate app-protection access path where needed. Microsoft compliant-device policy guidance.

Policy 3: Block Legacy Authentication

What it does: Blocks legacy authentication flows that cannot satisfy MFA. SMTP AUTH, IMAP and POP can also use OAuth; the protocol name alone does not prove Basic authentication. Microsoft legacy-authentication policy.

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'

Investigate the client and authentication method before changing exclusions. Prefer a supported OAuth migration. Any temporary exception needs a narrow scope, owner, expiry and compensating controls; do not broadly exempt a trusted IP range.

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
• For a simple pilot: Sign-in risk — Medium and High; Grant — Require multifactor authentication
• If the approved design uses a different action for High risk, create a separate policy for that condition; one policy cannot branch between two grant actions by risk level

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 follow the documented remediation for the evidence found. Confirming compromise marks risk; it is not equivalent to disabling the account. Disable access, revoke sessions or require secure remediation as separate authorised actions when appropriate. Dismiss risk only after validating a false positive. Microsoft risk remediation.

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 phishing-resistant MFA credentials, such as FIDO2 keys or suitably configured certificate-based authentication, with dependencies distinct from normal administrators
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 managed identities: User CA policies do not protect service-principal calls. Workload-identity Conditional Access supports qualifying service principals, but does not cover managed identities. Microsoft workload-identity scope.
• Guest users: Evaluate the resource tenant’s policy and cross-tenant trust settings. Home-tenant MFA/device claims can be trusted when configured; otherwise additional resource-tenant requirements may apply. Microsoft cross-tenant 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

Correction Record

10 September 2026: Corrected emergency MFA, compliant-device versus app-protection claims, risk-policy branching, compromise remediation and guest/workload-identity scope. This is a documentation review, not a tenant test.