Microsoft Entra ID Conditional Access: Complete Admin Guide to Deployment, Troubleshooting & 2026 Changes

Introduction

If you've spent any time managing a Microsoft 365 environment, you've probably heard the phrase "Zero Trust" more times than you can count. At the center of that model sits Conditional Access — the policy engine built into Microsoft Entra ID that decides who gets in, under what conditions, and what they need to prove first.

Here's the thing: understanding Conditional Access isn't optional anymore. Whether you're a seasoned IT admin or a helpdesk tech who just started fielding "I can't sign in" tickets, this is foundational stuff.

Every authentication attempt your users make passes through this engine. The policies you configure determine whether someone sails through to their inbox or hits a wall asking for MFA, a compliant device, or — in some cases — flat-out blocking them. The core principle is simple: never trust, always verify. Instead of assuming anyone on your corporate network is safe, Conditional Access evaluates signals like user identity, device health, location, app sensitivity, and real-time risk before making a call.

And there's an urgency here that goes beyond best practices. Microsoft is rolling out significant enforcement changes between March 27, 2026 and June 2026 that tighten how policies with resource exclusions behave. If your organization has policies excluding specific resources from Conditional Access requirements, those exclusions will be evaluated differently after the rollout. Admins who aren't prepared could face unexpected access blocks, a flood of helpdesk tickets, and some very frustrated users. So let's walk through everything you need to know — from foundational concepts to advanced troubleshooting — so you can handle Conditional Access with confidence.

How Conditional Access Works: The Signal-Decision-Enforcement Model

Conditional Access runs on a straightforward three-phase model: Signal, Decision, and Enforcement. Once you understand this flow, both policy creation and troubleshooting get a lot easier.

Signals

Signals are the contextual data points that Conditional Access evaluates during every authentication attempt. Think of them as the "inputs" the engine uses to make its decision:

• User or group membership — Who's signing in, and what groups or roles do they belong to? Policies can target specific users, groups, directory roles, or just everyone.
• Application — Which cloud app is the user trying to reach? You can target individual apps (Exchange Online, SharePoint) or go broad with "all cloud apps."
• Device platform and state — What OS is the device running? Is it marked compliant in Intune? Is it hybrid Azure AD joined?
• Location — Where's the sign-in coming from? This is evaluated using named locations (IP ranges or countries) that you define.
• Sign-in risk and user risk — Entra ID Protection evaluates sign-in patterns in real time. An unusual location or impossible travel scenario raises the risk level.
• Client application — Is the user signing in through a modern auth client, a browser, a mobile app, or a legacy protocol like IMAP or SMTP?

Decisions

Based on those signals, the policy engine makes a decision. There are really only two primary outcomes: Block access or Grant access. When it decides to grant, additional requirements can be layered on:

• Require multi-factor authentication
• Require authentication strength (e.g., phishing-resistant MFA only)
• Require the device to be marked as compliant
• Require a hybrid Azure AD joined device
• Require an approved client app
• Require app protection policy
• Require password change (when user risk is detected)

You can combine these controls with either an AND (require all selected) or an OR (require any one) operator.

Enforcement

Enforcement happens at the point of authentication. When a user tries to sign in, the Entra ID token service collects all applicable Conditional Access policies, merges their requirements, and enforces the most restrictive combination. Here's a critical detail that trips people up: if any policy blocks access, the user is blocked — even if another policy would allow it. Block always wins. No exceptions.

Planning Your Conditional Access Deployment

Honestly, deploying Conditional Access without a plan is a recipe for lockouts, helpdesk chaos, and a lot of angry emails. Before you create a single policy, do your homework.

Inventory Your Applications and Users

Review which cloud applications are registered in your tenant. Check the Enterprise Applications blade in Entra ID to see what people are actually using. Identify which apps are business-critical and which ones are used by service accounts or automation — those often get overlooked and then break in surprising ways.

Define Security Requirements

Sit down with your security team (or, if you are the security team, sit down with yourself) and figure out the requirements. Which roles need MFA at all times? Should every user need MFA, or only when they're off the corporate network? Are there compliance mandates requiring device health checks? Write these down before you touch the portal.

