Most MFA projects stall in the same places: the service account nobody knew about, the shared mailbox still answering IMAP and the exclusion group that grew from three people to forty. This free MFA rollout checklist is the project plan for getting from “some people have MFA” to “every account that can use MFA does, and every one that cannot is on a register with an owner and an end date”. It is written for in-house IT teams and for MSPs running the same rollout for each client: inventory identities and apps, choose methods with phishing-resistant options first for admins, design the access policy and break-glass accounts, close the helpdesk reset route, pilot, run the registration campaign, enforce in stages, block legacy authentication, then measure coverage and hand over to business as usual.
Any second factor stops most password-spraying and credential-stuffing attacks, which is why MFA is the control insurers and auditors ask about first. But attackers have adapted. Push bombing, also called MFA fatigue, floods a user with approval prompts until they tap Approve to make it stop. Adversary-in-the-middle phishing kits sit between the user and the real sign-in page and pass the code or push approval straight through. SIM swapping moves a victim’s phone number to an attacker’s SIM, so SMS codes go to the wrong person. CISA’s October 2022 fact sheets on phishing-resistant MFA and on number matching rank methods for exactly this reason, and NIST SP 800-63B-4, published in 2025, requires phishing-resistant authenticators at its highest assurance level and treats SMS and voice codes as restricted authenticators.
Number matching is the cheapest fix for push bombing. Instead of a plain Approve button, the user has to type the number shown on the sign-in screen into the authenticator app. Someone who did not start the sign-in does not know the number, so a flood of prompts cannot be approved by accident. Microsoft made number matching mandatory for all Microsoft Authenticator push notifications from 8 May 2023. It does not stop a real-time phishing proxy, so administrators and other high-value accounts should go further.
Methods: FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based or smart card authentication.
Why: the credential is bound to the real site, so a proxy page cannot replay it.
Use for: every administrator first, then finance, executives and anyone a targeted attack would go after.
Methods: push with number matching, or app-generated one-time codes.
Why: defeats password spraying and casual push bombing at no extra cost.
Watch for: users approving prompts they did not expect; train them to report it.
Methods: one-time codes by text message or phone call.
Why it is weak: exposed to SIM swapping, number porting and interception.
Use for: users with no alternative, recorded on the exception register with a date to move off it.
The checklist bakes this ordering in: admins move to a phishing-resistant method during the pilot, everyone else registers an authenticator app, and SMS stays only where someone has recorded why. If you manage Microsoft 365 tenants, the Microsoft 365 Security Baseline Review Checklist then checks quarter by quarter that the rollout has not drifted.
Seven phases take the rollout from a blank inventory to a measured, handed-over control. Policy design and go-live each need named approval, and the legacy-protocol tasks appear only when the inventory finds legacy authentication in use.
Owned by the project lead. Phase 1 records whether legacy authentication is in use (Yes/No) and whether the identity platform supports conditional access; later tasks depend on both answers.
Policy sign-off is an approval task for the security lead (or, for an MSP, the client’s nominated contact); the rollout halts until it is Approved.
Assigned to the service desk manager. These tasks must be complete before Phase 5 opens.
The go/no-go decision at the end of the pilot is an approval task for the project sponsor.
Each wave needs sign-off from the project lead before the next starts. The legacy-authentication tasks appear only when Phase 1 recorded legacy authentication in use.
Closure needs approval from the security lead. The handover creates the quarterly review, so the coverage check recurs without a new project.
MFA appears in almost every framework, but the detail differs. The table maps the main references to the phase that produces the evidence. Requirements change, so check each against the current text; this is a starting point, not legal or audit advice.
| Framework | Reference | What it expects | Evidenced in |
|---|---|---|---|
| NIST SP 800-63B-4 (2025) | AAL2, AAL3; restricted authenticators | Phishing-resistant authenticators required at AAL3 and offered as an option at AAL2; SMS and voice codes are restricted, needing an alternative and a risk assessment | Phases 2 and 7 |
| CISA fact sheets (October 2022) | Phishing-resistant MFA; number matching | Move to FIDO or PKI-based MFA, prioritising high-value accounts; use number matching where push is still used | Phases 2 and 4 |
| PCI DSS v4.0.1 | 8.4.1, 8.4.2, 8.4.3 | MFA for administrative non-console access into the cardholder data environment, for all access into it, and for all remote network access that could reach it | Phases 1, 2 and 6 |
| PCI DSS v4.0.1 | 8.5.1 | MFA not open to replay, not bypassable by any user (including admins) without a documented, time-limited exception, using two different factor types | Phases 2 and 6 |
| Cyber Essentials v3.3 (Danzell) | User access control | MFA on every cloud service that offers it; from 27 April 2026 a cloud service without it is an automatic fail | Phases 1 and 7 |
| CIS Controls v8.1 | 6.3, 6.4, 6.5 | MFA for externally exposed applications, for remote network access and for all administrative access | Phases 4 and 6 |
Two outside pressures often set the timetable. Microsoft now requires MFA to sign in to the Azure portal, the Microsoft Entra and Intune admin centres and the Microsoft 365 admin centre, and since October 2025 has been extending that to Azure command-line tools, PowerShell, SDKs and infrastructure-as-code tools, so any admin or automation account that cannot do MFA will eventually stop working there. As of October 2026, Microsoft’s plan is to disable Basic authentication for SMTP AUTH in Exchange Online by default for existing tenants at the end of December 2026, which is a good deadline for Phase 6’s legacy work.
Cyber insurers also commonly ask about MFA on email, remote access and admin accounts at application and renewal. The coverage figures and exception register from Phase 7 are the honest answer to those questions; the Cyber Insurance Readiness Checklist collects them alongside the other controls insurers ask about.
Every exception is recorded in a table inside the task, with an owner and an expiry, and the quarterly review that the handover creates walks through them again. The exclusion group cannot quietly grow because each addition is visible against a name.
Policy design, the pilot go/no-go, each enforcement wave and closure are approval steps assigned to a named person. The checklist halts until they approve, so a wave never starts while the last one still has open tickets.
MSPs start one run per client from the same template. Conditional logic adds the legacy-protocol work only where the inventory found it, and the audit trail shows the client exactly who did what and when.
CheckFlow is not an identity provider or MFA product. It runs the human side of the rollout around those tools: the inventory, the decisions, the communications, the waves and the exceptions. For MSPs running this across a client base, CheckFlow for MSPs shows how one template becomes a repeatable project per client, and the MSP process management guide covers how to standardise that work.
An MFA rollout is often the first project after taking on a client, so it sits naturally after the MSP Client Onboarding Checklist. Once it is live, check admin accounts properly with the Privileged Access Review Checklist, and use the Cyber Essentials Certification Checklist if certification is the reason for the deadline.
Start with an inventory of every account and app, including service accounts, shared mailboxes, admin accounts and anything using legacy protocols. Choose methods by risk, with phishing-resistant options for admins. Design the access policy and test it in report-only mode, secure the helpdesk reset process, pilot with IT and a cross-section of staff, run a registration campaign, then enforce in waves. Finish by blocking legacy authentication, recording every exception with an owner and expiry, and handing coverage checks to a recurring review.
It is MFA that a fake sign-in page cannot capture and replay. FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based or smart card authentication all qualify, because the credential is cryptographically tied to the genuine site. Codes from an app, SMS or a phone call, and push approvals, can all be relayed by an adversary-in-the-middle phishing kit, so they are not phishing-resistant even though they are much better than a password alone.
MFA fatigue, or push bombing, is when an attacker who already has a password triggers sign-in after sign-in, sending the user a stream of push prompts until they approve one by mistake or to make it stop. Number matching asks the user to type the number shown on the sign-in screen into the app. The real user can see it; someone being bombed at random cannot, so the attack fails. Train users to deny and report any prompt they did not start.
Only as a fallback for people with no better option, and recorded as an exception. SMS and voice codes can be intercepted or redirected by SIM swapping and number porting, and NIST SP 800-63B-4 classes them as restricted authenticators that need an alternative to be offered. Do not block a user’s only method before they have something to move to.
Shared mailboxes do not need their own sign-in: people open them through their own accounts, so block sign-in on the mailbox account itself. Service accounts should move to an option designed for machines, such as managed identities or certificate-based app authentication. Where that is not yet possible, restrict the account to the locations and systems it needs, give it a named owner, and record it on the exception register with a date to fix it.
For a small business with one identity platform, a few weeks from inventory to full enforcement is realistic. Larger organisations with legacy applications, shift workers and many sites often take a few months, mostly spent on legacy clients and people without a suitable phone. The pilot usually shows how long the rest will take.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
