Conditional Access Policies for Email: How to Secure Microsoft 365 Access Without Disrupting Approved Users

A stolen password reaches Exchange Online just as easily as a legitimate one unless something evaluates the sign-in itself. According to Mandiant's M-Trends 2026, stolen credentials accounted for 16% of cloud-related compromises investigated during 2025, ranking third behind voice phishing and third-party compromise. Conditional access policies for email close that gap by inspecting the identity and context behind every mailbox request.

The difficulty is rarely the policy screen. Microsoft 365 tenants carry a mixture of Outlook desktop, Outlook on the web, Outlook mobile, Apple Mail, Thunderbird, Exchange ActiveSync, POP, IMAP, and SMTP relay traffic, and each path responds differently to the same rule. A block that protects mailboxes from older authentication methods can also stop a warehouse scanner, a payroll job, or an invoice alert that nobody documented.

This guide covers:

• How conditional access policies for email evaluate users, devices, clients, locations, and risk before Exchange Online grants access;
• What licensing, inventory, and exception mapping administrators need before writing a single rule;
• How to build a baseline of focused policies spanning multifactor authentication, legacy protocols, device controls, risk, and administrator access;
• How to configure, test, and stage an Exchange Online policy through report-only mode and sign-in-log evidence;
• How Intune App Protection Policies extend conditional access policies for email to unmanaged mobile devices;
• How exceptions, shared mailboxes, and hybrid Exchange dependencies change the outcome of an otherwise correct policy;
• Where cybersecurity awareness training picks up the risk that identity enforcement cannot reach.

Misconfigured email access rules block approved workflows while leaving legacy protocols open to credential abuse. Adaptive Security detects and removes the phishing messages that reach inboxes after authentication succeeds.

Book a demo

What Are Conditional Access Policies for Email and How Do They Work?

Conditional access policies for email are identity-based rules that evaluate a sign-in or token request before granting access to Exchange Online and other Microsoft 365 resources. They assess signals such as the user, device, location, application, and sign-in risk, then allow access, require multifactor authentication (MFA), require a compliant device, or block the request outright. The distinction that governs every design decision is narrow but absolute: Conditional Access controls authentication and access decisions, while message content inside a mailbox stays outside its view.

What Is the Conditional Access Policy Model for Email?

A Conditional Access policy follows an if-then model. If a defined user attempts to access a defined resource under specific conditions, Microsoft Entra applies the policy's access controls. The model has five parts:

• Users and groups: Identifies who the policy covers, such as all employees, finance staff, administrators, guests, or a specific security group. Exclusions can protect emergency accounts, service accounts, and approved exceptions;
• Target resources: Identifies what the user is trying to reach. For email, this commonly means Exchange Online or the broader Microsoft 365 application grouping, though target resources can also include other cloud applications, user actions, and authentication contexts;
• Conditions: Defines the signals that activate the policy, including device platform, client application, network location, country or region, device state, and sign-in risk. A policy can apply only when a user accesses email from an unmanaged device, unfamiliar location, or legacy authentication client;
• Grant controls: Determines whether access is allowed and what the user must do first. Controls can block access, require MFA, require a compliant device, require an approved client app, or require a defined authentication strength;
• Session controls: Governs what happens after access is granted. Controls can limit the experience on an unmanaged device, shorten sign-in frequency, control browser persistence, or apply restrictions through integrated services.

This structure separates the trigger from the response. A condition identifies the situation, a grant control defines the access requirement, and a session control governs the experience after authentication.

How Does Exchange Online Resource Evaluation Work?

Exchange Online evaluation begins when a user or client requests a token for an email resource. Outlook on the web, Outlook desktop, mobile Outlook, and other applications act as clients, while the policy itself is evaluated against the resource the client is requesting.

The process follows a defined sequence:

1. 1Sign-in request: The user starts an authentication flow for Exchange Online or another Microsoft 365 resource.
2. 2Authentication: Microsoft Entra verifies the available authentication method, such as a password, passkey, or previously satisfied credential requirement.
3. 3Signal collection: Microsoft Entra gathers session details, including the user, target resource, device identity, client type, network location, and available risk signals.
4. 4Policy matching: The service identifies enabled policies whose users, target resources, and conditions match the request. Report-only policies provide visibility without enforcing access controls.
5. 5Grant enforcement: A matching block control stops access. Otherwise, Microsoft Entra prompts the user for required controls, such as MFA or a compliant device.
6. 6Session enforcement: After the grant requirements are satisfied, applicable session controls shape the email experience or determine how long the session remains valid.
7. 7Final decision: Access is allowed only when the applicable policy requirements are satisfied.

Conditional Access never reads a subject line, attachment, sender reputation, or message body to make its decision. It determines whether the identity and access context meet organizational policy, which means message inspection requires separate email security, data loss prevention, or mail-flow controls.

Conditional access policies for email reduce unauthorized access risk at the identity boundary, leaving content-focused controls to address cyber threats inside the mailbox.

How Do Multiple Conditional Access Policies Combine?

Multiple policies can apply to one request, and applicable policies generally combine rather than competing, so a user facing one MFA policy and one compliant-device policy must satisfy both.

Assignments within a single policy also work cumulatively. If a policy includes a user group, Exchange Online, an unmanaged-device condition, and an unfamiliar-location condition, every configured assignment must match before the policy triggers. Grant controls require closer review because administrators can configure them to require all selected controls or only one selected control.

Administrators should test exclusions, authentication dependencies, and overlapping policies in report-only mode before enforcement. The resulting decision path is direct: identify the user and email resource, evaluate conditions, apply matching policies, enforce grant and session controls, then allow or block access.

Identity controls decide who reaches a mailbox, yet they never judge whether a delivered message is safe. Adaptive Security analyzes inbound mail and removes confirmed cyberattacks automatically.

Explore the platform

What Do Organizations Need Before Creating Conditional Access Policies for Email?

Before creating conditional access policies for email, confirm licensing, administrative access, authentication methods, test accounts, device inventory, Exchange Online architecture, and business exceptions. Map every way employees and services connect to mail, from Outlook desktop through to SMTP relay devices, so the policy protects the intended users without disrupting critical workflows. Treat report-only testing and sign-in-log review as mandatory checkpoints.

According to IBM's Cost of a Data Breach Report 2026, the global average breach reached a record $4.99 million, which is the scale of exposure that identity groundwork is meant to reduce.

1. Confirm Licensing and Administrative Prerequisites

Verify that covered users have Microsoft Entra ID P1 or an eligible Microsoft 365 subscription. Microsoft documents Conditional Access as a P1 capability, while risk-based policies require Microsoft Entra ID P2. Intune device compliance and Microsoft Entra ID Protection introduce separate licensing requirements, so confirm the entitlement for every condition in the policy using the Microsoft Entra Conditional Access overview.

Assign policy creation to an administrator with the required permissions. Use a dedicated Conditional Access Administrator role in preference to a permanent Global Administrator assignment, and exclude at least one monitored emergency access account from policies that could lock out administrators.

Review authentication methods before applying an authentication strength requirement, and confirm that pilot users can complete the approved method. Document the help desk process for enrollment failures, lost devices, and account recovery so an authentication problem does not become an access outage.

Create a pilot group that reflects real work patterns, spanning finance, mobile, remote, executive assistant, and administrator roles on managed Windows and macOS devices. Add test accounts for shared mailbox access and approved service workflows, then review sign-in events in report-only mode before changing the policy to On.

2. Build the Identity, Device, and Mail-Flow Inventory

An email policy is only as reliable as the inventory behind its assignments. Export the users, groups, directory roles, guest accounts, service accounts, and emergency access accounts that could reach mail. Mark synchronized identities, guest accounts, and groups used for licensing or application access.

Document device ownership and management status across Windows, macOS, iOS, Android, and Linux. Record whether each device is Microsoft Entra joined, hybrid joined, registered, or managed through Microsoft Intune, then capture compliance state, operating-system version, browser, and primary mail client. The Microsoft Learn guide to Conditional Access conditions notes that device-platform signals are based on user-agent data and should be paired with compliance policies or carefully scoped block rules.

