Azure AD Conditional Access Policy Design: MFA Enforcement, Compliant Device Requirements, and Report-Only Testing
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The first Conditional Access deployment at a 500-person company took 20 minutes to implement and 4 hours to recover from. The MFA requirement policy was enabled for all users including the Global Admin accounts, the admin who made the change did not yet have MFA registered on their phone, and the policy applied to the Azure portal itself. Within minutes of enabling the policy, the Azure portal required MFA for every admin sign-in, including the admin trying to disable the policy to fix the mistake. No break-glass accounts existed. The recovery required a Microsoft support case and identity verification call.
The lesson is structural, not operational: Conditional Access policy changes need break-glass accounts excluded from every policy before the first blocking policy is enabled. This is not a recommended practice; it is a prerequisite without which a single misconfiguration can lock an organization out of its own Azure AD tenant. Every other Conditional Access design decision is secondary to this one.
Policy design: phased deployment with report-only validation
Effective Conditional Access policy design follows a phased deployment model: create the policy in report-only mode, analyze the impact on sign-in logs for 48-72 hours, remediate applications and accounts that would be blocked by legitimate access, then enable the policy. Skipping report-only mode is the source of most Conditional Access operational incidents — policies that look correct in the configuration UI regularly produce unexpected blocking of service accounts, legacy applications, or shared mailboxes that were not considered during policy design.
Deploy the block legacy authentication policy before the require MFA policy to eliminate the password spray attack vector first
Enable the block legacy authentication Conditional Access policy before requiring MFA, because legacy authentication bypass allows password spray attacks to bypass MFA even after MFA is required for modern authentication sign-ins. Create a policy targeting all users, all cloud apps, with a condition for client apps selecting Exchange ActiveSync clients and Other clients (which covers IMAP, POP3, SMTP AUTH, and Basic Auth endpoints) and grant control set to Block. Test in report-only mode for 72 hours and review the sign-in log for legacy auth sign-ins — any device showing Other clients sign-ins during the report-only period will lose access when the policy is enabled. Common legacy auth sources: older Exchange clients (Outlook 2010 or earlier), Linux mail clients using IMAP, monitoring tools using SMTP AUTH for alerts, and mobile devices using ActiveSync. Migrate each to OAuth before enabling the block policy. After blocking legacy auth, enabling MFA via Conditional Access provides unbypassable MFA enforcement since all non-MFA-capable auth methods are already blocked.
Use Conditional Access authentication strength to require phishing-resistant MFA for privileged administrators
Configure Conditional Access authentication strength to require phishing-resistant MFA methods (FIDO2 security keys, Windows Hello for Business, or certificate-based authentication) for Global Administrator and other privileged role sign-ins, rather than accepting any MFA method including SMS and authenticator app push notifications. Create a Conditional Access policy targeting directory role members including Global Administrator, Exchange Administrator, Security Administrator, and Privileged Authentication Administrator. Set the grant control to Require authentication strength and select Phishing-resistant MFA from the dropdown. Users signing in to these privileged roles who have only SMS or push notification MFA registered will be blocked until they register a FIDO2 key or Windows Hello. SMS MFA and push notification MFA are vulnerable to real-time phishing and MFA fatigue attacks; phishing-resistant methods prevent these attack vectors by design. Roll this policy out to admins in report-only mode for 30 days while providing FIDO2 security keys to all administrators, then enable enforcement after all admins have registered a phishing-resistant method.
Operations: monitoring policy effectiveness and managing exceptions
Conditional Access policy operations involve two ongoing activities: monitoring the sign-in logs to verify policies are enforcing correctly and detecting blocked legitimate access, and managing exceptions through a documented process that prevents exception accumulation from hollowing out the policy coverage. Both activities require structured processes rather than ad-hoc responses to individual user complaints.
Create a Sentinel alert for sign-ins that bypass all Conditional Access policies from non-trusted networks
Build a Microsoft Sentinel analytics rule that alerts on sign-ins from non-trusted networks where no Conditional Access policy applied, indicating a coverage gap. Query the SigninLogs table: SigninLogs | where TimeGenerated > ago(1h) | where NetworkLocationDetails has 'trustedNamedLocation' == false | where ConditionalAccessStatus == 'notApplied' | where ResultType == 0 | summarize count() by UserPrincipalName, IPAddress, AppDisplayName. A successful sign-in from a non-trusted network where zero Conditional Access policies applied means the user account or application is excluded from all policies — either intentionally (service accounts) or accidentally (a recently created account that was not added to any policy group). Route these alerts to the security team for investigation, distinguishing between expected service account sign-ins and unexpected coverage gaps that require policy remediation.
Audit all Conditional Access policy exclusions quarterly and remove any exclusions where the original justification no longer applies
Conduct a structured quarterly audit of all Conditional Access policy exclusions by exporting the excluded users, groups, and named locations from every policy and reviewing each exclusion against its original justification. In Entra ID, export the policy configuration via the Microsoft Graph API: GET /identity/conditionalAccess/policies returns all policies including their excludeUsers and excludeGroups arrays. For each exclusion, verify that the original reason still applies: service account exclusions should be validated against active service accounts (decommissioned service accounts should be removed from exclusion groups and disabled), IP range exclusions should be validated against current network architecture (VPN ranges that changed or office IPs that are no longer used), and user exclusions for legacy application access should be verified against the application's deprecation status. An accumulated exclusion list where 20-30% of excluded entries have expired justifications is a common finding in Conditional Access audits and represents real security coverage gaps that have grown silently over time.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Azure AD Conditional Access is the highest-impact identity security control available in Microsoft cloud environments, but it requires careful deployment sequencing to avoid operational incidents. Create break-glass accounts excluded from all policies before enabling any blocking policy. Deploy the block legacy authentication policy first to eliminate password spray attack bypass of MFA. Use report-only mode for every new policy for at least 48 hours and review sign-in logs for false positive blocking before enabling. Configure MFA as the baseline grant control for all users and all apps, then layer compliant device enforcement for corporate resources and phishing-resistant MFA for privileged administrators. Monitor sign-in log coverage gaps with a Sentinel analytics rule alerting on successful sign-ins where no Conditional Access policy applied from non-trusted networks. Audit policy exclusions quarterly to prevent exception accumulation from eroding coverage.
Frequently asked questions
What are the essential Conditional Access policies every Microsoft 365 tenant should have?
The essential Conditional Access policies for a Microsoft 365 tenant, deployed in this order to minimize operational disruption: First, require MFA for all users for all cloud apps — this is the single highest-impact security control available in Azure AD, blocking over 99.9% of account compromise attacks according to Microsoft's data. Second, block legacy authentication protocols (Basic Auth, IMAP, POP3, SMTP AUTH) for all users — legacy auth bypasses MFA and is the primary attack vector for password spray attacks in Microsoft 365 environments. Third, require MFA for all administrators accessing the Azure portal, Microsoft Entra admin center, and Microsoft 365 admin center — add a condition for directory role targeting Global Administrator, Exchange Administrator, SharePoint Administrator and similar privileged roles with MFA required. Fourth, block risky sign-ins (High risk from Entra ID Protection) for all users. Fifth, require compliant or hybrid Azure AD joined device for access to corporate applications from non-compliant devices. Deploy each policy in report-only mode for at least 48 hours before enabling to verify it does not block legitimate traffic from service accounts, shared mailboxes, or legacy applications.
How do I configure break-glass emergency access accounts for Conditional Access?
Configure break-glass emergency access accounts by creating two cloud-only accounts with Global Administrator roles that are explicitly excluded from all Conditional Access policies and use password-only authentication without MFA dependency. Create the accounts in the Azure AD portal as cloud-only accounts (not synced from on-premises AD) with names like emergency-access-01@tenant.onmicrosoft.com using the onmicrosoft.com domain (accessible even if the custom domain has DNS issues). Assign Global Administrator roles to both accounts. Create a security group named Excluded-From-Conditional-Access containing only these two accounts and add this group to the Exclude section of every Conditional Access policy. Store the account passwords (25+ character randomly generated) in a physical safe — not a password manager, not a digital secrets vault that might be locked out of during the same incident that requires break-glass access. Configure a monitoring alert in Entra ID sign-in logs that fires any time either break-glass account is used: this usage is so rare that any sign-in warrants immediate investigation. Test break-glass access quarterly by signing in with the credentials from the physical safe to verify they still work before an emergency requires them.
How do I use report-only mode to test a Conditional Access policy before enforcing it?
Use report-only mode by setting the policy Enable policy toggle to Report-only when creating or modifying a Conditional Access policy. In report-only mode, the policy evaluates against every sign-in and logs what it would have done — Grant, Block, or Require MFA — in the sign-in logs without actually enforcing the decision. After enabling a policy in report-only mode, review the sign-in logs in the Azure portal: navigate to Entra ID > Sign-in logs > select a sign-in event > Conditional Access tab which shows each policy's report-only result. Filter the sign-in logs for the 48-hour report-only period to find events where the new policy would have applied Block or Require MFA to sign-ins that are currently succeeding without those controls. Identify the sources of those sign-ins: service accounts that lack MFA registration, legacy applications using Basic Auth, or Intune-unenrolled devices. Remediate each category before switching the policy to Enabled — service accounts need application-managed credentials, legacy applications need to be updated to modern auth, and device enrollment needs to be completed. A 48-72 hour report-only period with zero blocking false positives is the deployment readiness threshold before switching to Enabled.
How do I enforce compliant device access with Intune in Conditional Access?
Enforce compliant device access by creating a Conditional Access policy with the Require compliant device grant control and ensuring all devices that need access are enrolled in Intune with passing compliance policies. Create an Intune device compliance policy for each OS platform (Windows, macOS, iOS, Android) defining the compliance requirements: minimum OS version, encryption required, antivirus required (for Windows), firewall enabled, and no compromised (jailbroken/rooted) status. Configure the compliance policy to mark devices as not compliant after 1 day without check-in so that unmanaged devices lose compliance status quickly after being disconnected. In the Conditional Access policy, set the grant control to Require compliant device OR Require hybrid Azure AD joined device (the OR allows corporate-managed domain-joined Windows machines that may not be Intune-enrolled to continue accessing resources during a phased Intune rollout). Test the policy in report-only mode for 72 hours and review the sign-in log filter for Not compliant device results — each result represents a device that will lose access when the policy is enabled. Communicate the enforcement date to users and IT support with a self-service device enrollment guide at least 2 weeks before enabling.
How do I configure named locations for network-based Conditional Access conditions?
Configure named locations to use IP ranges or country-based conditions in Conditional Access policies. For IP-based named locations, navigate to Entra ID > Security > Named Locations > New IP ranges location and enter the CIDR ranges for your trusted networks: corporate office IP ranges, VPN egress IPs, and approved partner network IPs. Mark these as Trusted locations, which signals to Entra ID Protection that sign-ins from these IPs are lower risk. Create a Conditional Access policy using the named location as an Include or Exclude condition: a policy that requires MFA from all locations except trusted corporate IPs allows users on-premises to skip MFA while requiring it from all other networks. For country-based blocking, create a Named Location using the country/region selector and add it to a Conditional Access policy as Block for countries where you have no employees or legitimate users — if your organization operates only in the US and Canada, blocking all other countries reduces the attack surface for credential stuffing from overseas botnets. Test country blocking with a VPN before enabling, since VPN exit nodes in blocked countries can accidentally affect legitimate users.
How do I handle service accounts and legacy applications that cannot use MFA?
Handle service accounts and legacy applications that cannot use MFA by using workload identity Conditional Access policies, application-specific exclusions, or migrating to modern authentication rather than creating blanket exclusions that weaken the overall MFA coverage. For Microsoft 365 service accounts (used by monitoring tools, backup applications, and APIs): migrate them to use application permissions via OAuth 2.0 client credentials flow rather than user credentials, which eliminates the MFA requirement entirely since application credentials do not use user MFA. For legacy applications that cannot be updated to support modern authentication: create a named location for the server IP addresses those applications run from, and create a Conditional Access policy that excludes sign-ins from those specific IPs for those specific users only. Document every MFA exclusion in an exceptions register with the application name, owner, IP range, and next review date. For legacy SMTP AUTH: disable SMTP AUTH globally in Exchange Online (block legacy authentication Conditional Access policy) and configure each application that sends email to use Microsoft Graph API with OAuth rather than SMTP AUTH — this eliminates the protocol entirely rather than managing per-application exceptions.
How do I measure the security impact of my Conditional Access policies?
Measure Conditional Access security impact using the Microsoft Secure Score Conditional Access recommendations, sign-in log analysis, and the Identity Protection risky sign-ins report. In the Microsoft 365 admin center, view Microsoft Secure Score and filter recommendations by category Identity — each recommended Conditional Access policy shows a point value for the score improvement from implementing it, making it easy to prioritize which policies provide the most measurable security improvement. In Entra ID sign-in logs, run the report of all sign-ins in the past 30 days filtered by Conditional Access result: Failure shows sign-ins that were blocked by Conditional Access policies (the security controls are working), Interrupted shows sign-ins that were challenged with MFA and may have succeeded or failed, and Not applied shows sign-ins that matched no policies (coverage gaps). A large Not applied count indicates users or applications that are not covered by any Conditional Access policy — investigate each to determine if a policy exclusion was intentional or a gap. Track the ratio of accounts with MFA registered versus total accounts in the MFA registration report and target above 95% registration before enforcing MFA through Conditional Access to avoid a large number of users being blocked on day one.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.