Start with Identity
Subscribe
← Guides
authentication · Intermediate

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

By SWI Community Team · Updated 2026-06-17 · 14 min

Problem statement

Every breach report says MFA would have prevented this, and the data backs it up: Microsoft reports phishing-resistant MFA blocks over 99% of identity attacks. Yet full enforcement remains rare, and the blockers are operational, not technical: legacy apps that cannot do MFA, help-desk capacity, and executive exceptions that quietly propagate. Worse, not all MFA is equal. The Snowflake breaches hit accounts with no MFA at all, while MFA-fatigue attacks defeated simple push approvals. The goal is not just MFA, it is phishing-resistant MFA everywhere it matters.

A sequence that works

  1. Inventory. Every app that touches sensitive data. Tag each with MFA capability (native, via IdP federation, or none).
  2. Phase 1, admin accounts only. Enforce phishing-resistant MFA (FIDO2 hardware keys or passkeys) on every admin. Two weeks, no exceptions. Admins are tier zero.
  3. Phase 2, high-risk roles. Finance, legal, executives and their assistants, and anyone with access to crown-jewel data. Same factor mix as admins.
  4. Phase 3, everyone, with number-matching push. General population on an authenticator app with number matching and context, never blind approve/deny. Risk-based policy suppresses prompts on trusted devices to reduce fatigue.
  5. Phase 4, phishing-resistant for everyone. Move the general population from push to FIDO2 and passkeys over the following year, with hardware-key issuance and platform-authenticator support.
  6. Phase 5, legacy app cleanup. Anything that cannot do modern MFA gets federated through the IdP, replaced, or sunset. Legacy and service accounts excluded from MFA are exactly where attackers like Midnight Blizzard get in.

Account recovery and enrollment: the step attackers target

Most real-world MFA bypasses do not break the factor; they exploit weak enrollment and recovery. Scattered Spider simply called the help desk and asked for a reset. Harden this path:

  • Require strong, hard-to-phish proof of identity before any reset, such as manager approval or a video check for sensitive roles.
  • Treat MFA re-enrollment as a high-assurance event with logging and alerting, not a casual self-service action.
  • Alert on the pattern of a reset immediately followed by a login from a new device or location.

Vendor requirements

Number-matching push (not just approve/deny), hardware-key and WebAuthn/FIDO2 support for passwordless step-up, a risk-based policy engine, strong recovery controls, and an audit-log API for the SOC. Compare options in MFA and passwordless vendors and the how to choose an MFA solution guide.

Common pitfalls

  • SMS as the only second factor; it is phishable and SIM-swappable.
  • Executive exceptions that creep across the org chart.
  • Enforcing MFA without addressing the legacy and service-account population first.
  • Blind-approval push without number matching, which invites fatigue attacks.
  • Underestimating help-desk volume and recovery risk during rollout.

Success metrics

Percent of workforce on phishing-resistant MFA. Percent of apps and service accounts covered. Time-to-recover for a locked-out user. Push approval rates with no fatigue patterns. Zero successful credential phishing in red-team exercises.