What order should we roll out MFA in?

Start with admin accounts on phishing-resistant MFA, FIDO2 hardware keys or passkeys, with no exceptions. Next cover high-risk roles such as finance, legal, executives and their assistants. Then enroll everyone on number-matching push, move the general population to FIDO2 and passkeys over the following year, and finally federate, replace, or retire legacy apps that cannot do modern MFA.

How long does an MFA rollout take?

As a typical practitioner estimate, plan for three to six months to reach enforced MFA across the workforce, with the admin phase taking about two weeks. Moving the general population from push approvals to phishing-resistant FIDO2 and passkeys is a longer effort that typically runs over the following year, alongside hardware-key issuance and cleanup of legacy apps that cannot support modern MFA.

How do attackers get around MFA after it is deployed?

Most real-world bypasses exploit enrollment and recovery rather than breaking the factor itself. Scattered Spider called help desks and asked for MFA resets. Require hard-to-phish identity proof such as manager approval or a video check before any reset, log and alert on re-enrollment, and flag a reset that is immediately followed by a login from a new device or location.

How should an MFA rollout handle contractors and third-party staff?

Put contractors in the same identity provider policy as employees, not in an exclusion group. Require MFA at the IdP for every app they reach, issue hardware keys to contractors with admin or production access, and set an account expiry tied to the contract end date. Third-party accounts with no MFA, like the Citrix portal used against Change Healthcare in 2024, are a common entry point.

Is SMS still acceptable as a second factor?

Only as a temporary fallback. NIST SP 800-63B-4, final since July 2025, classifies out-of-band verification over the public phone network as restricted, and requires AAL2 verifiers to offer at least one phishing-resistant option. SMS codes can be relayed by a phishing page or intercepted through SIM swap, so plan a dated off-ramp rather than treating SMS as the end state.

What should we require from an MFA vendor?

Require number-matching push rather than plain approve or deny, hardware-key and WebAuthn/FIDO2 support for passwordless step-up, a risk-based policy engine that can suppress prompts on trusted devices, strong account recovery controls, and an audit-log API your SOC can consume. Treat SMS-only second factors as a disqualifier, since SMS is phishable and SIM-swappable.

How do you measure whether an MFA rollout worked?

Track the percent of the workforce on phishing-resistant MFA, the percent of apps and service accounts covered, and the time it takes to recover a locked-out user. Watch push approval rates for fatigue patterns, and run red-team phishing exercises: the target is zero successful credential phishing against accounts that have completed the rollout.

authentication · Intermediate

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

By SWI Community Team · Updated 2026-11-05 · 14 min

An MFA rollout is the phased program that takes multi-factor authentication from optional to enforced for every account that matters: admins first, then high-risk roles, then all staff and contractors, ending on phishing-resistant MFA. The short answer on sequencing: protect the accounts that can change the tenant before you protect everyone, and harden recovery before you enforce, because recovery is where attackers go next.

Every breach report says MFA would have prevented this, and the data backs it up: in an August 2019 post, Microsoft said MFA can block over 99.9 percent of account compromise 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. Not all MFA is equal either. The Snowflake breaches hit accounts with no MFA at all, while MFA-fatigue attacks defeated simple push approvals. The goal is phishing-resistant MFA everywhere it matters. This guide is for IAM and security teams planning the program; for factor-level configuration see MFA implementation best practices.

What changed in 2025-2026

NIST tightened the baseline. SP 800-63B-4, final in July 2025, says verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2" and keeps out-of-band codes over the phone network as restricted (NIST 800-63B-4). See NIST 800-63 and AAL.
Cloud providers now enforce MFA for you. Microsoft's mandatory MFA required MFA for the Azure portal, Entra admin center and Intune admin center from October 2024, the Microsoft 365 admin center from February 2025, and Azure CLI, PowerShell, IaC tools and the control-plane REST API from October 1, 2025, with Phase 2 postponement available only until July 1, 2026. Break-glass accounts are not exempt, and Microsoft recommends passkeys (FIDO2) or certificate-based authentication for them.
Number matching is the floor for push. In Microsoft Entra, number matching is enabled for all Microsoft Authenticator push notifications and users cannot opt out (Microsoft Learn).
Passkeys are standardized. WebAuthn Level 3 became a W3C Recommendation on August 25, 2026 (see WebAuthn/FIDO2), so the phishing-resistant end state no longer depends on a draft.

Pick the factor by population

Population	Target factor	Interim factor	Never allow
Tenant admins, break-glass	FIDO2 security key or certificate-based auth	None	SMS, voice, plain push
Finance, legal, executives, assistants	Device-bound passkey or security key	Number-matching push	SMS-only
General staff	Passkey (platform or synced)	Number-matching push or TOTP	Approve/deny push
Contractors and third-party staff	Same as staff, keys for prod or admin access	Number-matching push	Exclusion groups
Frontline and shared devices	Security key or smart card	TOTP hardware token	Shared SMS phone
Service accounts	Workload identity, no human MFA	None	User accounts used as service accounts

Compare vendor support per factor in the MFA matrix and the Phishing-Resistant MFA Support Matrix 2026.

