How to Detect MFA Method Registration Abuse: Attacker-Added Authenticators

Once an attacker has registered their own phone, authenticator app or security key on a victim's account, every later sign-in passes MFA, and a password reset alone does not remove them. This guide shows how to detect attacker-added authentication methods: which events record a registration, which combinations of signals separate an attacker from a user getting a new phone, how to sweep existing accounts for methods added before detection existed, and how to respond. It covers Google Workspace, Microsoft Entra ID and Okta (listed alphabetically), using each vendor's own logs and APIs. It is for SOC analysts, detection engineers and identity administrators. Preventing the registration in the first place (protected registration, Temporary Access Pass, phishing-resistant methods) is covered in the MFA Fatigue and Bypass Guide; this page is about finding the ones that got through.

Key takeaways

• Registration is persistence: ATT&CK T1098.005 Device Registration describes adversaries enrolling a new MFA device after compromising credentials, sometimes where self-enrolment needs only a username and password, and T1556.006 covers registering an adversary-controlled MFA method.
• A registration event alone is noise: people change phones every day. The signal is the registration combined with context: a risky or unfamiliar sign-in shortly before, a new country or network, a dormant account, a weaker method added beside a strong one, or one method shared across users.
• Every platform logs it: Google Workspace records 2sv_enroll, Microsoft Entra ID records combined-registration events in the Authentication Methods service, and Okta records user.mfa.factor.activate. Stream all of them to the SIEM.
• Sweep, do not only alert: methods registered before your rules existed are still there. Inventory every user's methods with their creation time and review the ones added near suspicious sign-ins.
• Response removes the method and the access: delete the rogue method, revoke sessions, reset the password, re-verify the user out of band and look for the other persistence an attacker leaves at the same time.

When you need this

• Help desk resets: a call that ends with "MFA reset" followed by a new registration from an unfamiliar network is the pattern described in social engineering campaigns attributed to Scattered Spider. See the Scattered Spider Threat Actor Profile and the Help Desk Social Engineering Incident Playbook.
• Accounts that never registered MFA: new joiners, dormant accounts and accounts exempted during a rollout are where ATT&CK notes that first-device enrolment may need only a password.
• After a phishing or token theft incident: attackers who hold a session often add a method so they can come back after the session is revoked.
• Before tightening registration policy: a sweep shows how many methods were added outside the controls you are about to introduce.

Before you start

• Exact strings: activity names and field names differ slightly between portal display and API output, and change over time. Confirm the current value in the vendor's docs and in a test registration in your own tenant before writing a rule; match on a stable substring where you can.
• Test registrations: register and remove a method on a test account in each platform and confirm the event arrives in the SIEM with the IP, user agent and method type you need.
• The sweep identity is privileged: reading every user's methods needs a directory-wide read permission. Give the collector its own non-human identity with the read-only permission, a named owner and a short-lived credential. See the Service Account Security Guide.

Step-by-step

1. Collect the events. Forward the three event families above into the SIEM, with actor, target user, method type, IP, location, user agent and result. In Entra ID, filter audit logs on the Authentication Methods service; in Okta, filter on event types beginning user.mfa.factor.; in Google Workspace, use the Reports API user accounts application.
2. Build a per-user baseline from 30 days of sign-ins: usual countries, networks (ASN or ISP), devices and user agents. The same 30-day comparison is what Microsoft uses in its alert-grading playbooks for mailbox rules, and it works the same way here.
3. Write the correlation rules in the table below. Start with the first three; they carry most of the value.
4. Run the sweep. List every user's registered methods with type, display name or device, phone number (masked if your role masks it) and creation time. Join each method created in the look-back period to the sign-ins around it. Microsoft's API examples show a creation timestamp on method objects; confirm the field name for each method type in the current Graph docs.
5. Find shared methods. Group methods by phone number, authenticator device name or hardware identifier. The same number or device on two unrelated users is either a shared team phone (to be fixed) or an attacker who enrolled one device into several accounts.
6. Tune in report mode for two weeks: record every hit, label it, and adjust thresholds before the rule pages anyone.
7. Wire the response (see below) so a confirmed hit leads straight to method removal and session revocation.

Detection rules

Triage questions

• Did the user do it? Ask through a channel the attacker does not control: a call to the number in the HR record or a manager, never the newly added phone.
• What happened before? Sign-ins, MFA prompts, password reset, help desk tickets for the user in the previous 48 hours.
• What happened after? Sign-ins satisfied by the new method, new inbox rules, OAuth consents, device registrations, role changes.
• Is it isolated? Search for the same IP, phone number or device across all users.

