# Securing Security Info Registration > This Conditional Access Policy ensures that users register their security information (such as MFA methods) in a secure manner. This Conditional Access Policy ensures that users register their security information (such as MFA methods) in a secure manner. It helps protect accounts by requiring secure registration processes and reducing the risk of compromised authentication methods. ## 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-registration) | | 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-registration) | | 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-registration) | | 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-registration) | | 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-registration) | | 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-registration) | | 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-registration) | | 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-registration) | **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-registration) | | 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-registration) | | 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-registration) | | Included locations | Locations included in the policy. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-registration) | | Excluded locations | Locations excluded from the policy. [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-registration) | | Included user actions | User actions to include. Supported values are urn\:user\:registersecurityinfo and urn\:user\:registerdevice [Learn more](https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-registration) | [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 users registering their MFA methods for the first time should do so only from a trusted network, such as your office or VPN range. Registration is when someone's security info is weakest, before any second factor is in place to protect it. 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 **Included user actions** set to registering security information. This targets the registration step itself, not ordinary sign-ins to other applications. 4. Leave **Included locations** set to any location and **Excluded locations** set to all trusted locations, so the policy applies only outside your trusted network. Named locations are configured separately in Microsoft Entra, so set those up first. 5. Leave **Grant controls** set to require multi-factor authentication. 6. **Save.** Turn on **Auto-remediation** if you want Octiga to reapply the policy whenever it's changed. > **Caution:** New starters registering their first MFA method off your trusted network have no second factor to satisfy this policy with yet, so they need another way in, typically a Temporary Access Pass issued by an administrator. > **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`, the security-info-registration user action, the trusted-location exclusion, 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**. Users registering security information from off your trusted network are asked for MFA first; from within it, nothing changes. ## Standards this addresses ### CIS - **M365 5.2.2.x** — CIS M365 Foundations Benchmark 5.2.2.x - **v8 6.3** — CIS Controls v8 Safeguard 6.3 ### NIST - **PR.AC-7** — NIST CSF 2.0 PR.AC-7 - **IA-2** — NIST SP 800-53 IA-2 - **IA-5** — NIST SP 800-53 IA-5 ### ISO 27001 - **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/)