A sequence that works

Inventory. Every app that touches sensitive data. Tag each with MFA capability (native, via IdP federation, or none), and list every remote access portal, VPN and vendor-facing login separately.
Phase 1, admin accounts only. Enforce phishing-resistant MFA (FIDO2 hardware keys such as Yubico keys, or passkeys) on every admin. Two weeks, no exceptions (an estimate for a typical mid-size tenant). Admins are tier zero.
Phase 2, high-risk roles. Finance, legal, executives and their assistants, and anyone with access to crown-jewel data. Same factor mix as admins.
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. Bring contractors into the same policy on the same day.
Phase 4, phishing-resistant for everyone. Move the general population from push to FIDO2 and passkeys over the following year (estimate), with hardware-key issuance and platform-authenticator support.
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. Move user accounts used for automation to workload identities, which Microsoft's enforcement does not cover.

Failure modes and the incidents behind them

Failure mode	What happened	Technique	Control
No MFA on a remote access portal	Change Healthcare: compromised credentials on a Citrix portal without MFA, ransomware nine days later	Stolen credentials	Inventory every portal in step 1
No MFA on a SaaS tenant	Snowflake customer campaign: about 165 customer accounts accessed with infostealer credentials	Infostealer credential harvesting	Enforce at the IdP, block local login
Push approved under pressure	Uber and Cisco	MFA fatigue	Number matching, then passkeys
Codes relayed to a phishing page	0ktapus: 5,441 MFA codes captured across more than 130 organizations	OTP relay, AiTM phishing	Origin-bound factors
Help desk resets the factor	MGM Resorts	Help desk social engineering	Verified recovery (below)
Session stolen after MFA	CircleCI: a 2FA-backed SSO cookie stolen by malware	Session cookie theft	Short sessions, device binding

The last row matters for expectations: MFA protects the login, not the session that follows. Our analysis found that 46.5% of 2025-2026 identity breaches had no login for MFA to protect.

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.
Bootstrap new factors with a time-limited credential such as a Temporary Access Pass rather than a reset to SMS.
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. Cisco Duo, Microsoft Entra and Okta cover the workforce IdP side; compare options in MFA and passwordless vendors, the best phishing-resistant MFA ranking and the how to choose an MFA solution guide.

Common pitfalls

SMS as the only second factor; it is phishable and SIM-swappable. Set a retirement date (see the SMS off-ramp).
Executive exceptions that creep across the org chart.
Contractor and vendor accounts parked in an MFA exclusion group.
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, including contractors, on phishing-resistant MFA. Percent of apps, portals 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.

Frequently asked questions

What order should we roll out MFA in?: Start with admin accounts on phishing-resistant MFA, FIDO2 hardware keys or passkeys, with no exceptions. Next cover high-risk roles such as finance, legal, executives and their assistants. Then enroll everyone on number-matching push, move the general population to FIDO2 and passkeys over the following year, and finally federate, replace, or retire legacy apps that cannot do modern MFA.
How long does an MFA rollout take?: As a typical practitioner estimate, plan for three to six months to reach enforced MFA across the workforce, with the admin phase taking about two weeks. Moving the general population from push approvals to phishing-resistant FIDO2 and passkeys is a longer effort that typically runs over the following year, alongside hardware-key issuance and cleanup of legacy apps that cannot support modern MFA.
How do attackers get around MFA after it is deployed?: Most real-world bypasses exploit enrollment and recovery rather than breaking the factor itself. Scattered Spider called help desks and asked for MFA resets. Require hard-to-phish identity proof such as manager approval or a video check before any reset, log and alert on re-enrollment, and flag a reset that is immediately followed by a login from a new device or location.
How should an MFA rollout handle contractors and third-party staff?: Put contractors in the same identity provider policy as employees, not in an exclusion group. Require MFA at the IdP for every app they reach, issue hardware keys to contractors with admin or production access, and set an account expiry tied to the contract end date. Third-party accounts with no MFA, like the Citrix portal used against Change Healthcare in 2024, are a common entry point.
Is SMS still acceptable as a second factor?: Only as a temporary fallback. NIST SP 800-63B-4, final since July 2025, classifies out-of-band verification over the public phone network as restricted, and requires AAL2 verifiers to offer at least one phishing-resistant option. SMS codes can be relayed by a phishing page or intercepted through SIM swap, so plan a dated off-ramp rather than treating SMS as the end state.
What should we require from an MFA vendor?: Require number-matching push rather than plain approve or deny, hardware-key and WebAuthn/FIDO2 support for passwordless step-up, a risk-based policy engine that can suppress prompts on trusted devices, strong account recovery controls, and an audit-log API your SOC can consume. Treat SMS-only second factors as a disqualifier, since SMS is phishable and SIM-swappable.
How do you measure whether an MFA rollout worked?: Track the percent of the workforce on phishing-resistant MFA, the percent of apps and service accounts covered, and the time it takes to recover a locked-out user. Watch push approval rates for fatigue patterns, and run red-team phishing exercises: the target is zero successful credential phishing against accounts that have completed the rollout.

Last reviewed November 5, 2026By SWI Community TeamSuggest a correction How we research