Conditional Access Rollout Blocked by Legacy Mail Clients
Contoso has 4,200 users, all licensed for Microsoft Entra ID P1. The identity team builds a Conditional Access policy named Block-Legacy that targets All users and All cloud apps, with a client apps condition set to block exchange active sync and other legacy clients. Pilot mode is enabled for a test group of 25 users. Within two hours, 11 of the 25 report that Outlook on their smartphones stopped syncing mail, while Outlook on the web and desktop Outlook continue to work. Investigation shows the phones are configured with basic authentication against Exchange Online and do not support modern authentication. The help desk also reports that a kiosk account used by a warehouse scanner, which is not in the pilot group, is authenticating from an unfamiliar country. The security team wants the policy enforced for everyone by the end of the week.
1. Explain why the policy broke the phones and describe the two changes the team should make before broadening enforcement.
Read the worked answer
The block is working as designed: the phones use basic authentication, which Conditional Access classifies as a legacy client, so the client apps condition matches and the block control applies. Desktop and web clients negotiate modern authentication and are therefore not matched.
Change 1: fix the client, not the policy. Move the phones to an app that supports modern authentication (for example, Outlook mobile signed in with Microsoft Entra credentials) or reconfigure the mail profile. Excluding legacy protocols from a block policy defeats the purpose of the policy.
Change 2: treat enforcement as a staged rollout. Expand the pilot group in waves, publish a communication and remediation window, and use report-only mode first so the team can see which users and devices would be blocked before the block takes effect. Report-only produces sign-in log entries without enforcing the control, which is exactly the evidence needed to size the remediation effort.
The unfamiliar-country sign-in for the kiosk account is a separate signal and should be triaged as a potential compromise (revoke sessions, reset credentials, review sign-in logs) rather than folded into the rollout.
2. A stakeholder asks why the policy should not simply be set to report-only permanently, since report-only never breaks anything. Give the reasoning you would use.
Read the worked answer
Report-only evaluates the policy and records the result in the sign-in logs, but it does not enforce the control. Permanently running in report-only means legacy clients can still authenticate and access mail, so the risk the policy was written to close stays open. Report-only is a decision-support and rollout tool: it answers 'who would this affect' before enforcement.
The correct pattern is time-boxed. Run report-only, review the sign-in log results for the targeted population, remediate clients that cannot meet the requirement, then switch to On. Keep report-only for any new policy you add later. If the organization wants a permanent safety net, pair enforcement with an exclusion group that is monitored and reviewed, not with permanent report-only.