MFA Rollout Checklist Template

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.

• Export every account from the identity provider — staff, contractors, guests, shared mailboxes, service accounts and admin accounts, each tagged by type
• List every admin account and role holder — cloud directory, email, firewall, backup, remote management and finance system admins
• List the apps people sign in to and how — single sign-on through the identity provider, separate logins, VPN and remote desktop
• Check sign-in logs for legacy authentication — POP, IMAP, SMTP AUTH, older Office clients and anything else that cannot prompt for a second factor
• Identify accounts that cannot use MFA as they stand — service accounts, scanners and apps sending mail, shared kiosk logins; record each with an owner
• Confirm what your licence allows — conditional access, per-app policies and reporting differ between tiers and vendors; attach the summary

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.

• Set the allowed methods by group — phishing-resistant for admins, authenticator app with number matching for staff, SMS or voice only by exception
• Design the access policy — conditional access or the platform’s equivalent: who, which apps, which conditions, and what is blocked outright
• Create two break-glass accounts — cloud-only, excluded from normal policies, protected by a FIDO2 key or certificate stored securely, with an alert on every sign-in
• Write the exclusion rules — every exclusion is a named group with an owner, a reason and a review date, never an individual added on request
• Build policies in report-only or audit mode first — review a week of results to see who would have been blocked before anything is enforced
• Approve the design — methods, policies, exclusions and break-glass arrangements, with the approval recorded

Assigned to the service desk manager. These tasks must be complete before Phase 5 opens.

• Write the identity check for MFA and password resets — call back on a number from the HR record, manager confirmation or a video check with ID, never details the caller supplies
• Ban resets on the strength of urgency or seniority — attackers impersonate executives and claim to be locked out before a flight
• Use a time-limited one-time pass for re-registration — such as a temporary access pass, instead of disabling MFA on the account
• Require a second person to approve resets for admin accounts — recorded against the ticket
• Log every reset and alert the user by a second channel — an unexpected reset notice is often the first sign of an attack
• Brief and test the service desk — walk through a social-engineering call script and record who has completed it

The go/no-go decision at the end of the pilot is an approval task for the project sponsor.

• Move IT and every admin to their final method first — admins on phishing-resistant methods before anyone else is enforced
• Enrol a pilot group from every department and location — include remote staff, shift workers and at least one heavy traveller
• Test the awkward cases — new phone, lost phone, no smartphone, shared devices, overseas travel and guest access
• Test break-glass sign-in end to end — and confirm the alert reached the people who should see it
• Log every problem with a fix or a decision — attach the issue list to this task
• Approve go or no-go for the wider rollout — with the open issues accepted or resolved

• Send the announcement from a named leader — why it is happening, the dates, what users must do and how to get help
• Publish short how-to guides — one per method and device, with screenshots from your own sign-in pages
• Run the registration campaign — in-product prompts to register before enforcement, plus drop-in sessions for those who need help
• Supply hardware keys or alternatives — for users without a suitable phone, in secure areas or who decline a personal device
• Track registration by department weekly — chase the stragglers through their line managers before their wave goes live
• Tell users what a legitimate prompt looks like — and to report, not approve, any prompt they did not start

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.

• Enforce wave by wave — one department or site at a time, with the service desk briefed and staffed for the first morning of each
• Move the remaining legacy clients and apps to modern authentication — update mail clients, scanners and scripts, or replace them
• Block legacy authentication for everyone — once the sign-in logs show only accounts on the exception register still using it
• Block sign-in for shared mailbox accounts — people reach them through their own accounts, so they do not need a password of their own
• Record every exception — account, reason, compensating control such as location or device restrictions, owner and expiry date
• Confirm the wave — sign-in failures and service desk tickets checked and closed before the next wave begins

Closure needs approval from the security lead. The handover creates the quarterly review, so the coverage check recurs without a new project.

• Measure coverage — percentage of users registered and enforced, admins on phishing-resistant methods, and accounts on the exception register
• Review exceptions with their owners — anything without a current reason is removed or given a new expiry date
• Add MFA registration to the joiner process — and MFA method removal to the leaver process, so new gaps do not open
• Set up monitoring for repeated denied prompts and unusual resets — and agree who investigates them
• Schedule the quarterly coverage review — including a break-glass sign-in test
• Approve closure — with the coverage figures, exception register and policy export attached