Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Remove Authentication Method [FIX-9008]

This remediation deletes a single, specified authentication method from a user. It is used to remove a rogue MFA method (an authenticator app, phone number, FIDO2 key, software OATH token, Temporary Access Pass, or email method) that an attacker registered on a compromised account to maintain access.

The target identifies the user, the method type, and the specific method id, so only that one method is removed and the user's legitimate methods are left untouched.

The password method cannot be removed this way; it can only be reset (see FIX-9003). If the targeted phone number is the user's default MFA method, Microsoft Graph refuses to delete it until the default method is changed; in that case the remediation reports the method as not removed.

Rationale

Once an attacker has taken over an account, registering their own authentication method is one of the most common persistence techniques (MITRE ATT&CK T1098.005 – Account Manipulation: Device Registration). A self-enrolled authenticator app or phone number survives a password reset and session revocation: the attacker simply completes MFA with the method they control and signs back in. Incident responders who only reset the password and revoke sessions frequently miss this and hand the account straight back to the adversary.

Removing the attacker-controlled method severs that persistence. Because this remediation is surgical (it deletes exactly the method you point it at rather than wiping all of the user's methods), it avoids unnecessarily locking the legitimate user out of every factor. After the rogue method is gone, follow up with a password reset and session revocation so the attacker has no remaining path back in.

This remediation calls DELETE on the relevant Microsoft Graph authentication-method endpoint and then verifies the method is gone (a follow-up read returns HTTP 404). It requires the UserAuthenticationMethod.ReadWrite.All permission on the Attic application; an Authentication Administrator or Privileged Authentication Administrator role is needed for delegated use.

Fix

An automated fix is available through Attic.

Manual steps:

  1. Navigate to the Entra ID portal at https://entra.microsoft.com
  2. Go to Users > All users
  3. Search for and select the affected user
  4. Open Authentication methods
  5. Locate the suspicious method and click Delete
  6. Confirm the method no longer appears in the user's method list

Impact

  • The specified authentication method is removed and can no longer be used to satisfy MFA.
  • Only the targeted method is affected; the user's other registered methods continue to work.
  • The password method cannot be removed; reset it with FIX-9003 if credential compromise is suspected.
  • If the removed method was the user's only strong method, they will be prompted to re-register MFA at next strong-authentication sign-in.
  • Deleting a phone that is the user's default MFA method fails until the default is changed; the remediation reports this per target.
  • Combine with FIX-9005 (revoke sessions) and FIX-9003 (password reset) for full account recovery.

Revert

The method is deleted rather than disabled, so it cannot be restored — reverting means registering a replacement method.

If the user still has another working method, they can add a new one themselves at https://aka.ms/mysecurityinfo.

If the removed method was their last one, they cannot reach the registration page and an administrator must unblock them with a Temporary Access Pass:

  1. Navigate to the Entra ID portal at https://entra.microsoft.com
  2. Go to Users > All users and select the user
  3. Open Authentication methods and click Add authentication method
  4. Choose Temporary Access Pass, set a short lifetime and one-time use, then click Add
  5. Verify the user's identity out of band, then hand over the pass through a secure channel — never by email or chat, and never to a caller you have not verified
  6. The user signs in with the pass at https://aka.ms/mysecurityinfo and registers a new method
  7. Confirm the new method appears, then confirm the Temporary Access Pass is consumed or delete it

Temporary Access Pass must first be enabled under Protection > Authentication methods > Policies. If it is unavailable, the fallback is for an Authentication Administrator to register a phone method on the user's behalf from the same Authentication methods page.

Verify who you are talking to before issuing a pass. A Temporary Access Pass is a full MFA bypass, and a helpdesk-issued credential is exactly what the attacker was after in the first place.

More Information