Conditional Access Policies Every Business Should Consider in Microsoft 365

Introduction

Conditional Access is where identity security stops being theoretical in Microsoft 365. It is the policy engine inside Entra ID that evaluates every authentication attempt and decides, in real time, whether to grant access, block it, or require additional proof before letting someone through. If your organization uses Microsoft 365 in any meaningful capacity, this is the single most important security mechanism you control directly.

Most organizations fall into one of two camps. The first group has never touched Conditional Access at all. They are running on Security Defaults, the free baseline that Microsoft enables automatically, and they assume that is enough. The second group has a scattered collection of policies, often copied from blog posts or Microsoft templates, without a clear understanding of how those policies interact with each other or what gaps remain between them. Both positions create real exposure.

This guide covers the Conditional Access policies that matter most, explains why each one exists, and lays out the order you should implement them. It is not a click-by-click walkthrough of the Entra admin center. The portal interface changes frequently enough that step-by-step screenshots become stale within months. Instead, this is a consultative guide to help you understand the framework, make informed decisions about which policies fit your environment, and avoid the mistakes that lock people out or leave critical gaps open.

What Conditional Access Actually Does (and Does Not Do)

Before designing any policies, it helps to understand what Conditional Access actually is at a mechanical level. It is not a firewall. It is not MFA. It is not an access control list. Conditional Access is a decision engine that sits inside Entra ID and evaluates signals against rules every time a user authenticates to a cloud application.

The model works in three stages. First, the engine collects signals from the authentication attempt: who is the user, what role do they hold, what device are they signing in from, where are they geographically, what application are they trying to access, and what is the risk level of this particular sign-in. Second, the engine compares those signals against all active Conditional Access policies to find matches. A policy matches when all of its conditions are true for that specific authentication event. Third, the engine enforces the controls defined in the matching policy: grant access, block access, require MFA, require a compliant device, require an approved app, or limit the session.

This signal-to-decision-to-enforcement model is the foundation. Everything else builds on it.

One of the most important things to understand is how policy logic works. Within a single policy, conditions are evaluated using AND logic: a policy only matches when the user AND the application AND the location AND the device condition are all satisfied. But across multiple policies, the logic is OR: if any matching policy requires MFA, MFA is required, regardless of what other policies say. And if any matching policy blocks access, access is blocked, period. Block always wins.

This means you cannot create a "permissive" policy that overrides a blocking policy. There is no allow-list that exempts users from a block. If you need certain users exempt from a block, you must exclude them from the blocking policy itself. Misunderstanding this interaction model is one of the most common sources of lockouts and unexpected access denials.

Conditional Access also does not apply retroactively. It evaluates at sign-in time. If a user is already authenticated and their device falls out of compliance, the existing session continues until the token expires. Session lifetime controls and Continuous Access Evaluation (CAE) help address this, but the default behavior is sign-in-time enforcement.

Prerequisites: What You Need Before You Start

Conditional Access is not available in every Microsoft 365 tier. Before you start planning policies, confirm that your licensing and infrastructure meet the baseline requirements. Getting this wrong does not just cause configuration failures. It leads to policies that appear to be active but silently do nothing because the underlying license or data source is missing.

Entra ID P1 is the minimum license requirement. This is included in Microsoft 365 Business Premium, E3, E5, and A3/A5 education plans. It gives you access to the core Conditional Access engine, including user and group targeting, application targeting, location conditions, device platform conditions, client app conditions, and the standard grant controls (block, require MFA, require compliant device, require Hybrid Azure AD join). If you are on Microsoft 365 Business Basic, Business Standard, or E1, you do not have Conditional Access at all. Security Defaults is your only option in those tiers.