Map the mail clients and protocols present in the tenant:

• Outlook desktop, Outlook on the web, Outlook mobile, Apple Mail, and Thunderbird;
• Shared mailboxes, delegated access, and resource mailboxes;
• SMTP relay devices, including scanners, printers, applications, and monitoring systems;
• Hybrid mailboxes, on-premises Exchange servers, connectors, and synchronized identities.

This inventory exposes a common scoping error, which is the assumption that a policy targeting Exchange Online governs every mail path equally. Outlook on the web and modern Outlook clients generally provide modern authentication signals, while Apple Mail, Thunderbird, older Outlook versions, and SMTP relay workflows can behave differently. Test IMAP, POP, SMTP, and Exchange ActiveSync explicitly because legacy authentication paths can lack MFA and device-state support.

Use the Microsoft 365 integration guidance to document identity and application connections that affect policy scope, including Microsoft 365, HRIS, and directory workflows.

3. Define Protected Email Scenarios and Exceptions

Separate Exchange Online protection from broader Microsoft 365 targeting before assigning the policy. To control access to cloud-hosted mail, target Exchange Online as the cloud app and define the required client-app, device, user, and location conditions. If SharePoint, OneDrive, Teams, or other services also require controls, create separate policies or document the expanded scope, because a broad Microsoft 365 target can impose email controls when users access unrelated services.

Write each protected scenario as an if-then statement. For example, "If a finance user accesses Exchange Online from an unmanaged mobile device, require an approved client or block access." Specify whether the policy covers browser access, mobile and desktop clients, Exchange ActiveSync, or another client type, since Microsoft states that a new policy applies to all client app types when the client-app condition is not configured.

Document exceptions before enforcement, listing executives traveling to regions with restricted connectivity, contractors on approved personal devices, service accounts, shared mailbox operators, scanners, line-of-business applications, and hybrid users requiring a separate migration path. Assign every exception an owner, business justification, compensating control, and review date.

Use the What If tool, report-only results, and sign-in logs to test each client, device state, and exception. Enforce the policy only when expected users receive the intended challenge, legacy paths are blocked or migrated, and essential mail workflows continue without an undocumented bypass.

Incomplete inventories turn a well-intended access policy into an outage that finance, mobile, and relay workflows absorb first. Adaptive Security layers phishing detection over Microsoft 365 without mail-flow changes.

Book a demo

What Does a Baseline Set of Conditional Access Policies for Email Include?

A practical baseline for conditional access policies for email uses several focused rules in place of one oversized policy that is difficult to troubleshoot. Start in report-only mode, validate sign-in results, and enforce protections for authentication, legacy protocols, mobile devices, risky sign-ins, and administrative access. Treat Exchange Online as part of the wider Microsoft 365 dependency model, because email policies can affect Teams, SharePoint, calendars, files, and collaboration workflows in ways a single-resource test never surfaces.

1. Require MFA for All Users and All Microsoft 365 Resources

The baseline identity policy should cover every interactive user and all Microsoft 365 resources, formerly called all cloud apps. This prevents a stolen password from providing direct access to email or connected Microsoft 365 services. Microsoft Learn guidance for requiring MFA for all users recommends broad coverage with an authentication strength rather than a collection of app-by-app exceptions.

For a minimum baseline, select the built-in Multifactor authentication strength. It accepts a wider range of registered MFA methods and reduces deployment friction while the organization rolls out passkeys or security keys. For a mature configuration, use Phishing-resistant MFA strength with FIDO2 security keys, passkeys, or Windows Hello for Business, which suits finance staff, executives, help desk personnel, and anyone who can approve payments, reset credentials, or administer Microsoft 365.

The return on that control is unusually well documented. According to the Microsoft Digital Defense Report 2025, phishing-resistant MFA blocks more than 99% of identity-based cyberattacks even when the cyberattacker already holds a valid username and password.

Include all users and exclude only documented emergency access accounts. Avoid excluding service accounts and leaving them ungoverned, since service principals require separate workload identity controls, while automation should move toward managed identities or certificate-based authentication.

Set the policy to Report-only first and review sign-in logs for unsupported clients, authentication method gaps, guest access patterns, and applications that request tokens unexpectedly. After remediation, switch the policy to On in stages, beginning with IT and security teams.

2. Block Legacy Authentication Before Enforcing Device Controls

The legacy authentication policy removes protocols that cannot reliably satisfy modern access requirements. Include all users and target Exchange Online when the immediate goal is to block POP, IMAP, Exchange ActiveSync, MAPI, Exchange Web Services, and other basic authentication paths used to reach mailboxes. Under client app conditions, select Exchange ActiveSync clients and Other clients, then set the grant control to Block access.

Legacy clients cannot support MFA or supply the device state required for compliance decisions, which makes them the preferred route for high-volume credential abuse. According to the Microsoft Digital Defense Report 2025, more than 97% of identity-based cyberattacks are simple password spray or brute-force attempts. A Microsoft Learn reference on Conditional Access client app conditions identifies the affected paths, including older Exchange protocols, POP, IMAP, SMTP, MAPI, and Exchange Web Services.

Conditional Access should not be treated as the only SMTP AUTH control. Disable SMTP AUTH at the tenant or mailbox level where it is not required, and replace approved dependencies with OAuth-enabled applications, authenticated SMTP relay, or a managed service.

Start in report-only mode and inspect sign-in activity by client app, protocol, user, and source. The impact is immediate for users running old mail clients, third-party mobile apps, or devices that send mail through basic authentication, so give them a migration path to Outlook or updated applications before enforcement.

3. Require Compliant Devices or Approved Mobile Apps

The device policy controls access to email from phones, tablets, and unmanaged computers. Include mobile and desktop users who access corporate data, target Exchange Online for an email-focused rollout, and apply device compliance, approved client app, or app protection controls according to the organization's device management capability.

For managed endpoints, require the device to be marked compliant through Microsoft Intune or the supported device management system. Apply platform-specific conditions for iOS, Android, Windows, and macOS when their enrollment and compliance models differ. For personally owned mobile devices, require an approved client such as Outlook and an app protection policy instead of demanding full device enrollment, which protects corporate data without requiring ownership of the entire device.

Use Require device to be marked as compliant for enrolled devices, and Require approved client app with Require app protection policy for supported mobile scenarios. Exclude emergency access accounts and documented noninteractive workflows only when the exclusion has an owner and compensating control.

Begin in report-only mode and measure sign-ins that lack a device claim, use unsupported browsers, or come from apps that cannot receive app protection policies. Communicate the approved access path before enforcement so employees can stay productive without weakening the control.

4. Protect Risky Sign-Ins and High-Risk Users

Risk-based access adds context in preference to treating every login identically. Include all users or a high-value pilot group, target all Microsoft 365 resources, and use sign-in risk and user risk conditions when Microsoft Entra ID Protection is available. Require MFA for medium-risk sign-ins and block high-risk sign-ins after detection and remediation workflows have been validated.

The volume behind those detections is climbing. According to the Microsoft Digital Defense Report 2025, identity-based cyberattacks rose 32% during the first half of 2025, driven by credential leaks and infostealer malware that harvests passwords and session tokens at scale.

A mature configuration can require password change or secure account remediation for high user risk, while a minimum baseline starts with MFA for medium and high sign-in risk. Exclude emergency access accounts, and avoid broad exclusions for executives or remote workers. The policy should distinguish an unusual sign-in from a confirmed account compromise, because blocking every unfamiliar location creates disruption without improving control quality.

Use report-only mode to review risk detections, travel patterns, trusted network assumptions, and false positives. Pair enforcement with a clear help desk process and phishing-resistant methods for users who repeatedly trigger high-risk events.

5. Require Phishing-Resistant MFA for Administrators

Administrative access requires a separate policy because one compromised administrator can change mail flow, create forwarding rules, alter access controls, or weaken security policies across the tenant. Include built-in directory roles such as Global Administrator, Exchange Administrator, Security Administrator, Conditional Access Administrator, and Helpdesk Administrator. Target all resources and grant access only when the user satisfies Phishing-resistant MFA strength.

