Skip to content
Copy as Markdown

Securing Security Info Registration

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

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

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 locationsLocations included in the policy. Learn more
Excluded locationsLocations excluded from the policy. Learn more
Included user actionsUser actions to include. Supported values are urn:user:registersecurityinfo and urn:user:registerdevice 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 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), 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 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.

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

CISM365 5.2.2.xv8 6.3
NISTPR.AC-7IA-2IA-5
ISO 27001A.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.