Entra ID P2 unlocks risk-based policies. P2 adds Identity Protection, which feeds sign-in risk and user risk signals into the Conditional Access engine. A "sign-in risk" policy can require MFA only when Microsoft detects something unusual about the authentication attempt, like a sign-in from an anonymous IP address or impossible travel between locations. A "user risk" policy can force a password change when Identity Protection determines the user's credentials are likely compromised. These are powerful policies, but they require P2. If you try to create risk-based conditions on a P1 license, the option simply will not appear in the policy editor.

You need at least one break-glass emergency access account, and it must be excluded from every Conditional Access policy you create. This is non-negotiable. A break-glass account is a cloud-only Global Administrator account that is not federated, not subject to MFA through Conditional Access, and not tied to any single person's phone or authenticator app. It exists solely to recover access to your tenant if every other admin account is locked out by a misconfigured policy, a compromised authenticator, or a service disruption. The credentials for this account should be stored in a physical safe or secure vault, never used for routine administration, and audited through sign-in logs to detect any unexpected use.

Configure named locations before building location-based policies. A named location is a defined set of IP address ranges or countries that you assign a label to in Entra ID. For example, you might define "Corporate Office" as the public IP range of your headquarters, or "Trusted Networks" as a set of VPN egress points. Any policy that uses location as a condition references these named locations. If you build a policy that says "Block access from untrusted locations" without first defining what trusted means, the policy either does nothing or blocks everyone.

Understand report-only mode before you enforce anything. Every Conditional Access policy can be set to one of three states: On, Off, or Report-only. Report-only mode evaluates the policy against every sign-in but does not enforce the controls. It just logs what would have happened. This is how you validate a policy before it touches real users. Skipping report-only mode is how teams cause outages. We will cover the full deployment methodology in a later section.

The Foundational Five: Policies Every Organization Should Have

There are dozens of possible Conditional Access configurations, but the following five policies cover the vast majority of the risk surface for most organizations. They are listed in the order you should implement them, because each one builds on or interacts with the previous ones.

Policy 1: Require MFA for All Users

This is the single highest-impact policy you can deploy. It requires every user to complete multi-factor authentication when signing in to any cloud application in your tenant. If you only implement one Conditional Access policy, this is the one.

The configuration targets all users and all cloud apps, with two critical exclusions: your break-glass account (or accounts) and any service accounts that cannot perform interactive MFA. The grant control should be set to "Require authentication strength" rather than the older "Require multifactor authentication" option, if your tenant supports it. Authentication strength policies let you specify which MFA methods are acceptable. For example, you can require phishing-resistant methods like FIDO2 keys or Windows Hello for Business, rather than allowing SMS or voice call as valid second factors.

This policy replaces what Security Defaults does for MFA, but with more control. Security Defaults requires MFA for all users but does not let you exclude service accounts, define trusted locations, or control which MFA methods are acceptable. Once you deploy this policy, you have the same coverage with significantly more flexibility.

The real-world risk without this policy is straightforward. Microsoft reports that accounts without MFA are more than 99% likely to be compromised in credential-based attacks. Password spray attacks test thousands of username/password combinations per hour against your tenant. A single compromised account with access to SharePoint, Teams, or Exchange Online can become a data exfiltration point or a launching pad for lateral movement. MFA stops the overwhelming majority of these attacks at the front door.

Watch out for service accounts and shared mailboxes during implementation. Service accounts that authenticate non-interactively, such as accounts used for SMTP relay, PowerShell automation, or third-party integrations, cannot complete an MFA prompt. These must be excluded from this policy and protected through other means, such as restricting their sign-in to specific IP addresses or using managed identities where possible. Shared mailboxes typically do not have sign-in enabled and are unaffected, but verify this in your environment.

Policy 2: Block Legacy Authentication

Legacy authentication protocols, including POP3, IMAP, SMTP AUTH, and older Exchange ActiveSync implementations, do not support modern authentication. That means they do not support MFA. An attacker who obtains a username and password can authenticate directly through a legacy protocol and bypass your MFA policy entirely. This is not a theoretical risk. It is one of the most commonly exploited paths in real-world Microsoft 365 breaches.