Speed is the reason that policy cannot wait. According to the CrowdStrike 2026 Global Threat Report, average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest observed intrusion moving in 27 seconds.

Microsoft's administrator authentication-strength guidance recommends registering required passkeys or security keys before enforcement. Exclude emergency access accounts, but test them regularly through a controlled recovery procedure, and use Privileged Identity Management where available so role activation triggers a strong authentication requirement.

Start in report-only mode, confirm that every administrator has a registered method, and check that delegated or custom administrative roles are covered by another control. The resulting security-key prompt during portal access and privileged role activation is intentional friction, because administrative actions carry a larger blast radius than ordinary mailbox access.

Baseline Policy Matrix for Conditional Access Policies for Email

The following matrix summarizes how the five baseline policies differ in scope, control, and expected disruption.

When Should Email Policies Target Exchange Online or All Microsoft 365 Apps?

Target Exchange Online when the control is specific to mailbox access, Exchange ActiveSync, legacy mail protocols, or mobile Outlook access. This narrower scope limits disruption while the organization modernizes mail clients or tests a new device policy.

Target all Microsoft 365 cloud applications when the policy protects an identity or data boundary in place of email alone. Teams can depend on Exchange for calendars and SharePoint for files, while Outlook and search can request access to related resources. Microsoft's Conditional Access cloud app guidance explains how the Microsoft 365 app grouping reduces inconsistent enforcement across connected services.

A minimum baseline contains all-user MFA, a legacy authentication block, and separate administrator protection. A mature configuration adds phishing-resistant authentication for sensitive roles, compliant-device or app-protection requirements, risk-based access, workload identity controls, named locations, and continuous report-only review. Keep every exclusion accountable, and use sign-in logs to prove that each policy protects the intended resource without disrupting the dependencies employees need.

Baseline policies stop credential replay at sign-in, though convincing payment requests still land in approved inboxes every week. Adaptive Security trains employees against the cyberattacks that survive authentication.

Take a self-guided tour

How Do Administrators Create a Conditional Access Policy for Exchange Online Email?

A Conditional Access policy for Exchange Online email defines who can connect, which client types are covered, and what access control applies before Microsoft grants access. In Microsoft Entra, create the policy, target Exchange Online, select modern email clients, require MFA, exclude only documented emergency identities, and validate the result in report-only mode before enforcement. Use current Microsoft interface labels, because Microsoft has renamed several cloud-app and client-app fields over time, and stale documentation is a frequent source of misconfiguration.

1. Open Conditional Access and Name the Policy

Sign in to the Microsoft Entra admin center with an account authorized to manage Conditional Access. Open Entra ID, select Protection, choose Conditional Access, select Policies, and click New policy.

Name the policy after its resource, control, scope, and rollout stage. A name such as EXO - Require MFA - Modern Clients - Pilot is more useful than Email Policy 1, because the name remains visible in sign-in logs, audit records, and troubleshooting workflows.

Define the intended result before configuring assignments: when an in-scope user accesses Exchange Online through a selected email client, require MFA before access is granted. That objective gives administrators a test criterion and prevents unrelated controls from accumulating in the policy.

Set Enable policy to Report-only during configuration and validation. Report-only mode records how the policy would evaluate sign-ins without enforcing the result, allowing administrators to identify unexpected users, applications, or client types before production activation.

2. Assign Users or Groups and Add Exclusions

Under Assignments, open Users or workload identities. Select Include, then choose All users for organization-wide email protection or Select users and groups for a pilot. A pilot is safer when the organization has older mobile devices, service accounts, or unusual mail workflows.

Select Exclude before continuing. Add at least two separately managed emergency access accounts that are monitored and protected through an independent process, and exclude only identities with a documented operational reason. Broad exclusions create bypass paths around the MFA requirement.

Review exclusions with the identity and messaging owners, confirm that the pilot includes browser, Outlook desktop, and mobile users rather than administrators alone, then record the group name, owner, membership rule, and review date.

Conditional Access evaluates group membership when a new token is issued, so a membership change does not automatically alter every active session. Include token and session behavior in the rollout plan so administrators know when a policy change should take effect.

3. Select Exchange Online as the Target Resource

Open Target resources, formerly labeled Cloud apps or actions in some Microsoft Entra interfaces. Under Select what this policy applies to, choose Cloud apps, select Include, choose Select apps, and search for Office 365 Exchange Online. In newer interface views, the resource can appear as Exchange Online; select only that resource, then click Done.

Avoid selecting All resources unless the intended result is to require MFA for every cloud application. A policy targeting Exchange Online should not unexpectedly change access to SharePoint, Teams, Azure, or third-party applications.

Microsoft combines assignments when evaluating a sign-in. The Microsoft Learn guide to Conditional Access policies documents the assignment and access-control model. Keep the target resource narrow enough that the policy's name, objective, and actual effect remain aligned.

4. Choose Browser, Mobile, and Desktop Client Conditions

Open Conditions, select Client apps, and set Configure to Yes. Choose the access paths the MFA policy must cover instead of relying on an ambiguous default.

For a modern Exchange Online email policy, select Browser, which covers Outlook on the web and other browser-based sign-in paths, and Mobile apps and desktop clients, which covers modern-authentication applications such as Outlook desktop and Outlook mobile. Both selections are required when the policy is intended to cover modern email access across browser, desktop, and mobile clients.

Review the legacy client choices separately. Select Exchange ActiveSync clients only when the policy is deliberately built to control EAS traffic, since EAS uses a legacy protocol and cannot satisfy MFA through the same modern interactive flow. Handle EAS with a dedicated policy assigned to specific users or groups, or migrate users to Outlook mobile and another supported modern-authentication client.

Select Other clients in a separate policy when the intended result is to block basic or legacy authentication protocols. This category includes IMAP, POP, SMTP, and older Exchange and Office connection methods, and selecting Browser and Mobile apps and desktop clients does not control those legacy paths. The Microsoft Learn documentation for Conditional Access conditions separates modern authentication clients, Exchange ActiveSync clients, and other clients because they behave differently during evaluation.

The table below maps each policy setting to a recommended value and the risk of getting it wrong.

5. Choose the Grant and Session Controls

Open Access controls, select Grant, choose Grant access, and select Require multifactor authentication. Leave Require all the selected controls selected when MFA is the only grant control.

Adding Require device to be marked as compliant means users must satisfy both MFA and device compliance. Selecting Require one of the selected controls would allow either control to satisfy the policy and would change the intended access decision.

For a direct Exchange Online MFA policy, avoid adding a device requirement unless Intune enrollment, compliance reporting, and support procedures are already operating. Restricting email to managed endpoints introduces a separate device-management dependency and requires a tested recovery process.

Open Session only when the policy requires behavior beyond MFA:

• Sign-in frequency determines how long a user remains authenticated before another sign-in is required;
• Persistent browser session determines whether a browser session remains active after the window closes;
• Application enforced restrictions can provide Exchange Online with device information so the service can offer a limited or full experience.

Document the business reason for each session control. Reauthentication settings affect user experience, support demand, and the organization's response when a device or identity changes.

6. Validate the Result, Document It, and Enable the Policy

Return to the policy summary and verify the complete evaluation path: included users, exclusions, Exchange Online, selected client apps, grant controls, and session settings. Save the policy in Report-only mode, then use Sign-in logs to filter for Conditional Access results.

Test representative paths deliberately:

• An included user signing in through a browser should show MFA as required;
• An included user signing in through modern Outlook desktop should show MFA as required when the token lacks a valid MFA claim;
• An included user signing in through Outlook mobile should produce the expected modern-client result;
• An excluded emergency access account should not trigger this policy;
• An EAS or basic-authentication test should be evaluated under the separate legacy-authentication policy in preference to being assumed covered by the modern-client rule.

Document the protected resource, user population, exclusions, client-app decisions, MFA method, test cases, expected sign-in-log results, owner, and rollback procedure. After the pilot passes, change Enable policy to On during a monitored window, then focus the first production review on failed sign-ins, help desk reports, mobile enrollment issues, and excluded-account activity.

