Entra ID Security Info Registration: Why You Need a Conditional Access Policy to Protect It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Security info registration is a bootstrapping problem: to register MFA you need to authenticate, and to authenticate you need MFA -- or just a password, if no policy protects the registration endpoint. In most Entra ID tenants, the registration page has no special CA protection. Any password-authenticated session can add MFA methods. Attackers discovered this gap early: it is faster and more reliable to register a new MFA method than to intercept an existing one. A single CA policy targeting the Register security information user action closes this with no user experience impact for legitimate users.
Create the CA Policy for Security Info Registration
In the Entra admin center, navigate to Security > Conditional Access > New policy. Name: 'Protect MFA Registration'. Assignments > Users: All users (include all users -- no exceptions except break glass accounts). Target resources > What does this policy apply to: User actions > Register security information. Grant: Require authentication strength -- choose Phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based) if you are deploying phishing-resistant auth broadly. If you are not yet there, choose 'Require multifactor authentication' (any registered MFA method). For new accounts that have no MFA registered yet: they cannot satisfy MFA to register MFA -- this is the bootstrapping problem. Solve it with Temporary Access Pass (see next section). Enable: On. This policy means: before adding, changing, or removing any authentication method, the user must satisfy the MFA grant control. An attacker with only a password is blocked at this step.
Solve the Bootstrap Problem with Temporary Access Pass
When a new employee joins or when an existing user loses all their MFA methods, they cannot satisfy an MFA requirement to register new MFA methods. The solution is Temporary Access Pass (TAP) -- a time-limited, one-time passcode issued by an admin that satisfies MFA requirements for the security info registration session. TAP usage: IT issues a TAP via the Entra admin center or PowerShell (New-MgUserAuthenticationTemporaryAccessPassMethod -UserId [UPN] -Properties @{IsUsableOnce=$true; LifetimeInMinutes=60}). The user navigates to mysignins.microsoft.com/security-info and signs in with their password + the TAP code. The TAP satisfies the CA policy protecting registration. The user registers their authenticator app or passkey. TAP expires (it is one-time and short-lived). Now the user has a real MFA method and future registrations go through normal MFA. The IT admin never needs to know the user's password and the user's registration session is protected by the TAP. TAP must be enabled in the Entra admin center: Security > Authentication methods > Temporary Access Pass > Enable.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Additional Hardening for the Registration Policy
Beyond the basic MFA requirement, consider these enhancements to the security info registration CA policy. Require compliant device or Entra joined device: if your MFA registration should only happen from corporate-managed devices, add a device compliance requirement. This prevents an attacker who has stolen credentials and a personal device from registering new methods. Named location restriction: restrict MFA registration to corporate IP ranges or named trusted locations -- registration from a coffee shop or residential IP at 2 AM for an executive account is suspicious. Require sign-in risk = None: do not allow registration sessions from risky sign-in contexts. Apply an Identity Protection policy that blocks registration when sign-in risk is medium or high. Monitor registration events: Entra ID audit log > Authentication methods > Operation: User registered security info or User changed default security info. Alert on: MFA method registration for accounts that had no prior methods, registration outside business hours, registration from IP addresses inconsistent with the user's normal location.
Protect SSPR Registration and Password Changes
The security info registration CA policy also covers SSPR (Self-Service Password Reset) method registration, since SSPR methods are configured at the same security info page. However, password changes and resets may use separate flows that need their own CA coverage. For password change (users changing their own password): this is a separate CA user action -- 'Register or join devices' is a different action; password change is governed by the 'Change password' action in CA (available for user action targeting in newer CA policy versions). For admin-initiated password resets: these flow through the admin portal and are covered by the admin portal CA policy. Verify the full authentication lifecycle: initial registration (TAP + CA policy), MFA method change (existing MFA + CA policy), password change (MFA + CA policy for password change action), account recovery (TAP from IT if lockout). Each step in this lifecycle should require a satisfying authentication action that prevents a password-only session from making changes.
Audit Existing MFA Registrations for Anomalies
Before deploying the CA policy, audit current MFA registration state to identify potential existing compromises. PowerShell: Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Select-Object UserPrincipalName, IsMfaRegistered, IsMfaCapable, IsPasswordlessCapable, MethodsRegistered | Export-Csv mfa-registration-report.csv. Look for: accounts with only a phone number registered (easiest to SIM-swap or phish), accounts that recently changed their registered MFA method (within the past 30 days), accounts with no MFA registered but no enforcement CA policy blocking them. Review the audit log for the past 30 days of registration events: Entra admin center > Audit logs > filter by Category: User Management and Activity: Update user > find 'StrongAuthenticationMethod' in the additional details. Any recent registration event for a high-privilege account (Global Admin, Exchange Admin) warrants individual review.
The bottom line
Protecting the security info registration user action with a CA policy requiring MFA is a one-policy fix that closes a significant account takeover path. Without it, a stolen password is sufficient to register new MFA methods and fully take over an account. Deploy Temporary Access Pass to handle the bootstrapping problem for new accounts and MFA recovery. Alert on MFA registration events -- legitimate users rarely need to register new methods outside of onboarding.
Frequently asked questions
Does this policy affect users who are registering MFA for the first time during onboarding?
Yes, which is why Temporary Access Pass is the designed solution for initial registration. The policy blocks registration without MFA, which catches attackers -- but it also blocks new users who have no MFA yet. Your onboarding process must issue a TAP to every new employee before they attempt to register their authenticator app. Alternatively, create a time-limited policy exception for new accounts (exclude accounts created in the last 24 hours) while ensuring those accounts are required to register MFA during their first session via the Authentication Methods registration campaign feature.
What happens if a user registers a new MFA method from an unfamiliar device using their existing MFA?
If the CA policy only requires MFA (not a compliant device), a user who satisfies MFA from any device -- including a personal phone or unmanaged laptop -- can register new methods. The policy verifies that MFA was satisfied, not that the device is managed. To require a managed device for registration changes, add a device compliance requirement to the CA policy. This is a stricter posture that some organizations choose for high-security environments. For most environments, requiring MFA (without device compliance) for registration is an appropriate balance between security and usability.
Can I prevent users from removing MFA methods as well as adding them?
The CA user action 'Register security information' covers both adding and removing authentication methods -- both operations go through the mysignins.microsoft.com/security-info page and trigger the same CA policy evaluation. The policy protects both directions: an attacker cannot add a new method, and an attacker who has somehow satisfied MFA cannot remove the victim's existing methods without re-satisfying MFA. This means a support impersonation attack ('I'm IT, please remove your authenticator') would also require the victim to authenticate via MFA before the method removal succeeds.
Is there a Microsoft report that shows accounts with no MFA registration?
Yes. In the Microsoft 365 admin center > Users > Active users > filter by 'MFA status: disabled'. In the Entra admin center: Identity > Users > All Users > MFA column (may require enabling the column). Via the Authentication Methods Activity report (Entra admin center > Protection > Authentication methods > Activity): shows accounts by MFA registration status across the tenant. Via PowerShell with the Graph SDK: Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "isMfaRegistered eq false" shows all accounts without MFA registered -- these accounts are the highest priority to address before deploying the registration protection policy.
What is a Temporary Access Pass and how does it differ from a one-time passcode?
A Temporary Access Pass (TAP) is a time-limited, PIN-based credential issued by an administrator that allows a user to register their first MFA method without first having MFA. It is issued in the Entra admin center or via Graph API, is valid for a configurable duration (minutes to hours), and can be set as single-use or multi-use. A one-time passcode (OTP) is typically a 6-digit TOTP code sent via email or SMS as an MFA method itself. TAP is used for bootstrapping (getting the first authentication method registered on a new or recovered account), while OTP is used for authentication verification. TAP is far more powerful -- it bypasses MFA requirements -- so it must be issued only through a verified IT channel and should expire quickly (30 minutes is a common setting).
How do you protect the MFA security info registration process from being abused by an attacker who has already compromised a user's password?
The attack scenario: an attacker obtains a user's password through phishing or credential stuffing and uses it to register a new MFA method before the user does, gaining persistent access even after the password is changed. The primary defense is Conditional Access for Security Info registration. Create a CA policy targeting the 'My Security Info' registration action (under Authentication context) that requires either an existing MFA method (which an attacker without the victim's MFA device cannot satisfy) or requires the session to originate from a known compliant device or trusted network. Additionally, enable Microsoft Entra ID Protection to block sign-ins with medium or high user risk -- a sign-in from an unfamiliar IP attempting to register new MFA methods should trigger a risk score that blocks the registration. Restrict Temporary Access Pass issuance to Privileged Authentication Administrators and require the TAP to expire within 30 minutes. Monitor Entra audit logs for 'User registered security info' events occurring from unusual locations or within minutes of a successful password authentication -- this pattern indicates an attacker registering MFA before the legitimate user.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.