Block legacy authentication without discovering your last unattended mail client through an outage ticket. For Entra administrators, the task is to identify real dependencies, test a narrowly targeted Conditional Access policy, and prove both the block and continued modern sign-ins. This runbook takes you from log review to a controlled pilot, with a rollback path.
Our recommendation: observe the intended tenant-wide scope first, resolve legitimate dependencies, then enforce for an explicit pilot group before widening. Keep the change separate from existing protections so a rollback affects only this new policy.
- Check interactive and non-interactive user sign-ins.
- Target only the two documented legacy client categories.
- Read report-only failures as potential blocks.
- Prove a blocked legacy attempt and an unaffected modern sign-in.
Why this matters now
Make this an October 2026 hardening task if your tenant still has unexplained legacy user sign-ins or an untested exception list. It is established functionality, not a newly announced retirement. Microsoft recommends blocking legacy authentication requests that cannot support multifactor authentication. An MFA deployment is not a reason to stop checking how clients actually authenticate.
The useful outcome is an evidence-backed access decision, not another policy name in a list. Record which identity, client, and resource would be affected, who owns the dependency, and how it will be replaced. For the complementary credential work, use our Microsoft Entra passkey policy guide; this procedure does not change passkey enrollment settings.
Before you start
| Requirement | Details |
|---|---|
| Policy operator | Use at least Conditional Access Administrator to create and change the policy. |
| Log reader | Use at least Reports Reader for sign-in review; arrange the appropriate access before the change. |
| License | As of October 2026, Conditional Access requires Entra ID P1; Microsoft 365 Business Premium also includes access. Confirm entitlement for the users in scope. This runbook does not use risk-based controls or extra reporting infrastructure. |
| Existing baseline | A tenant already using Conditional Access, documented recovery access, and an approved change window. If security defaults are your baseline, use the boundary below instead. |
| Tools and evidence | Entra admin center in a current browser, a protected change record, an explicit pilot group, and approved test accounts and clients. No PowerShell module is required. |
Inspect Entra ID > Overview > Properties > Manage security defaults. Security defaults already block legacy authentication and offer a free-tier protection path. If enabled, stop this procedure: do not disable them simply to create this policy. Replacing that baseline requires a separate migration covering its other protections.
Step-by-step: Block legacy authentication safely
1. Capture the baseline
Open Entra admin center > Entra ID > Conditional Access > Policies. Inspect existing enforced and report-only policies, recording their names, identifiers, scope, exclusions, and state. The Policies page lists these policies. If an enforced legacy block already provides the required coverage, validate it rather than adding a duplicate.
Agree the pilot membership, business tests, recovery operator, and rollback trigger in the change record. Confirm approved emergency access is usable before enforcement, without changing its credential design here. Expected result: a known before-state and a named decision-maker. Check it worked: another administrator can identify exactly which new policy may be changed during rollback and which existing policies must remain untouched.
2. Identify dependencies
As Reports Reader, open Entra ID > Monitoring & health > Sign-in logs. Use Columns > Client App if the column is missing, then Add filters > Client App, select the legacy authentication protocols, and select Apply. Repeat on User sign-ins (non-interactive), following the documented legacy-use discovery procedure.
Open individual events and inspect Basic Info > Client App. Record the user, target resource, protocol classification, time, and outcome. Ask the application owner to reproduce legitimate jobs during observation, including infrequent batch activity. A failed internet sign-in attempt is not automatically a business dependency; distinguish it from a job that successfully authenticates.
Expected result: each legitimate dependency has an owner and replacement or retirement plan. Check it worked: reconcile findings against actual scheduled jobs, not only help desk memory. Choose an observation period covering your business cycle; that is our recommendation, not a Microsoft-mandated duration. Keep unknown entries unresolved until investigated.
3. Create report-only policy
Return to Entra ID > Conditional Access > Policies > New policy as Conditional Access Administrator. Name it clearly, for example CA-Block-Legacy-UserAuth. Apply the official policy settings:
- Assignments > Users or workload identities: Include All users. Under Exclude > Users and groups, select the documented emergency accounts and only explicitly approved temporary dependencies.
- Target resources > Resources (formerly cloud apps) > Include: select All resources (formerly ‘All cloud apps’).
- Conditions > Client apps: set Configure to Yes; select only Exchange ActiveSync clients and Other clients, then Done.
- Access controls > Grant: choose Block access, then Select.
- Set Enable policy to Report-only, review the settings, and select Create.
Do not add location, device, or risk restrictions to this baseline. Leave Browser and Mobile apps and desktop clients unchecked. Expected result: a new observation policy. Check it worked: reopen it and compare every setting with the change record, especially client selection and state.
That scope behavior comes from the client-app conditions reference. Each temporary exclusion should have a business owner, expiry decision, and remediation task; avoid an undocumented permanent exception group.
4. Review potential blocks
Return to sign-in logs, open a relevant event, and inspect its Report-only tab for this policy. Report-only evaluates the policy without enforcing its block. For a matching block policy, Report-only: Failure means the attempt would be blocked; it does not mean the configuration failed to save.
Report-only: Not applied means at least one condition did not match. Confirm that is correct for a modern sign-in or excluded account. Investigate it for a supposedly in-scope legacy event. Keep existing enforced policies active while observing the new one.
Expected result: a reviewed list of would-be blocks and unaffected modern tests. Check it worked: link each legitimate potential block to its owner and remediation decision. Do not manufacture a successful legacy session by weakening another protection. If another control already rejects the attempt before useful evaluation, record that limitation rather than claiming this policy was proved.
5. Enforce a pilot
After approval, reopen the new policy. Change Include from All users to Select users and groups and choose the explicit pilot group; preserve approved exclusions and all other settings. This is the group-staged deployment approach, not traffic splitting. Record the membership and scope before setting Enable policy to On and saving.
Have consenting pilot users run approved modern-client business tests in fresh sessions. Where a safe legacy test is available, attempt it and inspect the new event’s Conditional Access details. Expected result: this policy blocks matching legacy authentication while modern tests remain outside its client scope. Check it worked: identify this exact policy in the failed attempt and capture the successful business-test result. A generic failure from another control does not prove the new policy caused it.
6. Widen with evidence
At the approved expansion window, open the same policy and restore Include > All users only after the original observation findings are resolved. Recheck exclusions, client categories, and Block access, then save. Keep the service desk and application owners available for the change.
Expected result: the reviewed tenant-wide user scope is enforced. Check it worked: repeat representative modern business tests, inspect new legacy events, and compare affected identities against the observation record. If business coverage is incomplete, retain the pilot rather than expanding on a calendar alone.
Verify the result
Store configuration, log references, owner decisions, and functional results together. Identity cleanup remains a separate control: our Entra guest access-review runbook addresses who retains membership, not which authentication clients this policy blocks.
- Client scope contains only the two intended legacy categories.
- A matching attempt identifies this policy as the block, or its test limitation is explicit.
- Representative modern business tests succeed.
- Temporary exclusions have owners and remediation decisions.
- Recovery access and rollback responsibility are confirmed.
Roll back
- Using the recovery operator if needed, open Entra ID > Conditional Access > Policies and select only the new policy recorded in this change.
- Change Enable policy from On to Report-only and save. This stops that policy’s enforcement while retaining evaluation; it does not remove other controls.
- Repeat the failed business action in a fresh session, inspect its new log event, and confirm whether this policy was the cause. Preserve evidence and investigate any remaining block instead of disabling more policies.
- Correct the dependency or scope issue, return to observation, and obtain approval before enforcing again. Do not delete the policy or broadly exclude users as an unrecorded recovery shortcut.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Modern client is blocked by this policy | Client apps left unconfigured or modern categories selected. | Roll back this new policy; inspect Configure and the checked client categories before retesting. |
| Legacy event says Not applied | User excluded, outside pilot, or another condition does not match. | Inspect event and policy scope together; correct the unintended mismatch. |
| Report-only Failure, but job still runs | Evaluation is being mistaken for enforcement. | Use it as impact evidence; enforce only after dependency remediation and approval. |
| No legacy events appear | Wrong tab, filter, time window, or job has not run. | Review both user tabs and reproduce the approved workload; absence alone is not proof. |
| Failure continues after rollback | A different policy or service control is rejecting access. | Inspect the new sign-in details and troubleshoot that cause separately. |
FAQ
Does this block service principals?
No. Calls by service principals are not blocked by a user-scoped Conditional Access policy. Separate user-account automation from application identities during discovery, and route workload-identity controls to their own review.
Does a protocol name prove every client uses basic authentication?
No. Make the decision from the actual sign-in’s Client App classification and policy evaluation, using the documented modern and legacy client categories. Do not retire a working application solely because its name resembles an older protocol.
Will this prevent every password attack?
No. Conditional Access is evaluated after first-factor authentication, not as a frontline denial-of-service defense. This runbook removes a specific authentication path; it does not replace credential protection, monitoring, or incident response.
Start with evidence from both user sign-in tabs, not a blanket exception list. Enforce the narrow client scope for a pilot, prove the business outcome, and widen only when the original dependencies are resolved.
Last reviewed: October 2026
Sources
- Block legacy authentication with Conditional Access (Microsoft Learn)
- Conditional Access report-only evaluation and results (Microsoft Learn)
- Conditional Access overview and license requirements (Microsoft Learn)
- Client-app conditions in Conditional Access (Microsoft Learn)
- Configure security defaults (Microsoft Learn)
- Sign-in logs in Microsoft Entra ID (Microsoft Learn)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.