That operational discipline matters because identity is where most incidents begin. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed incidents involve a human element, which places credential handling and access decisions at the center of email risk.

Building a policy is straightforward; proving employees can still spot a fraudulent invoice is harder. Adaptive Security measures that judgment through realistic phishing simulations tied to individual risk scores.

Take a self-guided tour

How Should Conditional Access Policies for Email Combine MFA, Device Compliance, Client Apps, and Locations?

Conditional access policies for email combine identity, device, application, and network signals to decide whether access should proceed. Multifactor authentication verifies the person, while device, client app, and location conditions evaluate the context around that person's request. MFA protects access from an unmanaged personal laptop, though it never proves that the device is patched, encrypted, or managed. Requiring a compliant or hybrid-joined device improves endpoint assurance on managed Windows systems, yet it cannot replace strong authentication when a cyberattacker has stolen a valid session or account credential.

The strongest policy design layers these controls according to risk, because no single signal proves that email access is safe.

How Should MFA Apply to Personal or Untrusted Devices?

MFA should be the default control when a user accesses email from a personal, unknown, or otherwise untrusted device. A typical policy targets Exchange Online, includes all users except carefully managed emergency accounts, and grants access only after multifactor authentication succeeds. The policy can cover browser access, desktop clients, and mobile applications, while legacy authentication must be blocked separately because older protocols cannot reliably support modern Conditional Access enforcement.

This pattern protects the account when the device cannot provide trustworthy compliance data. A personal Mac, unmanaged laptop, or unknown tablet can reach email after MFA succeeds, though the policy never confirms that the operating system is patched, encrypted, or managed.

Account takeover techniques also raise the required authentication standard. Adversary-in-the-middle cyberattacks, number-matching cyberattacks, and session-cookie theft can defeat poorly designed MFA workflows. Require a phishing-resistant method, such as a FIDO2 security key or certificate-based authentication, for administrators, finance staff handling payment instructions, executives, and users reaching sensitive email from outside the corporate network.

The financial stakes concentrate in exactly those roles. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, business email compromise accounted for $3.046 billion in losses across 24,768 incidents, averaging roughly $123,000 per case.

Keep a broader MFA policy for lower-risk users if operational constraints require it, and avoid letting a compliant device bypass strong authentication for sensitive roles. Device trust and identity assurance answer different questions.

Sign-in frequency controls how often users must authenticate again, while persistent browser sessions determine whether a browser remains signed in after it closes. Shorter frequencies suit privileged access, though aggressive settings create prompts that users learn to dismiss. Disable persistent sessions on shared computers and untrusted browsers.

When Can Compliant or Hybrid-Joined Devices Avoid an Extra Prompt?

Managed Windows devices can provide lower-friction access when Conditional Access trusts their state and identity. A policy requiring a device to be marked compliant evaluates signals reported by Microsoft Intune, such as encryption, minimum operating-system version, password requirements, and security configuration. A policy requiring a Microsoft Entra hybrid joined device verifies that the Windows device is joined to both on-premises Active Directory and Microsoft Entra ID, so the two controls are related without being interchangeable.

Device compliance is the stronger choice when the organization needs current security posture in place of proof of organizational ownership. It requires Microsoft Intune enrollment, a compliance policy, reliable device identity, and a defined response when the device falls out of compliance. Hybrid join fits environments that still depend on on-premises Active Directory and domain-joined Windows devices, though hybrid join alone never proves that encryption is enabled, patches are current, or endpoint protections are functioning.

A managed Windows laptop on the corporate network can receive low-friction Outlook access after its user completes an earlier sign-in when the device satisfies the relevant policy. The same laptop connecting from a hotel should still meet the policy's identity and authentication requirements unless the organization has deliberately built a trusted-location exception. Network placement never converts an unmanaged or compromised device into a trustworthy one.

Client application controls add another boundary by restricting access to applications that meet the organization's authentication and data-protection requirements. Supported Outlook clients and modern browser experiences fit this model, while unsupported third-party mail clients should be blocked or excluded through a documented exception process.

Users on unsupported operating systems or clients need a clear path, such as a supported browser, managed mobile application, or device enrollment. Without that path, a well-intended policy becomes an access outage rather than a security control.

How Should Named Locations and Trusted IP Ranges Work?

Named locations should describe a network signal instead of substituting for authentication. Administrators can define corporate public IP ranges, branch-office egress addresses, or approved VPN endpoints and use those locations in policy conditions. A common pattern requires MFA outside trusted ranges while allowing a managed, compliant Windows device on the corporate network to avoid an additional prompt.

The exception must remain narrow. A trusted IP range proves that a sign-in emerged from a recognized network, though it never proves that the user is legitimate, the device is managed, or the traffic avoided a compromised VPN or shared proxy. Avoid marking broad cloud-provider ranges, residential ranges, or entire countries as trusted locations, and review the ranges when offices, VPN gateways, internet providers, or network architectures change.

Consider two access requests from the same employee. On-network access from a compliant, hybrid-joined Windows laptop can satisfy device and location conditions and avoid an unnecessary MFA prompt, while off-network access from that same laptop should require MFA. Off-network access from a personal device should require MFA and a supported client, or be blocked when the organization cannot control downloads and session behavior.

Microsoft Learn's Conditional Access conditions guidance treats user, device, application, network, and authentication signals as inputs that administrators can combine. That model supports a graduated policy in preference to a single rule that equates the internal network with safety. Use report-only mode, sign-in logs, and the What If tool before enforcement so administrators can identify unsupported platforms, service accounts, and legitimate travel scenarios.

What Combination Provides the Best Email Protection?

A practical baseline starts with modern authentication, blocks legacy protocols, requires MFA for external access, and requires a compliant device plus an approved client for managed endpoints. Add hybrid-join requirements where Windows domain integration remains necessary, while avoiding hybrid join as the only grant condition. For administrators and high-impact business roles, require phishing-resistant MFA regardless of location or device status.

Microsoft Learn describes Conditional Access policies as if-then decisions built from assignments and access controls. Microsoft's Conditional Access policy guidance supports testing these decisions in report-only mode before enforcement. That process exposes conflicts such as one policy granting access while another blocks it, or a mobile platform failing because it cannot report compliance.

Download controls should match mailbox sensitivity. When users access regulated records from unmanaged devices, block downloads or require browser-only access, and on managed devices allow them only when encryption, screen lock, and endpoint management are active. Treat forwarding, printing, and attachment access as separate data-handling decisions in place of assuming that a successful sign-in makes every action safe.

The final policy should produce predictable outcomes. Managed and compliant Windows devices on trusted networks receive low-friction access, those devices authenticate again off-network, and personal or unsupported devices face MFA, client restrictions, download limits, or a block. A device condition can reduce unnecessary prompts, though it cannot replace strong authentication when the request involves a privileged identity, sensitive data, irregular sign-in behavior, or a role routinely targeted by business email compromise (BEC).

Device compliance proves a laptop is managed; it says nothing about the fraudulent invoice waiting in the mailbox. Adaptive Security detects business email compromise attempts before employees act on them.

Explore the platform

How Can Organizations Block Legacy Authentication Without Breaking Email Workflows?

To block legacy authentication without disrupting email, identify every dependent user, device, printer, scanner, and application before enforcement. Review sign-in logs, create a report-only policy, migrate approved workflows to OAuth or a controlled relay, and enforce the block in stages. Keep emergency access accounts available, test business-critical mail paths, and treat every exception as a temporary migration task rather than a permanent bypass.

1. Identify Legacy Sign-Ins Before Creating the Policy

Start with Microsoft Entra sign-in logs instead of the block itself. Go to Entra ID > Monitoring & health > Sign-in logs, add the Client App column, and filter for legacy authentication. Review both interactive and noninteractive sign-in tabs, because background activity from mobile devices, scripts, and applications can remain hidden in only one view.