Verify it worked

• Replay: register a method on a test account from an unfamiliar network after a deliberately risky sign-in; the rule should fire within your target time.
• Removal: after a response, re-list the user's methods and confirm the rogue one is gone and no sign-in has used it since.
• Coverage: every identity provider in use, including any secondary tenant or org, sends registration events; the sweep covered every enabled user.

Measures that show it is working

• Median time from rogue registration to alert, and from alert to method removal.
• Share of registrations in the last quarter that happened under a protected registration policy or with a Temporary Access Pass.
• Number of methods shared across users (target zero, with named exceptions).
• Privileged accounts holding only phishing-resistant methods.
• Confirmed rogue registrations found by the sweep rather than by an alert (should fall as rules mature).

Responding to a rogue method

1. Preserve evidence: export the registration event, the method details and the surrounding sign-ins before deleting anything.
2. Remove the method through the admin console or API, and remove any other method added in the same window.
3. Revoke sessions and refresh tokens, then reset the password. Revoking first stops the attacker from re-registering with an open session.
4. Re-establish the user through verified identity proofing (in person, video with ID, or a manager-confirmed process) and issue a one-time enrolment credential such as a Temporary Access Pass for re-registration. See the Account Recovery and Help Desk Security Guide.
5. Hunt for companion persistence: forwarding and hiding rules (see the T1114 Email Collection Defensive Guide), device registrations (see Rogue Device Registration), OAuth consents and role changes.
6. Notify: NIST SP 800-63B-4 Sec. 4.1.2.1 requires the credential service provider to notify the subscriber when an authenticator is added, through a mechanism independent of the binding transaction. If those notifications already exist, check why the user did not report the alert.

Rollback and common errors

• Removed a legitimate method: the user re-registers through the normal verified process; keep this path fast so analysts are not reluctant to act.
• Alert floods during a rollout: suppress by planned rollout group and date, not by turning the rule off.
• Corporate VPN or proxy egress looks like one user: mark corporate egress ranges so the "unfamiliar network" rule does not fire on every office registration and the "burst" rule does not fire on the whole company.
• Help desk resets with no ticket link: without the ticket the "reset then register" rule cannot tell a real request from a social-engineered one. Require a ticket reference on every reset.
• Collector permission left in place: the sweep identity that reads every user's methods is a target in its own right; scope it to read and review it with other privileged non-human identities.

Hardening afterwards

• Protect the registration action: Microsoft's recommended Conditional Access policy targets the user action "Register security information" for all users, excludes trusted locations and requires an authentication strength, with Temporary Access Pass for new users; Microsoft announced that from 6 July 2026 such policies also apply to Windows Hello for Business and macOS Platform SSO registration. Use the equivalent enrolment policy in other identity providers. See the Conditional Access Guide.
• Require strong authentication to bind: SP 800-63B-4 Sec. 4.1.2.1 requires authentication at the maximum AAL available in the account, or the AAL the new authenticator will be used at, whichever is lower, before binding an additional authenticator.
• Move privileged users to phishing-resistant methods only and remove SMS and voice from them. See the Phishing-Resistant MFA Guide.
• Close the never-registered gap: disable or re-verify accounts that have not registered MFA within a set period after creation.

Framework mapping

Practitioner checklist

• Stream registration, removal, reset and default-change events from every identity provider to the SIEM.
• Confirm exact event names with a test registration in each platform.
• Build 30-day sign-in baselines per user and mark corporate egress ranges.
• Deploy the risky-sign-in, unfamiliar-network and reset-then-register rules first, in report mode.
• Sweep all users' methods, join creation times to sign-ins and find shared methods.
• Respond in order: preserve, remove, revoke, reset, re-verify, hunt for companion persistence.
• Protect the registration action and require strong authentication to bind new methods.
• Scope and review the identity that reads every user's methods.

Standards and references

• MITRE ATT&CK: Account Manipulation: Device Registration (T1098.005)
• MITRE ATT&CK: Modify Authentication Process: Multi-Factor Authentication (T1556.006)
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• Google for Developers: Admin SDK Reports API, User Accounts activity events
• Microsoft Learn: Troubleshoot combined security information registration
• Microsoft Learn: Require secure security info registration
• Microsoft Learn: List authentication methods (Microsoft Graph)
• Okta Developer: Event types

Related NHI Mgmt Group resources: MFA Fatigue and Bypass Guide · MITRE ATT&CK T1098 Account Manipulation Guide · Entra ID Sign-In and Audit Log Detection Guide · Okta System Log Detection Guide · Google Workspace Audit Log Detection Guide