Establish a Naming Convention

When you end up with dozens of policies — and you will — a consistent naming convention becomes a lifesaver. Here's a pattern that works well:

CA[Number]-[Target]-[Application]-[Action]-[Control]

Examples:
CA001-AllUsers-AllApps-RequireMFA
CA002-Admins-AllApps-RequireMFA-PhishingResistant
CA003-AllUsers-AllApps-BlockLegacyAuth
CA004-AllUsers-AllApps-RequireCompliantDevice
CA005-GuestUsers-AllApps-BlockUntrustedLocations

Start with Report-Only Mode

I can't stress this enough. Every new policy should be deployed in Report-Only mode first. This logs what the policy would do without actually enforcing anything. Let it run for several days (ideally a week or two) and review the sign-in logs before you flip the switch to On.

Policy State	Effect on Users	Logged in Sign-in Logs	When to Use
Off	No effect — completely inactive	Not evaluated or logged	Retired or under-development policies
Report-Only	No enforcement — users aren't blocked or prompted	Yes — shows what would have happened	Testing new policies, evaluating impact before enforcement
On	Fully enforced — users must satisfy all conditions	Yes — shows actual results	Policy is validated and ready for production

Essential Conditional Access Policies Every Organization Should Deploy

Microsoft provides policy templates in the Entra admin center organized into categories: Secure foundation, Zero Trust, Remote work, Protect administrator, and Emerging threats. They've also started auto-creating Microsoft-managed policies in tenants to provide baseline protection. You should definitely review those managed policies and customize or supplement them with your own. Here are the essentials.

Require MFA for All Users

This is the single most impactful security policy you can deploy. Full stop. It requires every user to complete multi-factor authentication for every sign-in to all cloud apps. Start in Report-Only mode and make sure you exclude your break glass accounts (more on those in a minute).

• Assignments: All users (exclude break glass accounts)
• Target resources: All cloud apps
• Grant: Require multi-factor authentication

Require MFA for Admin Roles

Even if you've already got MFA for everyone, create a separate policy targeting privileged directory roles — Global Administrator, Exchange Administrator, Security Administrator, and so on — that requires phishing-resistant authentication strength. This ensures admins can't fall back to weaker MFA methods like SMS codes.

• Assignments: Users in directory roles (Global Admin, Security Admin, Exchange Admin, etc.)
• Target resources: All cloud apps
• Grant: Require authentication strength — Phishing-resistant MFA

Block Legacy Authentication

Legacy authentication protocols (POP, IMAP, SMTP AUTH, older Exchange ActiveSync versions) don't support MFA. They're the number one vector for password spray attacks. Block them. No exceptions.

• Assignments: All users
• Conditions: Client apps — select "Exchange ActiveSync clients" and "Other clients"
• Grant: Block access

Require Compliant or Hybrid-Joined Devices

If your organization uses Microsoft Intune, requiring device compliance ensures only healthy, managed devices can access corporate resources. You can require the device to be marked compliant, hybrid Azure AD joined, or either one (using the OR operator). This is especially valuable for organizations with BYOD policies where you still want some level of device trust.

Block Access from Untrusted Locations

If your users should only access resources from known corporate locations or trusted countries, create a policy that blocks everything else. You'll need named locations configured first — I'll cover that next.

Require MFA for Device Enrollment

Don't let attackers enroll rogue devices. Require MFA when users enroll devices into Intune or register devices in Entra ID. Target the "Microsoft Intune Enrollment" and "Microsoft Device Registration Service" applications specifically.

Protect Privileged Actions

Require MFA or phishing-resistant authentication when users register security information (MFA methods, SSPR methods). This is a critical one — if an attacker compromises a password, you don't want them registering their own MFA methods. Target the user action "Register security information" under Cloud apps or actions.

Setting Up Named Locations and Trusted Networks

Named locations are one of those foundational building blocks that many admins set up once and then forget about (until something breaks). They let you define trusted corporate networks and geographic boundaries that your policies can reference.

