MFA rollout: a practical sequence that doesn't break the org

Problem statement

Every breach report says "MFA would have prevented this." Yet 100% MFA enforcement remains rare in mid-market organizations. The blockers are operational, not technical: legacy apps that can't do MFA, helpdesk capacity, exec exceptions that propagate.

A sequence that works

1. Inventory. Every app that touches sensitive data. Tag each with MFA capability (native, via IdP federation, none).
2. Phase 1 — Admin accounts only. Enforce strong MFA (FIDO2 hardware keys) on every admin in the org. Two weeks. No exceptions.
3. Phase 2 — High-risk roles. Finance, legal, exec assistants. Same factor mix as admins.
4. Phase 3 — Everyone, with push/authenticator app. General population. Risk-based policy that suppresses MFA on trusted devices to reduce fatigue.
5. Phase 4 — Phishing-resistant for everyone. Move the general population from push to FIDO2 over the next year. Hardware key issuance, platform authenticator (passkey) support.
6. Phase 5 — Legacy app cleanup. Anything that can't do modern MFA either gets federated, replaced, or sunset.

Vendor requirements

Strong push notifications with number matching (not just approve/deny). Hardware key support. Risk-based policy engine. FIDO2 / WebAuthn for passwordless step-up. Audit log API for the SOC.

Common pitfalls

• SMS as the only second factor — phishable and SIM-swappable
• Allowing exec exceptions that creep across the org chart
• Enforcing MFA without addressing the legacy app population first
• Underestimating helpdesk volume during rollout

Success metrics

Percent of workforce on phishing-resistant MFA. Time-to-recover for a locked-out user. MFA push approval rates that don't show fatigue patterns. Zero successful credential phishing in red team exercises.