Block Legacy Authentication

This Conditional Access Policy blocks the use of legacy authentication methods that do not support modern security controls. Blocking legacy authentication helps prevent credential-based attacks and enforces stronger security standards.

Settings this baseline controls

Setting	What it does
Policy name	Specifies a display name for the Conditional Access Policy Learn more
Enable policy	Specifies the state of the conditional Access Policy. Possible values are: enabled, disabled, enabledForReportingButNotEnforced. Required. Learn more
Included users	User IDs in scope of policy Learn more
Included roles	Role IDs in scope of policy Learn more
Included groups	Group IDs in scope of policy Learn more
Included guest types	Guest or external user types in scope of policy Learn more
Excluded users	User IDs excluded from scope of policy Learn more
Excluded roles	Role IDs excluded from scope of policy Learn more

4 more settings

Setting	What it does
Excluded groups	Group IDs excluded from scope of policy Learn more
Excluded guest types	Guest or external user types excluded from scope of policy Learn more
Grant controls	List of values of built-in controls required by the policy. Possible values: block, mfa, compliantDevice, domainJoinedDevice, approvedApplication, compliantApplication, passwordChange, unknownFutureValue Learn more
Client app types	Client application types included in the policy. Possible values are: all, browser, mobileAppsAndDesktopClients, exchangeActiveSync, easSupported, other. Required. Learn more

Adding a baselineAdd, configure or remove a single baseline on a tenant, a user or a group, without deploying a whole scheme.→

Configure it

This baseline is a Conditional Access policy, and you set it like any other baseline: directly on a tenant, or once inside a scheme (Schemes) that you deploy to many tenants, using the fields in the settings table above.

1. Add the baseline to the tenant directly (see Adding a baseline), or carry it in a scheme you deploy to every tenant you manage (see Deploying a scheme). Give the policy a Policy name your team will recognise later.

2. Set Enable policy to enabled to enforce it, or to enabledForReportingButNotEnforced to see who it would affect before it blocks anyone.

3. Leave Included users and Included roles empty to apply the policy to everyone, or scope it to specific users, roles or groups with Included users, Included roles and Included groups. Use Excluded users, Excluded roles and Excluded groups for accounts that still need legacy access, most commonly a small number of service accounts.

4. Leave Client app types set to legacy protocols only (exchangeActiveSync, other) so the policy targets legacy authentication without also catching modern browser and app sign-ins.

5. Leave Grant controls set to block. The baseline denies legacy authentication outright rather than adding a second factor to it.

Caution

A small number of older devices, mail clients and line-of-business applications still rely on legacy authentication protocols, and lose access as soon as this policy is enforced. Before you enforce it, check the tenant for recent legacy-protocol sign-ins and add any accounts that still need time to migrate to Excluded users or Excluded groups.

Check it worked

After the next sync, the tenant’s baseline status shows this baseline as Passing once the policy exists in Microsoft Entra with the fields above and state set to enabled (or enabledForReportingButNotEnforced, if that’s what you chose). If it shows as Deviated, the “Currently set to” value on the affected field shows what Microsoft 365 has. Usually the policy doesn’t exist yet, is disabled, or no longer matches the Client app types or Grant controls this baseline requires.

Standards this addresses

CISM365 5.2.2.3v8 4.8

NISTPR.PT-1AC-17IA-5

ISO 27001A.8.15A.8.16

GDPRArticle 32

Doing this for every tenant?

Step through the deploy wizard to apply a scheme to a tenant, groups or users, and see what Managed and Direct do at deploy time.

Deploying a scheme→