Skip to content
Copy as Markdown

Sign-In Risk-Based Multifactor Authentication.

ScopeTenantRoleL1 Read to view · L1 Read/Write to actLicenceEntra ID P1 or P2

This Conditional Access Policy requires multifactor authentication (MFA) for sign-ins that are determined to be risky, especially for administrator accounts. It helps prevent unauthorized access by adding an extra layer of security when suspicious activity is detected.

Settings this baseline controls

SettingWhat it does
Policy nameSpecifies a display name for the Conditional Access Policy Learn more
Enable policySpecifies the state of the conditional Access Policy. Possible values are: enabled, disabled, enabledForReportingButNotEnforced. Required. Learn more
Included usersUser IDs in scope of policy Learn more
Included rolesRole IDs in scope of policy Learn more
Included groupsGroup IDs in scope of policy Learn more
Included guest typesGuest or external user types in scope of policy Learn more
Excluded usersUser IDs excluded from scope of policy Learn more
Excluded rolesRole IDs excluded from scope of policy Learn more
6 more settings
SettingWhat it does
Excluded groupsGroup IDs excluded from scope of policy Learn more
Excluded guest typesGuest or external user types excluded from scope of policy Learn more
Grant controlsList of values of built-in controls required by the policy. Possible values: block, mfa, compliantDevice, domainJoinedDevice, approvedApplication, compliantApplication, passwordChange, unknownFutureValue Learn more
Included applicationsThe list of client IDs (appId) the policy applies to, unless explicitly excluded (in excludeApplications) All, Office365 - For the list of apps included in Office365. Learn more
Client app typesClient application types included in the policy. Possible values are: all, browser, mobileAppsAndDesktopClients, exchangeActiveSync, easSupported, other. Required. Learn more
Sign-in risk levelsSign-in risk levels included in the policy. Possible values are: low, medium, high, hidden, none, unknownFutureValue. 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

Add this baseline when a sign-in Microsoft judges risky (an unfamiliar location, an anomalous pattern, credentials seen in a leak) should need a fresh multi-factor challenge before it’s allowed through.

  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).

  2. Leave Included users covering everyone, and use Excluded users or Excluded groups for your organisation’s break-glass accounts.

  3. Leave Sign-in risk levels set to Medium and High. That pairing is Microsoft’s recommended starting point; Low is usually too noisy to enforce against.

  4. Leave Grant controls set to require multi-factor authentication. This is what challenges a risky sign-in; without it, the policy only observes it.

  5. Save.

    Turn on Auto-remediation if you want Octiga to reapply the policy whenever it’s changed in Microsoft 365.

Check it worked

After the next sync, this baseline shows Passing once a policy with state set to enabled, sign-in risk levels configured, and the multi-factor authentication grant control exists in Microsoft Entra. You can confirm it in the Microsoft Entra admin centre under Entra ID > Conditional Access > Policies. End users see an extra MFA prompt only on a sign-in Microsoft has judged Medium or High risk; other sign-ins are unaffected.

Standards this addresses

CISM365 5.2.2.6M365 5.2.2.7v8 13.3
NISTPR.AC-4PR.PT-1
ISO 27001A.8.3A.8.3.3

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.