MFA rollout checklist for small teams: enforce it without locking anyone out

Multi-factor authentication is the cheapest security win on the board — a stolen password alone stops opening most accounts. But half-finished rollouts are worse than none: an "optional" MFA policy is a policy nobody follows, an SMS-only rollout trains everyone to approve prompts they never meant to send, and an enforcement day without recovery codes becomes the day your bookkeeper is locked out of payroll. The rollout below is ordered so that the recovery layer exists before the enforcement switch does.

1. Pre-flight: inventory before you touch a setting

• List the accounts that matter: email, bank, payroll, cloud console, domain registrar, code hosting, the admin panels behind your product. Everything else can wait — roll out to the five accounts that can hurt, not to forty that can't.
• Find the non-humans. Service accounts, scripts, printers, old mail clients, and API integrations don't carry a phone. Tag them now; they get scoped app passwords or exceptions with expiry dates, not surprises.
• Check what each app actually supports. Most MFA-capable apps distinguish available from enforced. You want the enforce toggle — note where it lives for each account, because you'll visit it on enforcement day.
• Pick the factor before the rollout: an authenticator app (TOTP) as the default, hardware keys for the two admin accounts, SMS only as a documented last resort. Passkeys where the app offers them.

2. Build the recovery layer first (the part everyone skips)

• Two break-glass admin accounts that are not tied to any employee's phone: long random passwords in the password manager, MFA via hardware key, credentials sealed offline (paper in the safe, not a doc called "emergency.txt"). Test one by logging in, then leave them alone.
• Recovery codes, generated and stored, per human — printed or in the password manager before enrollment, not after the first lockout. Ten codes, one use each, dated.
• One backup admin per critical app: the person who can reset MFA for someone else must not be the person most likely to lose their own phone the same week.
• A written "lost phone" path — who to message, how identity is verified (video call with the manager, not "answer me in Slack"), and the expected turnaround. If it's not written down, enforcement day invents it under pressure.

3. The rollout: volunteers first, everyone second

1. Pilot with 3–5 volunteers for one week. They will find every broken integration: the desktop mail client that only does passwords, the invoicing tool that logs in once a quarter, the script that calls an old API. Fix or exempt those now, on five people, instead of on forty.
2. Collect the friction and answer it publicly: "why do I keep getting codes," "what happens when my phone dies," "does this log me out of my session." The questions repeat; answer them once in the rollout note.
3. Announce with real dates: T-7 "MFA goes enforced on the 15th, here's the 5-minute setup," T-1 reminder with the setup guide, T-0 enforcement. Open-ended "soon" rollouts never finish.
4. Offer a 15-minute setup window with someone screen-sharing. The volunteers who did it already are the best teachers — and the culture win is "we all did this together," not "IT made me."

4. Enforcement day, in order

1. Flip one account to enforced first (a volunteer who still has recovery codes), and verify a normal login works end-to-end — including on the mobile app and the desktop client people actually use.
2. Then enforce the rest in one batch. Keep "allow existing sessions" on if the app offers it, so nobody gets logged out mid-task on day one.
3. Watch the channel you named for lockouts for the rest of the day. Every unblock goes through the written path — verify identity, have them use a recovery code, re-enroll the new device.
4. Same day: check the exceptions list. Service accounts and old clients should now have scoped app passwords or API tokens — each one labeled with an owner and an expiry.
5. Close the loop in the weekly review: enforcement status per app, exceptions remaining, and the date the last "optional" box gets turned off. An MFA rollout ends when nothing is optional.

5. The mistakes that flood the helpdesk

• Enforcing before recovery codes exist. This is the one that turns a Tuesday into a payroll outage. The recovery layer is section 2 for a reason.
• One human's phone as the factor for a shared account. Shared mailboxes and service logins get scoped app passwords or delegated access — not one employee's personal device as a single point of failure.
• SMS as the default. SIM-swap and phishing make it the weakest common factor, and it's the one that breaks silently when someone changes carriers. Authenticator app by default; document every SMS exception.
• "Optional" forever. The users who most need MFA are the ones most likely to skip an optional setting. Set the enforcement date when you announce the rollout.
• No re-auth on sensitive actions. MFA at login but password-only for changing the bank account on file is a drawer with a lock on the drawer handle. Ask for the factor again on admin and money-path changes.

Takeaways

• Recovery before enforcement: break-glass admins, per-person recovery codes, and a written lost-phone path exist before the first "enforced" toggle.
• Pilot on volunteers so the broken integrations surface on five people instead of forty.
• Authenticator over SMS, hardware keys for admins, exceptions with expiry dates — and nothing stays "optional."

---

The Ops Starter Kit ($14) includes the account inventory and access-review sheets that make the pre-flight list ten minutes instead of an afternoon, and Automation Starter Pack ($19) turns the weekly review — exceptions, expiry dates, enforcement status — into a recurring workflow. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.