The policy targets all users and all cloud apps, with conditions set to match client apps classified as "Exchange ActiveSync clients" and "Other clients." These two categories capture all legacy protocol connections. The grant control is straightforward: block access. There are no exclusions for break-glass accounts here because the break-glass account should be using modern authentication through a web browser, not a legacy email client.

Before enabling this policy, you need to verify that nothing in your environment still relies on legacy authentication. Check the Entra sign-in logs, filter by client app, and look for any legitimate connections using legacy protocols. Common culprits include older multifunction printers that send email via SMTP AUTH, legacy line-of-business applications that use Basic authentication, older versions of Outlook that have not been updated to use modern auth, and third-party email clients on mobile devices that do not support OAuth.

If you find legitimate legacy auth usage, you have two options. The first is to migrate those systems to modern authentication before deploying the policy. The second is to create a targeted exclusion for the specific accounts or IP ranges involved, but this should be treated as a temporary concession with a firm deadline for migration. Every legacy auth connection is an open door that bypasses your MFA investment.

Policy 3: Require MFA for All Administrators

You already have MFA for all users from Policy 1. Why do administrators need their own policy? Because administrative accounts require stricter controls, and those controls need to survive even if Policy 1 is temporarily modified, scoped down, or accidentally changed.

This policy targets directory roles rather than user groups: Global Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator, User Administrator, Helpdesk Administrator, Billing Administrator, and any other privileged roles active in your tenant. The grant control requires MFA on every sign-in, with no exceptions for trusted locations. Administrators should always authenticate with MFA, even when sitting at their office desk, even when connecting through the corporate VPN. The elevated permissions associated with admin roles make them the highest-value targets in any tenant, and the damage from a compromised admin account is categorically different from a compromised standard user account.

A compromised Global Admin can disable every other Conditional Access policy, export all mailbox data, create backdoor accounts, and remove security controls across the entire tenant. The cost of requiring admins to complete MFA every time is trivially small compared to the risk of not doing so. If your administrators complain about MFA fatigue, deploy phishing-resistant methods like FIDO2 security keys or Windows Hello for Business. These methods are faster than typing a code and dramatically harder to phish.

One important detail: this policy should not include your break-glass account. The break-glass account typically holds the Global Administrator role, but it must be excluded from all Conditional Access policies, including this one. The break-glass account's security comes from its credentials being stored in a physical safe and its usage being monitored through sign-in log alerts, not from Conditional Access controls.

Policy 4: Block or Restrict Access from Untrusted Locations

Once MFA and legacy auth blocking are in place, the next layer is location-based control. This policy uses the named locations you configured in the prerequisites to define where access is expected and where it is not.

The simplest version of this policy blocks access entirely from outside your defined trusted locations for sensitive applications. Target all users (exclude break-glass accounts), scope to specific applications such as Exchange Online, SharePoint Online, and the Azure Management portal, set the condition to "All locations" excluding your named trusted locations, and set the grant control to block. This means users can only reach those applications from your corporate networks, VPN egress points, or any other IP ranges you have explicitly trusted.

The more nuanced version does not block but instead requires additional controls. Instead of blocking access from untrusted locations, you require MFA plus a compliant device, or you apply session controls that limit what users can do. This approach is more realistic for organizations with remote workers, traveling employees, or BYOD policies.

Be careful with country-level blocking. It is tempting to create a policy that blocks access from all countries except where your organization operates. This can work well for organizations with a stable geographic footprint, but it will break access for traveling employees and cause support tickets whenever someone tries to check email from an airport in a blocked country. If you implement country blocking, make sure your helpdesk knows the policy exists and has a process for temporary exceptions.

For high-security applications, particularly the Azure Management portal, location blocking is strongly recommended. There is rarely a legitimate reason for someone to manage Azure resources from an IP address that is not part of your infrastructure or a known administrative network. Restricting Azure Management to trusted locations adds a meaningful layer of protection against administrative account compromise.