Microsoft Entra's legacy authentication categories require careful interpretation. Exchange ActiveSync clients generally represent mobile mail applications and older native clients that authenticate with a username and password instead of modern OAuth. Other clients covers protocols and applications that do not identify themselves as Exchange ActiveSync, including POP, IMAP, SMTP AUTH, and older Outlook clients.

Use the Client App field on each sign-in record to identify the protocol. Record the user, source device, application, IP address, mailbox, and business owner, since a sign-in from an employee's old phone requires a different replacement path from a sign-in generated by a warehouse scanner.

The urgency behind that inventory is easy to underrate. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 13% of all breaches, and basic authentication protocols give those credentials a route that never encounters MFA.

Avoid assuming that a successful sign-in proves a workflow is safe to block, since a printer might send mail only during an overnight batch and a line-of-business application only when an invoice or shipment is created. Ask each system owner to demonstrate the workflow during a controlled test window and document the expected sender, recipient, relay host, and failure behavior.

The table below pairs each legacy protocol with its detection signal, replacement path, and validation test.

2. Configure a Dedicated Block Policy in Report-Only Mode

Create a separate policy named Block legacy email authentication so its scope and impact remain clear. In the Microsoft Entra admin center, open Entra ID > Conditional Access > Policies, select New policy, and include all users. Exclude only documented emergency access accounts and users or groups with a specific, approved migration dependency.

Under Target resources, select all cloud applications. Under Conditions > Client apps, enable the condition and select only Exchange ActiveSync clients and Other clients. Under Access controls > Grant, choose Block access, then set Enable policy to Report-only.

Report-only mode records which sign-ins the policy would block without interrupting mail access. Administrators can compare those results with application inventories and owner feedback before enforcement, while Conditional Access evaluates signals such as the user, device, application, location, and risk before applying a decision.

Review report-only results across a full operating cycle, covering working days, weekends, overnight jobs, payroll runs, invoice processing, mobile travel, and scheduled alerting. Export the affected sign-ins and classify each one as migrate, retire, replace, or approved exception.

A quarantine email never replaces this testing, since quarantine reveals nothing about whether a blocked device can submit mail or whether an automated process will fail silently. Test the authentication decision and the complete business workflow before enabling the policy.

3. Preserve Approved Relay and Application Workflows

Separate human mailbox access from machine-generated email. Printers, scanners, monitoring systems, ticketing platforms, and line-of-business applications rarely need interactive mailbox access. They need a controlled way to submit messages through OAuth-based SMTP submission, a documented SMTP relay, direct send, managed identity, or application redesign appropriate to the workload.

SMTP relay exceptions should be narrow. Restrict the connector or relay by approved source IP, certificate, device group, sender domain, or application identity, and log every submission. Avoid excluding an entire department because one scanner still uses SMTP AUTH; assign that device an owner, replacement date, and test plan.

After Basic authentication is blocked, connect Exchange Online PowerShell with the supported module and interactive or certificate-based modern authentication in place of preserving a password-based administrative script. Review scheduled scripts separately, because a service account can continue operating through a path that stays invisible in an ordinary user review.

App passwords deserve the same scrutiny. They can keep some older applications functioning, though they never modernize POP, IMAP, SMTP, or mobile access. Treat an app password as a temporary bridge with a named owner and expiration plan rather than proof that the underlying workflow is ready for a legacy-authentication block.

Organizations standardizing Microsoft 365 access should document these dependencies alongside their Microsoft 365 integration controls so identity, application, and workflow owners work from the same inventory.

Once report-only results show no unplanned dependencies, enable the policy for a pilot group, then expand it by department or workload while monitoring sign-in failures, mail-flow tracking, application logs, and help desk tickets. A blocked mobile device loses its Exchange ActiveSync connection until the account is reconfigured in a modern client, and that failure stays recoverable when the migration path has been tested in advance.

After rollout, review the policy regularly and remove exceptions as systems migrate. The goal extends beyond making a policy show zero errors: it is to eliminate password-based access while preserving approved email workflows through auditable, modern authentication paths.

Retiring basic authentication closes one bypass while cyberattackers shift toward voice calls and text messages that identity rules never inspect. Adaptive Security runs phishing simulations across email, SMS, and voice.

Book a demo

How Do Intune App Protection Policies Secure Mobile Email With Conditional Access Policies for Email?

Intune App Protection Policies secure mobile email by allowing Outlook for iOS and Android while blocking native clients such as Apple Mail, even when a phone is never enrolled in Intune device management. Configure Conditional Access to control which client can connect to Exchange Online, then use Intune to require an app PIN and restrict copying, pasting, saving, sharing, and opening company data in other apps. Test every sign-in path in report-only mode before enforcement, because access control and in-app data controls operate at different layers and fail in different ways.

1. Restrict Mobile Email to an Approved Client App

Define the access boundary in Microsoft Entra Conditional Access. Target Office 365 Exchange Online, include the relevant users or groups, and select iOS and Android under Conditions > Device platforms. Under Client apps, select Mobile apps and desktop clients for modern authentication clients.

Create a separate policy for older Exchange ActiveSync connections and select Exchange ActiveSync clients. Modern authentication and legacy synchronization paths do not evaluate through the same client-app condition, so one policy should never be expected to cover both.

Mobile access deserves that attention because social engineering has moved onto the phone. According to Mandiant's M-Trends 2026, voice phishing was the most common initial infection vector in cloud-related compromises during 2025, accounting for 23% of those intrusions.

Use the grant control that matches the organization's device-management model.

For a BYOD email policy, select Require approved client app or Require app protection policy, depending on the controls the tenant supports. Microsoft Entra Conditional Access also supports combining these controls with Require one of the selected controls, an OR condition, which lets a compatible app satisfy the app-protection requirement while an older approved client follows the approved-app path.

The distinction matters. Require a compliant device evaluates device compliance through Intune, Require a hybrid-joined device evaluates device identity, and Require an approved client app evaluates the application used to connect. None of these controls, by itself, prevents a user from copying an email into a personal notes app after Outlook has been allowed to open it.

2. Create the Intune App Protection Policy for Outlook

Create separate App Protection Policies for iOS/iPadOS and Android under Apps > App protection policies. Target Microsoft Outlook in preference to every application. Assign the policy to the same user groups targeted by Conditional Access, and confirm that the required Microsoft Entra ID and Intune licensing are assigned before testing.

The app policy protects company data inside Outlook, including on an unmanaged phone. Require a work or school account credential and an app PIN, then configure PIN complexity, retry limits, and reset behavior for the organization. Users should see an Outlook sign-in prompt followed by a PIN prompt when the app opens or returns from an inactive state.

Under data-transfer settings, configure Send org data to other apps and Receive data from other apps according to the workflow, and set Restrict cut, copy, and paste between other apps to Blocked or a managed-app-only option. Disable Save As, then configure Open data into organizational documents and Open data into other apps so attachments and message content remain within approved, policy-managed applications.

Microsoft's Exchange Online protection guidance for unmanaged iOS devices illustrates the division clearly. Conditional Access blocks an unapproved mail client, while Intune limits Outlook actions such as copying, pasting, and saving data. The policy gives employees a controlled way to work on personal devices without treating those employees as the source of the risk.

For organizations building broader Microsoft 365 access controls, integration planning for Microsoft 365 and identity systems should align with the same user groups and authentication paths.

3. Match Client-App Selections to the Intended Behavior

Client-app selections determine which sign-in traffic a policy evaluates. Select Browser when the policy must govern Outlook on the web or another browser-based access path, and select Mobile apps and desktop clients for modern authentication applications such as Outlook mobile and desktop Outlook. Select Exchange ActiveSync clients in a dedicated policy when the goal is blocking legacy mobile synchronization paths that could otherwise allow Apple Mail or another native client to connect.

Selecting Outlook in an App Protection Policy does not automatically block Apple Mail. Intune can protect data inside Outlook, while Apple Mail cannot receive those controls at all, so Conditional Access must deny the unsupported client before Exchange Online grants access.

Test the policy with one iPhone and one Android device. Adding the Exchange account in Apple Mail should produce a message stating that the app is not approved by the organization, followed by a block, while Outlook mobile should complete MFA, register as prompted, and display the app PIN.