IP-Based Named Locations

Navigate to Protection > Conditional Access > Named locations and create an IP ranges location. Enter your corporate public IP addresses or ranges using CIDR notation. A few limitations to keep in mind:

• Each named location supports a maximum of 2000 IP address ranges.
• The minimum CIDR subnet mask allowed is /8 — you can't go broader than that.
• IPv6 ranges are supported.
• You can mark an IP-based location as a trusted location, which is referenced by policies using the "All trusted locations" condition.

Country-Based Named Locations

You can also create locations based on countries or regions. Microsoft determines the country by resolving the sign-in's IP address. One gotcha: VPN users may appear to sign in from the VPN exit node's country, not where they're physically sitting.

VPN and Proxy Considerations

If your organization uses a proxy or VPN that modifies source IP addresses, configure your network infrastructure to pass the original client IP in the X-Forwarded-For (XFF) header. Entra ID can evaluate XFF headers for more accurate location detection, but this requires proper configuration on both the network side and in Entra ID's named location settings.

# PowerShell: List all named locations in your tenant
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessNamedLocation | Select-Object DisplayName, Id, @{N='Type';E={$_.AdditionalProperties.'@odata.type'}}

# Get details of a specific named location
Get-MgIdentityConditionalAccessNamedLocation -NamedLocationId "location-guid-here" | Format-List

Emergency Access (Break Glass) Accounts

Let me be blunt: if you don't have break glass accounts set up, stop reading and go create them. Right now. These emergency access accounts are the safety net that prevents you from being permanently locked out of your tenant. If a Conditional Access misconfiguration blocks all admin access, or if a federation service goes down, these accounts are your only way back in.

Requirements for Break Glass Accounts

• Create a minimum of two break glass accounts.
• They must be cloud-only — not synced from on-premises Active Directory.
• They must use the *.onmicrosoft.com domain, not a custom domain (custom domains depend on DNS, which could fail independently).
• Assign the Global Administrator role permanently (not through PIM).
• They must be excluded from all Conditional Access policies — every single one, no exceptions.
• Don't assign Microsoft 365 licenses to these accounts.
• Use FIDO2 security keys as the authentication method. This avoids dependency on phone networks or authenticator apps. Store the keys in separate, secure physical locations.

Naming Conventions

Avoid obvious names like [email protected] or [email protected]. An attacker who gets partial directory access will absolutely look for these. Use non-descriptive names that don't reveal the account's purpose — something like [email protected].

Monitoring and Documentation

Set up alerts that fire on every single sign-in to break glass accounts. These accounts should never be used during normal operations, so any sign-in is a significant security event. Use Azure Monitor or Microsoft Sentinel to create the alerts. Document the following in a secure, offline location (a physical safe, not a SharePoint document):

• The account UPNs
• Where the FIDO2 keys are physically stored
• The procedures for when and how to use these accounts
• Who is authorized to use them

# PowerShell: Create an alert rule for break glass sign-ins
# First, identify the break glass account Object IDs
$breakGlassUsers = @("object-id-of-bg1", "object-id-of-bg2")

# Query sign-in logs for these accounts (last 24 hours)
Connect-MgGraph -Scopes "AuditLog.Read.All"
$startDate = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "userId eq '$($breakGlassUsers[0])' and createdDateTime ge $startDate" |
    Select-Object UserPrincipalName, CreatedDateTime, Status, IpAddress, Location

Troubleshooting Conditional Access Issues

Troubleshooting Conditional Access is probably one of the most common tasks you'll handle as an IT admin or helpdesk tech. When a user calls and says "I can't sign in" or "I keep getting prompted for MFA," you need a systematic approach — not guesswork.

Using the What If Tool

The What If tool should be your first stop. Always. It simulates a sign-in scenario and tells you exactly which policies would apply and what the result would be.

Navigate to: Protection > Conditional Access > Policies > What If

1. Select or search for the user experiencing the issue.
2. Select the cloud app they're trying to access.
3. Optionally set conditions: IP address, device platform, device state, client app, sign-in risk, location.
4. Click What If.
5. Review the results — the tool shows policies that will apply and policies that will not apply, along with the reasons.