Policy 5: Require Compliant or Hybrid Joined Device for Desktop Applications

This policy ties access to device posture. If your organization manages devices through Intune, you can require that the device be enrolled and compliant with your Intune compliance policies before it can access corporate resources through desktop applications.

Target all users (exclude break-glass accounts and service accounts), scope to all cloud apps or specific applications, set the condition to device platforms covering Windows and macOS at minimum, and set the grant control to require the device to be marked as compliant. A device is "compliant" in this context when it meets the conditions defined in your Intune compliance policies: encryption enabled, firewall on, antivirus running, OS version within acceptable range, and so on.

This policy is particularly effective for desktop applications because it ensures that corporate data accessed through Outlook, Teams, OneDrive sync, and other thick clients is only available on devices that your organization controls and monitors. It closes the gap where a user might install Outlook on a personal laptop, sync their mailbox, and create an unmanaged copy of corporate data on an uncontrolled device.

For mobile devices, the approach is different. Rather than requiring full device compliance (which means full device enrollment in Intune), most organizations use app protection policies combined with the "Require approved client app" or "Require app protection policy" grant controls. This allows employees to access email and files from their personal phones through approved apps like Outlook and OneDrive without requiring their personal device to be fully enrolled in your MDM. The data stays protected inside the managed app container, and the user's personal data stays private.

Advanced Policies Worth Considering

The foundational five cover the majority of the risk surface, but the following policies add meaningful protection for organizations that have the licensing, infrastructure, and operational maturity to manage them.

Risk-Based Policies (Entra P2 Required)

Identity Protection in Entra P2 feeds two additional signals into the Conditional Access engine: sign-in risk and user risk. Sign-in risk reflects whether the current authentication attempt looks suspicious, based on signals like anonymous IP addresses, impossible travel, malware-linked IP addresses, and unfamiliar sign-in properties. User risk reflects whether the user's credentials appear to be compromised, based on signals like leaked credential databases and anomalous activity patterns.

A risk-based sign-in policy might require MFA only when sign-in risk is medium or higher, allowing low-risk sign-ins to proceed without interruption. A risk-based user policy might require a password change and MFA when user risk is high. These policies are more surgical than blanket MFA requirements, which makes them useful for reducing MFA fatigue in environments where users authenticate frequently throughout the day.

The trade-off is that risk-based policies depend on Microsoft's risk detection models, which are statistical rather than deterministic. Occasionally a legitimate sign-in will be flagged as risky (false positive), or a malicious sign-in will not be detected (false negative). You should not rely solely on risk-based policies for MFA. Use them as an additional layer on top of your foundational policies.

Session Controls for Unmanaged Devices

Rather than blocking access entirely from unmanaged devices, you can use session controls to limit what users can do. The most common pattern is allowing browser-only access to Exchange Online and SharePoint Online from unmanaged devices, with restrictions on downloading attachments or syncing files. This is implemented through Conditional Access App Control, which integrates with Microsoft Defender for Cloud Apps to proxy the web session and enforce inline controls.

This approach works well for organizations that want to support some level of remote access from personal devices without allowing full offline data sync. An employee traveling without their corporate laptop can read and respond to email through the web but cannot download a 500-page contract to their personal desktop.

Require Approved Client Applications on Mobile

This policy ensures that mobile access to corporate resources happens only through Microsoft-approved applications that support app protection policies. Target mobile platforms (iOS, Android), require the "approved client app" grant control, and scope to Exchange Online and SharePoint Online at minimum. This prevents users from connecting through arbitrary email clients or file managers that your organization does not control.

Block Access from Specific Countries

If your organization has no operations in certain countries and you see no legitimate sign-in traffic from those regions, blocking access is a reasonable control. Review your sign-in logs to identify countries where you have zero legitimate activity, create a named location for those countries, and create a policy that blocks all sign-ins from that location. This reduces your attack surface from credential-based attacks originating in those regions.

