Require MFA to Register Security Information: MFA Reset and Registration Abuse Risk

Why this risk matters

Security information registration is the process by which users set up their MFA methods — adding an authenticator app, phone number, or security key. In a default configuration, many tenants allow users to register new MFA methods without first completing an existing MFA challenge. This means that if an attacker has obtained a user's password, they can sign in and immediately register their own authenticator device, effectively replacing or supplementing the user's MFA and giving themselves ongoing access.

Requiring MFA to register security information closes this gap. It means that adding a new MFA method requires the user to already have a working MFA method and to authenticate with it. An attacker who only has the password cannot register a new device because they cannot pass the existing MFA challenge.

This is sometimes called the "registration gate" and is a prerequisite for making the rest of your MFA policy meaningful. Without it, MFA can be bypassed through the registration flow rather than the authentication flow.

What happens if this is abused

  • Attacker with stolen credentials signs in and registers their own authenticator app before the legitimate user notices
  • Once a malicious MFA device is registered, the attacker can pass all subsequent MFA challenges for that account
  • Legitimate user is effectively locked out of their own MFA, since the attacker's device now controls the second factor
  • Account takeover is complete and persistent — the attacker has both the password and the MFA device
  • The registration event appears in audit logs but without an alert in place it may not be noticed until damage is done
  • Social engineering attacks against helpdesk teams may use this gap to register a new MFA device by pretending to be the user

When this is expected or acceptable

The main exception is during MFA rollout or onboarding:

  • New users who haven't yet set up any MFA method cannot satisfy an MFA requirement to register their first method — a temporary access pass (TAP) can be used as a secure, time-limited credential for initial MFA registration
  • Users who have lost access to all their MFA methods may need an admin-assisted reset process using a TAP before they can re-register

Temporary Access Passes are the recommended mechanism for handling both scenarios. They allow initial registration to happen securely without opening the registration gate to everyone.

Checks to perform before taking action

  • Confirm that the Temporary Access Pass feature is enabled in Entra ID (Authentication methods > Temporary Access Pass) so admins can issue TAPs for initial registration and account recovery
  • Ensure helpdesk staff understand how to issue a TAP for new users or users who have lost MFA access
  • Check whether any users currently have no MFA methods registered — these users will be blocked from registering without a TAP after enforcement
  • Review the Combined Security Information Registration experience is enabled (My Staff > Security info) so users are registering through the modern combined registration flow
  • Deploy in Report-only mode via a Conditional Access policy targeting the "Microsoft account management" or "User actions" condition

Safe remediation steps

  1. Enable Temporary Access Pass in Entra ID > Authentication methods and train helpdesk staff on issuing TAPs for onboarding and account recovery
  2. Create a Conditional Access policy scoped to All users, using the User actions condition targeting "Register security information"
  3. Set the grant control to Require MFA or Require authentication strength
  4. Deploy in Report-only mode and review impact
  5. Issue TAPs to any users with no existing MFA methods before enforcing, so they can complete initial registration
  6. Enforce the policy
  7. Update your onboarding process to include TAP issuance for new employees as a standard step before their first day

Related risks and follow-on checks

After enforcing this control, review these related areas:

  • Admins with Risky MFA Settings — ensure admin accounts are subject to the same registration gate, not excluded from this policy
  • Users with Risky MFA Settings — users with weak MFA methods should be guided to re-register with stronger methods; the TAP process supports this
  • Disable MFA alert — if MFA is disabled for a user, they should be required to re-register via a TAP-gated process before re-enabling
  • CA MFA Bypass Paths — review whether any Conditional Access exclusions inadvertently bypass the registration gate policy
  • Break-Glass Accounts — confirm emergency access account registration is handled separately and documented
TBD CTA