MFA Device Lost Runbook

A lost phone with your only authenticator isn't an IT ticket — it's a lockout with a deadline, and the deadline is whenever the phone turns up in someone else's pocket. This is the runbook for the hour it happens: verify the human out-of-band before anything is reset, reset in the right order, keep the business running through the lockout window, and harden the setup so the next lost phone is a two-minute job.

1. The real risk isn't the lockout — it's the window

• The phone and the account are still paired. Lost does not mean wiped: the TOTP app or push prompt on that device can still approve logins until someone acts. Treat "MFA device lost" as "second factor compromised until proven otherwise" — the same assumption as the API key leak runbook: you don't wait to find out.
• Lockout is when people get phished. A locked-out employee who "just needs back in" is exactly the state attackers exploit — and exactly when your help desk instincts are weakest. The verification step below exists as much for the phisher who calls two hours later claiming to be the same employee as for the real one.
• Announce it internally, briefly. One line to the team: "Alex's phone is lost, MFA resets are in progress, expect verification calls." Social-engineering attacks ride on the gap between what happened and what people know happened.

2. Verify the human before you touch anything

• Out-of-band, live, and not the lost channel. Video call with a face you know, or a call to a number on file that is not the lost phone. Never verify over the same channel that was lost — email to the address reachable from the lost device is not verification, it's theater.
• Two checkpoints minimum. Face-to-name (a live camera), plus a knowledge check your HR data can confirm (start date, last expense report, the manager who interviewed them). This is the same discipline the first 30 minutes runbook applies to an incident: confirm the reality before you start changing state.
• Write down who verified whom, and when. The reset log entry: verifier, requester, channel, timestamp. If the phone later surfaces in a fraud attempt, this line is the difference between an audit note and an incident with no timeline.

3. Reset in the right order

• Kill the old factor first, then enroll the new one. Admin console: revoke the lost device's MFA registration (not "reset password" — the password was never lost). In most consoles this is "revoke MFA methods" or "require re-enrollment"; the lost factor dies the moment you do it, which closes the compromise window. Enroll the replacement — a new TOTP app on a device the employee still holds — immediately after.
• Session revocation is part of the reset. Sign the account out everywhere and revoke refresh tokens: the old phone may hold active sessions that survive an MFA change. The Slack checklist's session-revocation drill, applied to the whole account.
• Sweep what the lost phone could reach beyond login. If it held the password manager app, rotate the master password and check for exports; if it was the backup email's second factor, that chain breaks too. The lost device is a keyring, not a key — inventory what hung off it before you call it done.

4. Keep the business running through the lockout

• The shared mailbox trick for the dead hours. If the account is the one customers email, forward to a live teammate while the reset completes — then turn the forwarding OFF (the employee offboarding checklist explains why silent forwarding is the classic hole; same rule, different trigger).
• Admin work doesn't wait for one phone. A second admin (or the break-glass account, below) covers the console actions the locked-out person owned. If the lost phone belonged to your only admin — that is the scenario this runbook exists for, and the reason every small team needs a second admin seat with MFA enrolled.
• Print the waiting-room rule. During the lockout window, the employee changes nothing else: no new passwords, no device re-pairing from the lost phone if it pings back, no "helpful" workarounds someone emails them. One incident at a time.

5. The break-glass account (build it the day after, not the day of)

• One admin account that exists only for disasters. A cloud-only admin identity, excluded from conditional access, with a long generated password in a sealed envelope or offline vault, no SMS, and TOTP you can afford to lose — documented in the Microsoft 365 checklist and the Google Workspace checklist. It exists so that "the admin lost their phone" is an annoyance, not a hostage situation.
• Test it quarterly and log every use. An untested break-glass account is a myth with a password. Sign in with it once a quarter, from the documented runbook, and record the test. Every real use gets the incident-timeline treatment — who used it, why, when it was re-sealed.

6. Recovery codes: the ten-minute fix everyone skips

• Backup codes exist precisely for this day. Every provider that offers one-time backup codes should have them generated, printed or stored in the password manager's secure notes, and inventoried at rollout — the MFA rollout checklist should have made this a gate. If your team skipped it, run it now: one hour, every employee, codes generated and filed.
• Codes are single-use, and that's the audit. A used backup code should be replaced the same week; a "I used my backup code" event is a small flag worth logging — lost device, or just cleared browser? Either answer is a note in the same register.
• The second factor is a pair, not a hero. Two enrolled factors (phone TOTP + a hardware key or the manager's TOTP) means a lost phone is a five-minute re-enroll. The passkeys rollout changes the shape — passkeys sync across devices — but the principle is identical: never exactly one factor.

7. Harden before the next phone goes missing

• The quarterly 15-minute pass: every employee has at least two working factors, backup codes exist and are current, at least two admins exist with independent factors, the break-glass account has been tested, and the password manager master password recovery path is documented. This is the same cadence as the annual security review, scoped to factors.
• Rehearse it once, for real. Pick a quiet Friday afternoon: an admin revokes a volunteer's MFA, the runbook runs end to end — verification, reset, re-enroll, forwarding cleanup. Twenty minutes, once. The first real loss should be the second time you've done this, not the first.
• And when the lost phone is a lost laptop instead — the lost laptop runbook is the device-loss sibling of this page: same verification reflex, bigger blast radius.