Require Terms of Use Acceptance

For compliance-driven environments, Conditional Access can require users to accept a Terms of Use document before accessing applications. This is not a technical security control, but it serves a legal and regulatory purpose. The user must accept the terms during sign-in, and the acceptance is logged with a timestamp. This is commonly used for guest access, BYOD enrollment, and regulatory compliance scenarios.

How to Deploy Without Locking Anyone Out

The most common Conditional Access failure is not a policy that is too weak. It is a policy that is too aggressive, deployed too quickly, and takes down access for part or all of the organization. The deployment methodology matters as much as the policy design.

Every Conditional Access policy should go through the same lifecycle: design, report-only, validate, enforce for a pilot group, validate again, and then enforce broadly. Skipping any of these stages increases the risk of an outage. The following phases apply to each policy individually. Do not batch multiple policies into a single enforcement event.

Phase 1: Report-only mode. Enable the policy in report-only state and let it evaluate real sign-in traffic for one to two weeks. During this period, every sign-in that matches the policy is logged with the outcome that would have occurred, but no access is actually blocked or challenged. This gives you a complete picture of the policy's blast radius before anything changes for end users.

Phase 2: Validate with sign-in logs and the What If tool. After the report-only period, review the sign-in logs for entries where the policy would have required MFA, blocked access, or required a compliant device. Look specifically for service accounts, shared mailboxes, conference room accounts, third-party integrations, and any other non-standard authentication flows that might break. The What If tool in the Entra admin center lets you simulate a specific sign-in scenario and see which policies would apply. Use it to test edge cases: What if this service account signs in from this IP? What if a guest user accesses SharePoint from a mobile device?

Phase 3: Pilot enforcement. Switch the policy from report-only to enabled, but scope it initially to a small pilot group. Your IT team is the best candidate because they can troubleshoot their own issues and provide immediate feedback. Run the pilot for 48 to 72 hours. During this period, monitor the sign-in logs for blocked or failed sign-ins and collect feedback from the pilot group about unexpected MFA prompts, blocked applications, or degraded workflows.

Phase 4: Broad enforcement. Expand the policy to all targeted users. Monitor the sign-in logs actively for the first week. Have your helpdesk prepared for an increase in tickets, particularly for MFA enrollment, blocked devices, and confused users who do not understand why they are being prompted for additional verification. Communication before enforcement makes a significant difference. A short email explaining what is changing, why it matters, and what users should do if they have trouble reduces support volume substantially.

The entire process for one policy takes roughly three to four weeks. Resist the temptation to deploy all five foundational policies simultaneously. Stagger them. Deploy Policy 1 (MFA for all users), let it stabilize, then move to Policy 2 (block legacy auth), and so on. If something breaks, you want to know exactly which policy caused it.

Common Mistakes and How to Avoid Them

A related mistake is misunderstanding how policy logic works across multiple policies. Within a single policy, all conditions are AND: the policy only applies when every condition matches. Across policies, controls are OR: if any matching policy requires MFA, MFA is required. Block is absolute and overrides everything. Exclusions only work within the policy where they are defined. You cannot create a separate "allow" policy that overrides a block in another policy. If this logic is not clear to the person designing the policies, the result will be unexpected blocks, unexpected gaps, or both.

How Conditional Access Interacts with Security Defaults

Security Defaults is Microsoft's free baseline security configuration. It automatically requires MFA registration for all users, enforces MFA for administrators at every sign-in, challenges users with MFA when necessary (based on Microsoft's risk assessment), blocks legacy authentication, and protects privileged activities like Azure portal access. For organizations that do not have Entra P1 licensing, Security Defaults is the only option, and it is far better than nothing.

However, you cannot use Security Defaults and Conditional Access at the same time. When you create your first Conditional Access policy, Security Defaults must be disabled. This is not a technical limitation that can be worked around. The two systems are mutually exclusive by design.