Open an attachment, attempt to copy text into a personal app, use Save As, and try sharing the file through an unmanaged destination. Each action should produce the restriction configured in Intune.

Keep Conditional Access in Report-only mode while reviewing sign-in logs, and exclude a break-glass account and a controlled test group before broader deployment. After browser, mobile-app, desktop-client, and Exchange ActiveSync paths produce the intended results, switch enforcement on. Conditional Access decides whether access is granted, Intune App Protection decides what an allowed Outlook session can do with company data, and together they secure mobile email without requiring the organization to manage every personal device.

Mobile data controls limit what an approved app can do, though they cannot stop an employee from approving a fraudulent request. Adaptive Security builds that judgment through cybersecurity awareness training.

Explore the platform

How Do Conditional Access Policies for Email Handle Exceptions, Shared Mailboxes, and Hybrid Dependencies?

Conditional access policies for email fail most often at the boundaries: emergency accounts, automation identities, shared mailboxes, and hybrid services that authenticate differently from ordinary users. Map each dependency, test the signed-in identity behind every request, and treat exclusions as narrow, monitored, time-bound exceptions. Mandatory MFA changes the operating assumptions for administrators, B2B guests, federated identity providers, service accounts, and break-glass access, so validate each policy in report-only mode before enforcement.

1. Protect Emergency-Access and Service or Synchronization Accounts

Inventory every identity that can administer Microsoft 365, synchronize directories, run automation, or recover the tenant. Administrators and B2B guests must satisfy applicable MFA requirements, while a federated identity provider must send an acceptable MFA claim when it authenticates users outside Microsoft Entra ID.

Avoid assuming a break-glass account remains safe because it is excluded from a Conditional Access policy. Apply phishing-resistant passkeys or certificate-based authentication where supported, store recovery procedures offline, and test each account on a scheduled basis without using it for routine administration.

Unmonitored accounts also extend how long an intrusion lasts. According to Mandiant's M-Trends 2026, global median dwell time rose to 14 days from 11 days the previous year, which gives a cyberattacker holding an ungoverned identity a longer window inside the tenant.

Separate human identities from workload identities before applying conditional access policies for email. A service principal or managed identity never completes an interactive MFA challenge, while a script that signs in with a standard user account does. Replace user-based automation with a managed identity, service principal, or another workload identity, and monitor sign-in logs for failed token requests and unexpected interactive use.

Microsoft Entra Connect synchronization is not a reason to exclude every synchronization account. Its administrative operators still require the controls assigned to administrators, while the synchronization service itself requires a documented identity, permission scope, and recovery owner.

Keep every exception narrow and temporary. Define the exact account, resource, client, location, and duration; record the owner and business reason; alert on every sign-in; and set an expiration or review date. A permanent trusted service account exclusion becomes an unmanaged bypass when the account can reach Exchange Online, SharePoint, Teams, or directory data.

2. Separate Shared and Delegated Mailbox Permissions From User Access Policy

Treat a shared mailbox as a mailbox-permission problem in place of an identity-policy exception. Full Access, Send As, and Send on Behalf permissions determine what an authenticated user can do after access is granted, and they never independently bypass the signed-in user's Conditional Access requirements.

When a user opens a shared mailbox through Outlook, Outlook on the web, or a mobile client, the policy evaluates the user and the resource request that delivers the mailbox data. A delegate can retain valid mailbox permissions and still be blocked by device, location, authentication-strength, or MFA conditions.

Test the delegate's primary mailbox and the shared mailbox from every supported client before deployment, which exposes outages caused by assuming that a mailbox without a separate password can bypass the delegate's sign-in policy.

For high-volume operational mailboxes, remove direct sign-in credentials and assign access through named, governed user accounts. Review delegates through joiner, mover, and leaver processes, and document whether third-party mail applications use delegated user tokens, application permissions, or a legacy protocol, because each model creates different monitoring requirements.

Organizations that need a broader view of Microsoft 365 integrations and identity dependencies should document the account, token type, target service, and recovery owner for every mailbox workflow. That record turns a policy exception into an accountable operating decision rather than an undocumented workaround.

3. Map Hybrid Exchange and Microsoft 365 Dependencies Before Enforcement

Hybrid Exchange environments require a dependency map because one user action can generate several resource requests. Exchange Online mailboxes, SharePoint files, Teams conversations, Microsoft Entra Connect synchronization, AD FS authentication, and Microsoft 365 public-client applications never operate as isolated policy targets.

The following dependencies produce the most common enforcement surprises.

Avoid targeting Outlook or Teams as though they were the protected data service. Conditional Access evaluates the resources requested by public clients, so a policy applied to Exchange governs Outlook's email request, while a SharePoint policy governs files requested through Teams. Use sign-in logs and audience reporting to confirm which resources each client requests, and test representative users, delegates, guests, administrators, and automation identities.

Deploy the policy in report-only mode and review successful and interrupted sign-ins across a controlled pilot of on-premises and cloud mailboxes. Confirm that AD FS sends the expected claims, Microsoft Entra Connect continues synchronization, delegates retain only intended access, and break-glass recovery works under the new MFA requirements.

Every documented exception becomes a standing invitation for cyberattackers who study shared mailboxes and service accounts. Adaptive Security monitors human risk across those accounts and assigns training where exposure concentrates.

Take a self-guided tour

How Should Teams Test and Roll Out Conditional Access Policies for Email Safely?

Test conditional access policies for email in report-only mode, model expected outcomes with What If, validate every supported client through a controlled pilot, then enforce in phases. Review Microsoft Entra sign-in logs after each test to confirm the evaluated Exchange resource, client app, device state, location, authentication requirement, and policy result. Keep break-glass access available, define rollback triggers before enforcement, and treat unexplained access or MFA behavior as a deployment failure instead of an acceptable variance.

1. Start in Report-Only Mode and Run What If Analysis

Create a narrowly named policy such as CA-Exchange-Email-Block-Legacy-Pilot-2026 and select Enable policy: Report-only. Scope it to Exchange Online or the specific email resource, define the intended users and conditions, and exclude only approved emergency access accounts or documented service workflows. Every exclusion needs an owner, a business reason, and an expiration or review date.

For a legacy authentication policy, target Exchange ActiveSync clients and Other clients, then select Block access while the policy remains in report-only mode. Retain an emergency access path so a policy error cannot lock administrators out, and use the report-only period to capture normal business cycles, mobile reconnects, scheduled mailbox activity, and noninteractive sign-ins.

Run What If for each important combination of identity, resource, client app, platform, location, and device state, testing a member, guest, privileged user, shared-mailbox delegate, and service account separately. Model Outlook desktop, Outlook on the web, Outlook mobile, Apple Mail, Thunderbird, Exchange ActiveSync, POP or IMAP, SMTP relay, on-network and off-network access, and a blocked legacy client.

What If identifies policies that apply and policies that do not, though it never replaces a real sign-in. Record the expected result before testing so an unexpected result cannot be reclassified as acceptable after the fact.

Use the Conditional Access policy report and sign-in logs to investigate every report-only match, adding the Client App column and filtering for legacy protocols when validating a block. Open individual events and confirm the user, client application, and target resource, which should identify the Exchange service the policy was built to protect.

Review the Basic info, Device info, Location, Authentication details, Conditional Access, and Report-only tabs to confirm device state, network origin, evaluated client app, and whether the policy shows Success, Failure, Not applied, or Report-only.

A successful password sign-in never proves MFA was enforced. Review the authentication requirement and authentication methods, because a requirement satisfied by an existing token claim produces no new prompt. That result is acceptable only when the session contains a valid MFA claim and the behavior matches the policy design.

2. Build Pilot Groups and Test Real Email Scenarios

Create a pilot group that represents the organization's risk and operating diversity in preference to the security team alone. Include users on Windows and macOS, iOS and Android, remote and office networks, managed and unmanaged devices, finance or shared-mailbox users, delegated assistants, guests, and users with older mail clients. Keep one controlled test account for each required scenario, recording the device identifier, operating system, application version, network location, and expected outcome before testing begins.

