Resetting somebody else's MFA
What Reset MFA actually removes, why it also clears their recovery codes, why you cannot use it on your own account, and how to be sure you are talking to the real person first.
Somebody on your team has a new phone, or lost the old one, and cannot get past the authenticator prompt. On the Users screen, open their row and choose Reset MFA. This is a real, immediate, administrator-only action — and it removes more than the one factor they lost, which is worth knowing before you use it.
Do it only when you have confirmed by another channel that you are talking to the right person — an attacker asking for an MFA reset is the most common way an account is taken over.
What Reset MFA actually removes
Two things, together, in one action: the enrolled authenticator, and every unused recovery code on the account — cleared deliberately, because the usual reason you are doing this reset is that the person's device, and possibly a printed or saved copy of their codes, is in someone else's hands, so leaving the old codes live would hand back exactly the access you just removed. It does not enrol them on anything, end their existing sessions, or remove a passkey they hold — see I enrolled MFA and cannot get in for the exact confirmation text and response shape from the affected person's side of the same action.
You cannot reset your own MFA this way, and that is deliberate
The admin Reset MFA control refuses to target your own account. This is not an oversight: proving you are signed in with a session is a weaker check than proving you hold the second factor, and letting the admin door double as a way to shed your own factor would make it a bypass for exactly the protection MFA exists to provide. If you need to remove your own factor, use the self-service path instead, which requires proving the very factor you are trying to remove before it lets you clear it.
Who can do it, and what it records
Resetting somebody else's MFA needs the users:write permission, held by the built-in admin role. It writes a privileged audit row — mfa.admin_disabled — naming who did it and who it was done to, so this is visible in Reading the audit log afterwards. Treat that row as the record you would show if anyone later asks why the reset happened.
What to do next
- Confirm identity out of band before you press the button — see the callout above.
- After resetting, tell the person directly that their next sign-in will ask for a new authenticator, so it does not read as a phishing prompt.
- If their phone was lost or stolen rather than merely replaced, also consider Revoking sessions on the account.
- Read Recovery codes so the person knows what their next set looks like once they re-enrol.