The transition requires planning because disabling Security Defaults removes protections immediately. If you disable Security Defaults on Monday morning and do not have your Conditional Access policies ready until Wednesday, you have a two-day window where MFA is not enforced and legacy auth is not blocked. The correct approach is to build your Conditional Access policies in report-only mode while Security Defaults is still active, validate them, and then disable Security Defaults and enable your policies in a single coordinated change.

Specifically, here is what you lose when Security Defaults is disabled and what you must replace:

Notice that the risk-based MFA that Security Defaults provides requires Entra P2 to replicate in Conditional Access. If you have P1 but not P2, you lose that risk-based intelligence when you move to Conditional Access. Your MFA-for-all-users policy compensates by requiring MFA universally rather than risk-based, which is more aggressive but eliminates the gap.

Monitoring and Maintaining Your Policies

Deploying Conditional Access policies is not a one-time project. The policies need ongoing monitoring, periodic review, and adjustment as your organization's environment changes. New applications are onboarded. Users change roles. Network ranges shift. Compliance requirements evolve. A policy set that was appropriate six months ago may have gaps today if no one has reviewed it.

Sign-in logs are your primary monitoring tool. Every authentication event in your tenant is logged with the Conditional Access policies that were evaluated, whether each policy applied, and what controls were enforced. When a user reports an access problem, the sign-in log for that event will show you exactly which policy triggered the block or challenge. Filter the sign-in logs by "Conditional Access" status to find events where a policy was applied, and filter by "Failure" to find events where a user was blocked.

The Conditional Access insights workbook provides trend data over time. This workbook, available in the Entra admin center under Workbooks, requires that your sign-in logs are being sent to a Log Analytics workspace. If you have not configured diagnostic settings to export sign-in logs, the workbook will be empty. Configuring this export is worth doing even beyond Conditional Access, because it enables long-term analysis of sign-in patterns, failed authentication trends, and MFA adoption rates across your organization.

Review your policies quarterly. At minimum, once per quarter, walk through every active Conditional Access policy and verify that its scope, conditions, and controls are still appropriate. Check for policies that were created as temporary measures and never removed. Check for exclusions that were added for a specific migration and are no longer needed. Check for new administrative roles that should be covered by your admin MFA policy. Check for new applications that should be included in your location or compliance policies.

Document each policy's purpose. This is one of the simplest and most consistently neglected maintenance practices. Every Conditional Access policy should have a description that explains what it does, why it exists, who approved it, and when it was last reviewed. The display name alone is not sufficient. "Require MFA for all users" tells you the what but not the why or the context. A description like "Baseline MFA requirement for all users, approved by IT Security Jan 2026, excludes break-glass account BG-Admin01 and service account SVC-SMTP-Relay, reviewed quarterly" gives the next administrator everything they need to understand and maintain the policy without guessing.

Final Takeaways

Conditional Access is the highest-leverage security control available in Microsoft 365. It sits at the authentication layer, which means it intercepts threats before they reach your data, your applications, or your users' mailboxes. Five well-designed policies, deployed carefully and maintained over time, address the vast majority of identity-based attack vectors that organizations face today.

The framework matters more than the specific click paths. The Entra admin center will change its layout, rename options, and reorganize menus. The underlying model will not. Signals flow in, policies match, controls enforce. If you understand that model and apply it deliberately, you can adapt to any portal change, any new condition type, and any future control that Microsoft adds.

Start with MFA for all users and legacy auth blocking. Those two policies alone eliminate the most commonly exploited attack paths. Add administrative MFA, location controls, and device compliance as your organization's maturity and infrastructure allow. Deploy in report-only mode, validate thoroughly, and roll out one policy at a time.

If your organization needs help designing a Conditional Access framework that fits your specific environment, licensing, and risk profile, Cybernerds can help you get it right the first time.