Test modern clients first. In Outlook desktop, verify profile discovery, mailbox synchronization, calendar access, shared mailboxes, and delegated folders, and in Outlook on the web, test browser sign-in, attachments, and guest access. In Outlook mobile, verify token acquisition, synchronization, push notifications, and MFA or device-compliance prompts.

Test third-party and protocol-dependent clients deliberately. Apple Mail and Thunderbird must either authenticate through modern authentication or produce the planned block, and Exchange ActiveSync needs testing independently from Outlook mobile because the protocol and client classification can differ. POP and IMAP should fail when prohibited, with a clear user-facing message in place of a continuing password prompt loop.

SMTP relay requires a separate test, since an application or device that sends mail is not equivalent to an interactive user sign-in. Validate scanners, multifunction printers, line-of-business applications, alerting systems, and service accounts before blocking their path, and replace basic authentication with OAuth, authenticated relay, a connector, or a managed identity where appropriate.

The matrix below defines the acceptance evidence each scenario must produce.

After every test, capture the sign-in event and compare the observed result with the What If prediction. Confirm that the Application or Resource is Exchange Online, the Client App matches the tested client, the location is interpreted as expected, and the device state is accurate.

Look for MFA prompts that were never enforced, successful sign-ins showing Not applied, unexpected policy exclusions, or an apparently successful request associated with a different resource. These discrepancies indicate an incorrect assignment, an untested dependency, a cached token, or a client using a different authentication path.

3. Enforce in Phases and Preserve Rollback

Move from report-only to On for the pilot group only after every acceptance row has evidence and each exception has a named owner. Start with a small operational cohort, then add departments in waves, and keep report-only monitoring or equivalent sign-in visibility in place so new access patterns remain visible as enforcement expands.

Resist adding an exclusion immediately after a user reports an error. Identify the evaluated resource, client app, device state, and policy condition before changing the assignment, then set an observation window for each wave and monitor sign-in failures, help desk tickets, legacy authentication attempts, mobile synchronization, and SMTP relay health against the pre-enforcement baseline.

That comparison matters because email remains the dominant entry point. According to IBM's Cost of a Data Breach Report 2026, phishing was the most common initial access vector for the fourth consecutive year, with voice and SMS phishing producing the highest average breach costs.

Rollback is warranted when a critical workflow fails without an approved replacement, an emergency account cannot sign in, a modern client is blocked unexpectedly, or logs show an excluded account being evaluated as in scope. Rollback should be a controlled policy change rather than an improvised deletion, so keep the policy definition, assignments, exclusions, and version history documented.

If a trigger fires, return the policy to report-only for the affected group, restore the approved configuration, and preserve the failed sign-in records. Correct the dependency, retest, and resume with the smallest safe cohort. Once all waves meet the acceptance criteria, remove temporary exclusions, disable unused legacy protocols, and schedule recurring reviews of new clients, service accounts, and delegated mailboxes.

Report-only testing proves a policy behaves correctly; nothing in a sign-in log shows whether employees would report a suspicious message. Adaptive Security measures reporting behavior alongside phish triage.

Take a self-guided tour

How Do Teams Monitor, Troubleshoot, and Automate Conditional Access Policies for Email?

Operating conditional access policies for email requires more than enabling MFA or block controls. Review sign-in results, reproduce confusing outcomes with What If, track coverage and exceptions, and automate policy reporting and controlled changes through Microsoft Graph. Maintain peer-reviewed version history, because licensing, authentication protocols, service accounts, and application dependencies can change outcomes without any policy edit.

1. Diagnose Policy-Result Mismatches

Start with the sign-in record instead of the user's account of what happened. Record the user or service principal, application, client type, device state, location, authentication method, policy name, result, grant controls, session controls, and failure reason. A policy appearing in the log without an MFA prompt is not automatically a defect, since the user may have satisfied MFA earlier in the session or received the required control from another applicable policy.

Conditional Access evaluates assignments and access controls together. Microsoft's Conditional Access policy documentation explains that multiple applicable policies are combined, so a user might need both MFA and a compliant device even when each requirement appears in separate policies. Use that model to investigate common symptoms:

• Policy logged, no MFA prompt: Check whether MFA was already satisfied, whether session controls preserved the session, and whether the policy requires a stronger authentication method in preference to a new prompt;
• Unexpected block: Compare user, application, client app, device, location, and exclusion assignments, since a broad block policy, stale named location, or unrecognized client can explain the result;
• Unprotected client: Confirm that the policy targets the client app type in use, because modern browser access and legacy authentication produce different signals;
• Service account failure: Identify whether the account is a user, workload identity, or service principal, then verify that the policy supports that identity type;
• Application dependency failure: Check whether the requested application depends on another service, such as Exchange Online, because a policy applied to the dependency can block access even when the primary application's policy appears correct.

Run What If for the exact identity, target resource, device platform, client app, location, and risk conditions. Compare the predicted result with the live sign-in record, then test the smallest change in report-only mode before enabling it. Treat a mismatch as an investigation prompt in place of proof that the policy engine is malfunctioning.

2. Monitor Coverage, Authentication, and Exceptions

Review exposure and operational friction together by tracking covered users, blocked sign-ins, MFA prompts, compliant-device coverage, legacy-authentication attempts, policy exceptions, and time to remediate. A high block count without a corresponding reduction in risky access indicates a targeting problem, while a low prompt count can reflect effective session reuse or a policy that misses the client types employees actually use.

Review coverage by application and user population rather than a single tenant-wide percentage. Microsoft's Conditional Access overview describes coverage and policy activity views that identify applications with and without policy coverage. Export the policy inventory and sign-in data on a fixed schedule, preserve each export with its review date, and compare changes with the previous period.

Give legacy-authentication attempts their own trend line, since they often reveal an unprotected client, outdated application, or account that bypasses modern controls. Assign each attempt an owner and disposition: migrate the client, block the protocol, replace the integration, or approve a time-limited exception. Document the business reason, expiry date, compensating control, and approver for every exception.

Apply the same review process to licensing and protocol changes, recording which capabilities depend on current Microsoft Entra licensing and which integrations still use older authentication flows. A weekly operational review catches drift early, while a monthly leadership report should show coverage, blocked access, exception age, and remediation time.

3. Automate Policy Change Control Through Microsoft Graph

Use Microsoft Graph to make policy creation and reporting repeatable, while keeping production enforcement behind human approval. Export current policies before every change, store the JSON in version control, and attach a change record covering the business objective, targeted identities, resources, conditions, grant controls, session controls, exclusions, licensing assumptions, and rollback method. For Microsoft 365 and identity integrations, document the surrounding dependencies in the integration workflow so policy changes avoid creating undocumented access failures.

Build automation in separate stages:

1. 1Read and normalize the current policy set.
2. 2Compare the proposed configuration with the approved version.
3. 3Generate a report showing added, removed, and changed assignments.
4. 4Require peer review and explicit approval.
5. 5Deploy to a pilot group or report-only mode.
6. 6Verify sign-in outcomes and update version history with deployment time, operator, test cases, exceptions, and observed impact.

Automated reporting should surface policy state, covered users, blocked and successful sign-ins, MFA outcomes, compliant-device rates, legacy-authentication attempts, and open exceptions. Alert when a policy is disabled, an exclusion expands, coverage falls, or legacy activity returns after migration.

Make rollback practical. Keep the prior policy definition, dependency notes, and tested recovery command together so an operator can restore the previous state without reconstructing it during an outage. That discipline turns conditional access policies for email from static settings into an auditable control process.

Coverage dashboards track policy state without revealing which employees keep clicking convincing lures. Adaptive Security scores individual risk from real cyberattacks and assigns cybersecurity awareness training automatically.

Explore the platform

Why Email Access Controls Are Part of a Broader Human-Risk Program

Email access controls reduce unauthorized entry, though they never govern the decision an employee makes after a convincing message arrives. MFA, device restrictions, and legacy-protocol blocking limit account compromise, while cybersecurity awareness training teaches employees to recognize phishing, spear phishing, vishing, and smishing before they disclose information or approve a request. CISA's 2025 credential-risk guidance supports pairing phishing-resistant authentication with broader identity controls, because stronger sign-in requirements address credential abuse instead of the social engineering that precedes it.

