# Sign-In Risk-Based Multifactor Authentication. > This Conditional Access Policy requires multifactor authentication (MFA) for sign-ins that are determined to be risky, especially for administrator accounts. 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 | Setting | What it does | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Policy name | Specifies a display name for the Conditional Access Policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Enable policy | Specifies the state of the conditional Access Policy. Possible values are: enabled, disabled, enabledForReportingButNotEnforced. Required. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Included users | User IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Included roles | Role IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Included groups | Group IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Included guest types | Guest or external user types in scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Excluded users | User IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Excluded roles | Role IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | **6 more settings** | Setting | What it does | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Excluded groups | Group IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Excluded guest types | Guest or external user types excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | 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](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Included applications | The 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](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Client app types | Client application types included in the policy. Possible values are: all, browser, mobileAppsAndDesktopClients, exchangeActiveSync, easSupported, other. Required. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | | Sign-in risk levels | Sign-in risk levels included in the policy. Possible values are: low, medium, high, hidden, none, unknownFutureValue. Required. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk) | [Adding a baseline](https://docs.octiga.io/baselines/adding-a-baseline/) — Add, 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](https://docs.octiga.io/baselines/adding-a-baseline/)), or carry it in a scheme you deploy to every tenant you manage (see [Deploying a scheme](https://docs.octiga.io/baselines/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. > **Licence: Entra ID P1 or P2:** This baseline needs Entra ID P1 or P2 on the tenant. Without it, Octiga excludes the baseline rather than reporting it as deviated — see [Licence requirements](https://docs.octiga.io/reference/licence-requirements/). ## 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 ### CIS - **M365 5.2.2.6** — CIS M365 Foundations Benchmark 5.2.2.6 - **M365 5.2.2.7** — CIS M365 Foundations Benchmark 5.2.2.7 - **v8 13.3** — CIS Controls v8 Safeguard 13.3 ### NIST - **PR.AC-4** — NIST CSF 2.0 PR.AC-4 - **PR.PT-1** — NIST CSF 2.0 PR.PT-1 ### ISO 27001 - **A.8.3** — ISO/IEC 27001:2022 Annex A.8.3 - **A.8.3.3** — ISO/IEC 27001:2022 Annex A.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. [Deploying a scheme](https://docs.octiga.io/baselines/deploying-a-scheme/)