This tool is invaluable. It answers questions like "Why is this user being blocked?" and "What would happen if I enable this new policy?" Always test with What If before enabling anything.

Analyzing Sign-in Logs

For issues that have already happened, sign-in logs are your historical record. Navigate to Entra ID > Monitoring & health > Sign-in logs.

Use these filters to zero in on the relevant event:

• Username — Filter by the affected user's UPN
• Date — Narrow to the time window when the issue was reported
• Application (Resource) — Filter by the app the user was trying to access
• Status — Filter by Failure or Interrupted to find blocked sign-ins
• Conditional Access status — Filter by Success, Failure, or Not Applied
• Correlation ID — If the user got an error message with a correlation ID, search by that value to find the exact event

Once you find the sign-in event, click on it and go to the Conditional Access tab. This shows every policy that was evaluated, whether it was applied, and the outcome. Click any policy name to see which conditions matched and which grant controls were satisfied (or weren't).

Sign-in Diagnostic Tool

Microsoft also provides a built-in diagnostic tool accessible from the sign-in logs. When you're viewing a failed sign-in event, look for the Troubleshooting and support tab or the Diagnostic link. It analyzes the event and gives you a human-readable explanation of what went wrong and how to fix it. It's surprisingly helpful — don't overlook it.

Common Issues and Their Solutions

User blocked unexpectedly: Check the sign-in logs for the specific event. Look at the Conditional Access tab to identify which policy blocked them. Common culprits include a new policy turned on without Report-Only testing, a location change (user traveling or switching VPNs), or a device falling out of compliance.

MFA loops (prompted repeatedly): This one's frustrating for everyone. It usually happens when the application doesn't properly pass the MFA claim back to Entra ID, or when there's a conflict between multiple policies requiring different grant controls. Check if the user is on a client that supports modern authentication. Also verify that no policy has a zero sign-in frequency, which would force re-authentication on every single request.

Device compliance failures: The user's device may have fallen out of compliance in Intune. Check the Intune device compliance status. Common causes: expired compliance check-in, outdated OS version, disabled encryption, or a missing required app. Have the user open Company Portal and sync their device — that resolves it more often than you'd expect.

Legacy app failures: If you've blocked legacy authentication (and you absolutely should), older applications relying on POP3, IMAP, or basic SMTP authentication will stop working. The fix is migrating those apps to modern authentication. For apps that genuinely can't be migrated, you may need a narrowly scoped exception — but document it as a risk acceptance and revisit it regularly.

PowerShell Commands for Investigation

# Connect to Microsoft Graph with necessary permissions
Connect-MgGraph -Scopes "Policy.Read.All", "AuditLog.Read.All"

# List all Conditional Access policies with their states
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State, Id, CreatedDateTime, ModifiedDateTime |
    Sort-Object DisplayName |
    Format-Table -AutoSize

# Get details of a specific policy
$policy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "policy-guid"
$policy | ConvertTo-Json -Depth 10

# Find all policies that target a specific user or group
$allPolicies = Get-MgIdentityConditionalAccessPolicy
foreach ($pol in $allPolicies) {
    $includeUsers = $pol.Conditions.Users.IncludeUsers
    $includeGroups = $pol.Conditions.Users.IncludeGroups
    if ($includeUsers -contains "All" -or $includeUsers -contains "specific-user-id") {
        Write-Output "Policy: $($pol.DisplayName) | State: $($pol.State)"
    }
}

# Review sign-in logs for a specific user (last 7 days)
$userUpn = "[email protected]"
$startDate = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$userUpn' and createdDateTime ge $startDate" -Top 50 |
    Select-Object CreatedDateTime, AppDisplayName, Status, ConditionalAccessStatus, IpAddress |
    Format-Table -AutoSize

# Find sign-ins blocked by Conditional Access
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure' and createdDateTime ge $startDate" -Top 100 |
    Select-Object UserPrincipalName, AppDisplayName, CreatedDateTime, IpAddress |
    Format-Table -AutoSize

The 2026 Enforcement Changes: What You Need to Know

This is the section you should probably bookmark. Microsoft is rolling out a major change to how Conditional Access evaluates policies with resource exclusions. The rollout starts March 27, 2026 and phases through June 2026.

What Is Changing

Right now, when a Conditional Access policy targets "All cloud apps" but excludes specific resources, the exclusion behavior can create security gaps. For example, if you have a policy requiring MFA for all cloud apps but exclude a specific line-of-business application, that exclusion might inadvertently reduce security coverage in ways you don't immediately notice.

The improved enforcement tightens how these exclusions are evaluated. After the change, the policy engine applies stricter logic to ensure exclusions don't create unintended bypass paths. What this means in practice: some sign-in flows that previously succeeded without meeting a Conditional Access requirement may now get evaluated — and potentially blocked.

Rollout Timeline

• March 27, 2026: Initial rollout begins. Microsoft starts enabling the new enforcement logic in pilot rings.
• April–May 2026: Gradual rollout across production tenants in waves.
• June 2026: Full enforcement across all tenants.

What Administrators Should Do Now

1. Audit all policies with resource exclusions. Review every policy targeting "All cloud apps" that has excluded applications. Understand why each exclusion exists.
2. Test with the What If tool. Simulate sign-in scenarios for excluded applications to understand current behavior and predict how the new enforcement will affect those flows.
3. Deploy adjustments in Report-Only mode. If you need to change policies in response, run them in Report-Only first so you can observe the impact.
4. Monitor Microsoft 365 Message Center. Microsoft will provide tenant-specific guidance and timelines as your rollout date approaches.
5. Prepare your helpdesk. Brief your team on the changes so they can handle any spike in access-related tickets during and after the rollout.
6. Test in pilot rings. If your organization uses deployment rings, test the impact on a pilot group before enforcement hits your full production environment.

# Identify all policies with resource exclusions
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy
foreach ($pol in $policies) {
    $excludedApps = $pol.Conditions.Applications.ExcludeApplications
    if ($excludedApps -and $excludedApps.Count -gt 0) {
        Write-Output "Policy: $($pol.DisplayName)"
        Write-Output "  State: $($pol.State)"
        Write-Output "  Excluded Apps: $($excludedApps -join ', ')"
        Write-Output "  ---"
    }
}

Common Mistakes and How to Avoid Them

Conditional Access is powerful, and with that power comes the ability to cause some real damage if you're not careful. I've seen (and, honestly, made) most of these mistakes at some point. Here's what to watch out for.

Not Using Report-Only Mode First

This is the number one mistake, bar none. An admin creates a policy, sets it to On, and instantly locks out hundreds of users. Don't be that admin. Always deploy in Report-Only mode. Review the sign-in logs for at least a week. Look for unexpected blocks or failures. Only then switch to On — and do it during business hours when you can respond quickly if things go sideways.

Forgetting to Exclude Break Glass Accounts

Every Conditional Access policy that could block access needs to exclude your emergency access accounts. Forget even one policy, and you risk a scenario where a misconfiguration locks everyone out — including the accounts you need to fix it. Create a dedicated security group (e.g., "SG-BreakGlass-Exclusions") and exclude that group from every policy. It's much easier to audit a group exclusion than individual account exclusions.

Blocking Yourself as an Administrator

You deploy a policy requiring a compliant device for all cloud apps, but your own device isn't enrolled in Intune yet. Congratulations — you just locked yourself out of the Entra portal. To avoid this, always test policies with the What If tool using your own account before enabling them. Better yet, deploy device compliance policies to a pilot group first.

Misconfiguring Risk Levels and Causing MFA Fatigue

If you set a policy to require MFA whenever sign-in risk is "Low and above," your users will get prompted for MFA constantly — multiple times per day, sometimes multiple times in a single session. This creates MFA fatigue, where users become desensitized and are more likely to approve fraudulent requests (which rather defeats the purpose). Use "Medium and above" as your threshold for MFA prompts, and reserve "High" for blocking access or forcing password changes.

Not Monitoring Service Accounts

Service accounts — including the Entra Connect Sync account — can absolutely be affected by Conditional Access. If your sync account hits a policy requiring MFA or a compliant device, directory synchronization breaks. And that's a bad day for everyone. Identify all service accounts and either exclude them from problematic policies or make sure they can satisfy the requirements (managed identities or certificate-based authentication work well here).

Not Communicating Changes to End Users

Users need advance notice when new policies will affect their workflow. If you suddenly require MFA and nobody has registered their MFA methods yet, they won't be able to sign in — and your helpdesk phone will ring nonstop. Communicate changes at least two weeks out, provide clear instructions for MFA registration, and consider a phased rollout by department.

Not Having a Rollback Plan

Before enabling any policy, document how to disable or roll it back. Know which policy you're enabling, what its Report-Only behavior showed, and have a plan to switch it back to Report-Only or Off if things go wrong. Keep the Entra admin center open in another browser tab during the switch. You'll thank yourself later.

Helpdesk Preparation: Supporting End Users Through CA Policies

Let's be realistic — Conditional Access policy changes generate helpdesk tickets. That's just how it goes. The question is whether your helpdesk team is ready to handle them efficiently or whether every ticket gets escalated to Level 2.

Training Helpdesk Staff

Every helpdesk agent should understand the basics: what Conditional Access is, what common error messages look like, and where to check in the sign-in logs. They don't need the ability to modify policies, but they do need read access to sign-in logs and the ability to use the What If tool. Assign them the Reports Reader or Security Reader role in Entra ID.

Creating Runbooks

Build runbooks for the scenarios your helpdesk will encounter most:

• "I can't sign in" — Step 1: Ask for the exact error message and any error code or correlation ID. Step 2: Check sign-in logs for the user. Step 3: Look at the Conditional Access tab on the failed event. Step 4: Identify the blocking policy and the unmet condition. Step 5: Guide the user through resolution (register MFA, enroll device, use a supported app).
• "I keep getting asked for MFA" — Check the sign-in frequency setting on the applicable policy. Check if the user is in a private/incognito browser (which doesn't persist tokens). Check for legacy apps that re-authenticate on every request.
• "My device is not compliant" — Check Intune device status. Have the user open Company Portal and sync their device. If there's a compliance issue (outdated OS, encryption disabled), walk them through remediation.
• "I'm traveling and can't access anything" — Verify whether a location-based policy is blocking them. If it is, work with a security admin to determine the appropriate exception (temporary or otherwise).

Communicating Policy Changes

Develop a communication template for Conditional Access changes. Include:

• What's changing and when
• Who's affected
• What users need to do to prepare (register MFA, enroll their device, etc.)
• Where to get help if they run into issues
• A clear timeline with specific dates

Self-Service Options

Reduce your helpdesk load by enabling self-service capabilities wherever possible:

• Self-service password reset (SSPR) — So users can reset passwords without calling the helpdesk. This one alone can save a surprising number of tickets.
• Combined security info registration — Let users register MFA and SSPR methods from a single page at https://aka.ms/mysecurityinfo.
• Company Portal for device enrollment — Provide clear documentation so users can enroll their own devices in Intune.

Monitoring and Ongoing Management

Deploying Conditional Access isn't a one-and-done project. Policies need ongoing monitoring, review, and adjustment as your organization evolves. Set it and forget it is not a strategy here.

Conditional Access Insights Workbook

Microsoft provides a built-in Conditional Access insights and reporting workbook in the Entra admin center. This workbook aggregates sign-in data and shows the impact of your policies over time. Use it to identify:

• Report-Only policies that are ready to be enabled (or that would cause too many blocks)
• Trends in blocked sign-ins
• Users who are frequently failing Conditional Access requirements
• Applications generating the most CA failures

Sign-in Log Monitoring

Set up automated monitoring for sign-in failures caused by Conditional Access. If you use Microsoft Sentinel or another SIEM, create analytics rules to alert on spikes in CA failures — that could signal a misconfigured policy or an active attack.

// KQL query for Microsoft Sentinel — Conditional Access failures spike
SigninLogs
| where TimeGenerated > ago(1h)
| where ConditionalAccessStatus == "failure"
| summarize FailureCount = count() by bin(TimeGenerated, 5m), ConditionalAccessPolicies = tostring(ConditionalAccessPolicies)
| where FailureCount > 50
| order by TimeGenerated desc

// KQL query — Users blocked by Conditional Access in the last 24 hours
SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "failure"
| summarize BlockCount = count(),
    Apps = make_set(AppDisplayName),
    Locations = make_set(Location) by UserPrincipalName
| order by BlockCount desc
| take 20

Auditing Policy Changes

Every change to a Conditional Access policy is recorded in the Audit logs. Navigate to Entra ID > Monitoring & health > Audit logs and filter by the service "Conditional Access" to see when policies were created, modified, or deleted — and by whom. This is invaluable for change management and for figuring out what happened when a policy change causes unexpected issues.

# PowerShell: Review Conditional Access audit events
Connect-MgGraph -Scopes "AuditLog.Read.All"
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogDirectoryAudit -Filter "category eq 'Policy' and activityDisplayName eq 'Update conditional access policy' and activityDateTime ge $startDate" |
    Select-Object ActivityDisplayName, ActivityDateTime, InitiatedBy, TargetResources |
    Format-Table -AutoSize

Periodic Policy Reviews

Schedule quarterly reviews of all Conditional Access policies. During each review, go through this checklist:

1. Verify that break glass accounts are still excluded from all policies.
2. Check for policies stuck in Report-Only mode that should have been enabled or removed by now.
3. Review "All cloud apps" policies and verify that exclusions are still justified.
4. Confirm that service accounts aren't being inadvertently affected.
5. Validate that named locations are still accurate (office IP ranges change when leases renew or offices move — it's easy to forget).
6. Review Microsoft-managed policies for any updates or new policies auto-deployed to your tenant.

# PowerShell: Quick health check — policies missing break glass exclusions
Connect-MgGraph -Scopes "Policy.Read.All"
$breakGlassGroupId = "your-break-glass-group-id"

$policies = Get-MgIdentityConditionalAccessPolicy -Filter "state eq 'enabled'"
foreach ($pol in $policies) {
    $excludedGroups = $pol.Conditions.Users.ExcludeGroups
    if ($excludedGroups -notcontains $breakGlassGroupId) {
        Write-Warning "ALERT: Policy '$($pol.DisplayName)' does NOT exclude break glass group!"
    } else {
        Write-Output "OK: Policy '$($pol.DisplayName)' excludes break glass group."
    }
}

Conclusion

Conditional Access is the cornerstone of identity-driven security in Microsoft Entra ID. It transforms your identity provider from a simple gatekeeper into an intelligent, context-aware policy engine that lives and breathes Zero Trust. If you're working with Microsoft 365 or Azure services in any capacity, you need to understand how these policies work, how to deploy them safely, and how to troubleshoot them when users inevitably call for help.

Here are the key takeaways:

• Plan before you deploy. Inventory your apps, define your requirements, establish naming conventions, and always — always — start in Report-Only mode.
• Deploy the essentials. Require MFA for all users, enforce stronger authentication for admins, block legacy authentication, and require device compliance where you can.
• Protect yourself. Create and maintain break glass accounts, exclude them from every policy, and monitor their sign-ins like a hawk.
• Prepare for the 2026 enforcement changes. Audit your resource exclusions now, test with What If, and be ready for the rollout starting March 27, 2026.
• Equip your helpdesk. Train your team, build runbooks, communicate changes to end users early, and enable self-service wherever possible.
• Monitor continuously. Use the Insights workbook, sign-in logs, audit logs, and automated alerts to stay on top of policy health.

Conditional Access isn't a "set and forget" technology. It demands ongoing attention, regular reviews, and continuous alignment with your organization's security posture. Start with the fundamentals covered here, test rigorously, and build your policies incrementally. Your users' productivity and your organization's security both depend on getting this right.