How Do Prevention Layers Work Together?

Conditional access policies for email create a prevention layer by deciding who can reach an account, from which device, and under what authentication conditions. Policies can require MFA for risky sign-ins, restrict access from unmanaged devices, limit sessions by location or risk level, and block older protocols. Phishing-resistant methods such as passkeys or security keys add stronger protection against credential theft, because a fraudulent login page cannot easily replay the authentication exchange.

These controls narrow a cyberattacker's options without making the message itself safe. An employee can still receive a malicious email on an approved device, follow a fraudulent payment instruction, disclose sensitive information during a phone call, or approve an account change after a convincing executive impersonation.

Volume alone makes that exposure routine. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest complaint count of any reported crime type.

Cybersecurity awareness training addresses the judgment point after delivery. Employee phishing awareness training should show how cyberattackers create urgency, imitate vendors, and exploit familiar business processes, while spear-phishing recognition should cover the open-source intelligence (OSINT) used to personalize messages. Reporting workflows give employees a direct route to flag suspicious messages before another person acts on them.

Which Human-Risk Signals Should Security Teams Measure?

Behavioral measurement connects email controls to outcomes that identity logs cannot capture. Track whether employees report suspicious messages, how quickly, whether they repeat the same mistake after coaching, and whether they verify high-risk requests through an independent channel.

Completion rates alone are a poor proxy for readiness. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics fail to measure sustained change in employee attitudes and behaviors.

Useful signals include:

• Authentication signals: MFA enrollment, blocked legacy-protocol attempts, risky sign-ins, and access from unmanaged devices;
• Decision signals: Phishing simulation clicks, credential submissions, attachment opens, and compliance with payment-verification procedures;
• Response signals: Report rates, time to report, duplicate reports, and the proportion of reported messages classified as malicious;
• Change signals: Improvement after targeted coaching, recurring exposure by role, and risk trends across finance, executives, and administrators.

Multi-channel cybersecurity awareness training extends measurement beyond email by testing how employees respond to realistic voice, SMS, and deepfake scenarios. The objective is to identify the precise behavior that needs practice, deliver targeted instruction, and confirm whether the next decision improves.

How Should Governance Reporting Combine Access and Behavior?

Governance reporting should present identity enforcement and human behavior as connected controls. A board or audit committee needs to see whether privileged accounts use phishing-resistant authentication, whether legacy access paths remain open, which departments face the most phishing exposure, and whether reporting behavior is improving.

Board attention is already assumed by most oversight frameworks. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of organizations indicate that board members receive regular cybersecurity updates, and 30% of highly resilient organizations reported that board members hold personal liability in the event of cyber breaches, compared with 9% of organizations with insufficient resilience.

A useful report separates control coverage from human-risk outcomes. Control coverage includes MFA adoption, device-policy enforcement, and legacy-protocol blocks, while human-risk outcomes include phishing simulation performance, suspicious-message reporting, completion of remediation training, and repeat exposure. Combining both views prevents a misleading conclusion such as treating enabled MFA as evidence that email risk is managed.

Strong programs assign clear ownership. Identity teams maintain conditional access policies for email, cybersecurity awareness leaders build employee phishing awareness training and phishing simulations, security operations manage reporting workflows and response, and compliance teams preserve evidence mapped to the applicable framework.

Governance reports that show full MFA coverage can still hide a workforce untested against realistic social engineering. Adaptive Security connects identity enforcement to measured employee behavior across every channel.

Book a demo

How Adaptive Security Extends Conditional Access Policies for Email

Conditional access policies for email decide which identities reach Exchange Online, while Adaptive Security addresses what happens to the messages that pass that boundary legitimately. Its Cloud Email Security connects to Microsoft 365 through an API, without MX record changes or mail-flow redirection, and applies layered machine learning and language-model detection to inbound messages. Confirmed cyberattacks are removed automatically from every inbox they affected, including near-identical variants sent across the organization.

Detection then becomes measurement. Every cyberattack that targets an employee feeds that person's risk score and triggers relevant Security Awareness Training, so the lure that arrives becomes the lesson delivered. Phishing simulations extend the same measurement across email, SMS, and voice, while Phish Triage closes the loop by routing employee reports back into detection accuracy.

The same platform covers the governance work that identity policies leave open. Compliance Training maps evidence to the frameworks auditors ask about, and AI Governance surfaces shadow AI use and personal-account data movement, an exposure most tenants cannot see. According to the National Cybersecurity Alliance's 2025-2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported receiving no training on the security or privacy risks of AI tools.

Sign-in policies and inbox defenses often run as separate programs with separate reporting, leaving gaps between them. Adaptive Security unifies detection, phishing simulations, and cybersecurity awareness training in one platform.

Take a self-guided tour

Frequently Asked Questions About Conditional Access Policies for Email

How Do Conditional Access Policies Protect Exchange Online Email From Legacy Authentication Cyberattacks?

Conditional Access protects Exchange Online by blocking sign-in requests that use basic authentication protocols such as POP, IMAP, SMTP AUTH, and older Exchange ActiveSync clients. Those protocols cannot enforce MFA, so a cyberattacker can use a stolen password without satisfying a second factor. Microsoft recommends targeting the Other clients condition in a dedicated block policy and starting in report-only mode to identify affected users and applications. Microsoft guidance for blocking legacy authentication explains the deployment pattern. Review sign-in logs, migrate approved workloads to OAuth, and enforce the block after testing.

What License Is Required for Conditional Access Policies for Email in Microsoft 365?

Conditional access policies for email require Microsoft Entra ID P1 or a Microsoft 365 subscription that includes it, such as Microsoft 365 Business Premium, Microsoft 365 E3, or Microsoft 365 E5. The license must cover every user subject to a policy. Microsoft Entra ID P2 adds identity protection and risk-based controls, while P1 remains the baseline for standard email policies that require MFA, restrict devices, or block legacy authentication. Confirm entitlement and assignment before enabling enforcement, including for pilot groups and administrators.

Can Conditional Access Require MFA Only for Email Accessed From a Personal or Unmanaged Device?

Yes. Conditional Access can require MFA for Exchange Online email when the sign-in comes from a personal, unmanaged, or otherwise untrusted device. Build a policy that targets Exchange Online, includes the relevant users, applies a device or client-app condition, and uses Require multifactor authentication as the grant control. Exclude compliant or hybrid-joined devices only when those devices satisfy a documented access standard. Microsoft documentation on Conditional Access conditions describes the available device, platform, location, and client-app signals. Use report-only mode and test Outlook, browser access, and mobile clients before enforcement.

How Do Conditional Access Policies Affect Shared Mailboxes and Delegated Mailbox Access?

Conditional Access evaluates the signed-in user and the client request in preference to the shared mailbox as an independent identity. A user opening a shared mailbox or using delegated permissions must satisfy the policies that apply to that user's access to Exchange Online. Granting Full Access or Send As never bypasses MFA, device, location, or client-app requirements. Test delegates on managed and unmanaged devices, document service-account exceptions separately, and avoid treating shared-mailbox permissions as an access-control boundary.

How Can Administrators Verify That Outlook, Apple Mail, Thunderbird, and SMTP-Enabled Applications Are Evaluated Correctly?

Verify evaluation by testing each client and reviewing its Microsoft Entra sign-in-log result, including the evaluated resource, client-app classification, authentication method, and Conditional Access outcome. Outlook and Apple Mail can use modern authentication when configured appropriately, while Thunderbird and SMTP-enabled applications require explicit protocol and OAuth validation. The Other clients condition covers basic-authentication protocols such as IMAP, MAPI, POP, and SMTP. Run report-only and What If tests with controlled accounts, record expected results, and investigate every mismatch before enforcement.

Conditional Access decides who reaches a mailbox, though the message inside still asks an employee for a decision. Adaptive Security protects both the access path and the decision that follows.

Book a demo