Somebody replaces their phone, or wipes it, or simply deletes the authenticator app while tidying up. Their password still works and their second factor is gone, so they can't get into their mail. A webmail 2FA lockout is one of the most common support requests in any organization that took security seriously, and it's entirely predictable.
This page covers how to resolve one, why the resolution has to be deliberate rather than automatic, and the small preparations that make it a two-minute job instead of an afternoon.
Why This Happens So Often
Two-factor is set up once, on one device, at a moment when the person is thinking about getting into their mail rather than about what happens if the device disappears.
Recovery codes are offered and generally ignored, because at that moment they look like homework. Phones then get replaced roughly every three years, and unless the authenticator app was backed up or migrated deliberately, the codes don't come across. A webmail 2FA lockout is therefore not a sign anyone did anything wrong — it's the predictable consequence of a device lifecycle.
Which is worth remembering when it happens, because the person locked out usually feels foolish and isn't.
The Two Ways Out
There are exactly two, and the first is the only one you can act on yourself.
A recovery code. These are issued at enrolment and they are the self-service route. The user signs in with their password, presents a recovery code instead of an app code, and can then remove the old second factor and enrol a new device from webmail settings. No administrator is involved at any point.
Contacting us. If the recovery codes are gone too, the second factor has to be cleared on our side. This is a support action rather than something in your dashboard, and it is deliberately not self-service — an account owner who could silently strip 2FA from any mailbox would be a more useful target than the mailbox itself.
Worth being clear about what the customer dashboard does and doesn't offer here, because it looks like it should help. The mailbox security page shows whether two-factor is active and when it was confirmed, and it can change the mailbox password. It cannot clear the second factor. Changing the password does not resolve a webmail 2FA lockout, because the password was never the thing blocking them.
However the factor is cleared, the user should re-enrol immediately rather than "later". A mailbox that has been through a webmail 2FA lockout and is now running on a password alone is exactly the one you'd least like left that way.
Confirm Who You're Talking To
Before you escalate a webmail 2FA lockout on somebody's behalf, confirm the request is genuine. This is the step people skip, and it's the one that matters.
A request to remove someone's second factor is, from an attacker's point of view, among the most useful things they can get a colleague to ask for. It arrives by email or chat, sounds routine, and gets passed along because the person seemed to know what they were talking about.
So verify out of band. If the request came by email, telephone them. If it came by chat, ask something an impersonator wouldn't know, or confirm in person. The check takes a minute, and the fact that the final action sits with support rather than with you is a second layer rather than a reason to skip the first.
Be particularly careful when the request is urgent, apologetic and slightly flustered. That's the texture of a genuine webmail 2FA lockout and it's also exactly how a social engineering attempt is staged, because urgency suppresses verification.
Preparing So It's Trivial
Three small things turn this from an incident into an errand.
Make recovery codes part of enrolment. Not an optional extra afterwards — part of the same conversation, with somewhere specific to keep them. A password manager is the obvious place, and printing them is a perfectly reasonable alternative.
Encourage a second enrolled device where sensible. A tablet or a second phone means a lost device is an inconvenience rather than a lockout.
Write down the escalation path. When a webmail 2FA lockout happens, the user needs to know who to tell, and that person needs to know the route runs through support rather than through the dashboard. Discovering that mid-incident wastes an afternoon.
None of this prevents lockouts, and it isn't meant to. It makes them cheap — and recovery codes are the single thing that turns a support ticket into a two-minute self-service fix, which is why they deserve more insistence than they usually get.
Two Cases That Only Look Like Lockouts
Two situations look identical to the user and need entirely different responses.
Codes being rejected while the app still works. This is usually clock drift — time-based codes under RFC 6238 depend on the device clock being roughly correct, and a phone that has drifted by more than a minute produces codes that fail. Enabling automatic time sync fixes it, and no reset is required.
The wrong account. People with several addresses sometimes enrol one and try to log into another, or use the wrong entry in their authenticator. Worth checking before resetting anything.
There's also the case where the user is logging in at the wrong place entirely. Mailbox users sign in through the webmail login rather than the account dashboard, and a password that works in one won't work in the other — which presents as a mysterious failure rather than an obvious one.
Whether to Require It At All
Since lockouts are the cost, it's fair to ask whether the benefit is worth it.
For any mailbox that receives password resets for other services — which is nearly all of them — the answer is straightforwardly yes. An email account is the recovery route for everything else, so it's the account worth protecting most, and a webmail 2FA lockout resolved with a recovery code is a small price against a compromised mailbox.
Where it's genuinely awkward is shared operational addresses that several people use. The better answer there isn't skipping the second factor; it's not having a shared login at all, and using a shared mailbox with membership instead, so each person authenticates as themselves.
The same principle underlies enrolment generally: the credential should belong to a person, which is why invites let users set their own and why administrators never need to know them, as described in setting up mailboxes without sharing passwords.
