For now, administrators can strip authentication factors from an account by following this guide, although from the discussion in the task linked to T7309 it looks like you're already aware of that:

https://secure.phabricator.com/book/phabricator/article/multi_factor_auth/#recovering-from-lost-fac

After we add backup codes users will still sometimes lose their phone and their backup codes (and attackers will always un-provably claim that they have lost or never wrote down the backup codes), so this feature will only reduce the administrative overhead of TOTP somewhat.

We are also technically (not necessarily chronologically) close to having SMS support; this will require use of a third-party SMS provider, but might be another way to reduce this overhead (e.g., in the case of a damaged device with an intact SIM card, I think recovery is pretty quick? Not sure about lost devices).

(On the other hand, I'm a little skeptical of how secure SMS is as an authentication factor: my SMSes are currently delivered unpredictably to one or more or all of the Apple-branded devices I own, all at once or at different times, as dictated by whim and chance. Many theoretical attackers who could compromise my primary account credentials could also compromise factors delivered over SMS by overcoming barriers much lower than TOTP. The SMS provider will also be well-positioned to compromise accounts.)

For the case of not letting users use MFA because the administrative overhead associated with factor loss is a bigger problem than unauthorized access, we're also potentially open (see also T6115) to letting user accounts have a setting like "Multi-Factor Auth: Required / Optional / Forbidden" or similar, although we'd like to see use cases justifying this in the wild (i.e., actual overhead caused by users losing factors) before pursuing it, because it may be possible to satisfy the needs for this with simpler rules (e.g., just a "required for administrators" flag). I suspect we'll end up with both a per-account flag and some group-requirement mechanism, but it would be nice to avoid building this if we don't really need it.

Another thought is that we could possibly implement a "timed unlock" mechanism like this:

• We send email to every address (and SMS to every phone number) associated with the account, plus some list of administrative addresses, with a link to cancel the unlock.
• We wait 48 or 72 or some other number of hours.
• If, within this time period, none of the links have been clicked, no valid sessions have been used, and no one has logged in to the account up to the factor screen and clicked "do not unlock", we strip the authentication factors.

This is a much lower barrier than "mail us your passport" or "meet physically and execute a prearranged secret handshake", but still a significant barrier (attackers must compromise everything all at once, not compromise a user known to administrators, and not alert the user).

I'm not sure if there is a 48/72/X hour number which is both short enough to be reasonable and long enough to resist attacks, however. One thing we could do is that, in Calendar, if you've provided us the information, we know about scheduled vacation, holidays in your locale, and your workweek definition. We could stop the timer from ticking during these times: so a 48 reset on a Friday before a long weekend would pause for Saturday, Sunday and Monday and start ticking on Tuesday, opening up on Wednesday. If you'd marked yourself as away for 3 weeks in Calendar (e.g., taking a vacation) prior to "losing" your MFA token, we'd similarly stop the timer.

If we had reliable access to this information, this might defuse the most obvious attacks and let us reasonably shorten the timer window to something which could make this plausible.

This feels a little far afield, and kind of complex, and I'm not aware of similar implementations in other systems and am not excited about "rolling our own" security mechanisms, but I can't immediately come up with any reasons why it's a completely terrible idea, especially if the underlying Calendar data gets to a place where it's pretty reliable.

We could also commit to this only halfway and let it be used only "low-importance" accounts, but at some point anything in this vein sort of becomes a WMF-only feature because it's unlikely that most installs will have enough factor-related administrative overhead to justify this. We'd likely prefer to just have a "MFA: Forbidden" flag to deal with the overhead issue, rather than a complex mechanism which is ultimately only suitable for low-security recovery.

See also T9515 and T7639 for "choose some other users to trust, if you lose your phone they can vote to strip your MFA".