Build an MFA Rollout Plan With Every Exception Assigned

Start With the Boundary of the Promise

The MSP model includes MFA in baseline security for every plan, alongside endpoint protection, awareness training, and email protection. That sets the service expectation. Your implementation still needs a precise list of the systems and identities you manage, plus the client-controlled systems that need a separate decision.

On MSP Mastery, Tim Stephinson recommends giving clients evidence about the systems the MSP actually manages rather than answering security questionnaires on their behalf. His example distinguishes MFA on managed systems from a client-controlled application outside the MSP's scope. Use that distinction when agreeing the rollout boundary, before anyone describes the result as universal coverage.

Build the inventory with the client's application owner. Include ordinary users, administrators, external access, unattended processes, and the devices or applications involved in their sign-in paths. For each entry, record who controls it, the relevant vendor documentation, the present configuration, and the required end state.

Treat an unknown application as unresolved work. Ask the client to identify its owner and arrange access for assessment. Leaving it out of the list would make the report tidier while leaving the coverage question unanswered.

Choose the Standard and Record the Differences

The model calls for a standard technology stack and training technicians on it. Apply that discipline to your documented MFA approach: the methods you intend to support, how enrollment works, how support verifies a recovery request, and who can authorize an exception. Check the current vendor prerequisites, licensing, and supported authentication paths for each system before choosing settings.

A rollout checklist is like an electrical panel schedule: every circuit needs a label, including the one awaiting repair. A checked box saying the building has power doesn't tell you whether the room you need is connected. Keep the account and application detail behind the client-level status.

On a podcast, Justin Esgar describes checking his own firm's task-management accounts after an employee left and discovering users without MFA. He planned a review across his MSP's tools to establish whether MFA was enforced rather than merely offered. That is one operator's account, and a useful question for your test sheet.

Write the question as an observable test. For a selected user and application, what should happen when they sign in, what result would show the requirement is missing, and where will the technician record the evidence? Have the technical lead confirm the test against that system's current documentation.

Give Exceptions a Decision and an Exit

Picture a client with staff ready to enroll and an older application whose authentication options are still unconfirmed. Keep that application on the rollout register. Assign someone to establish what the vendor supports and whether the application can be changed, replaced, or taken out of use.

Don't let a temporary exclusion become an undocumented operating standard. I would require the following record before treating any exception as an approved decision.

• The affected accounts, applications, and access paths, with a plain reason the intended requirement cannot yet be applied.
• The technical owner who will investigate the limitation, the client person who can decide the business tradeoff, and the person authorized to approve the exception.
• The proposed interim treatment, its documented limitations, and the evidence the technical lead needs before recommending it.
• The work that will remove the exception, who will fund or approve it, and the date when the decision must be revisited.

Set the review date from the actual work and the risk decision. A convenient date on a template doesn't make the interim treatment suitable. If the team can't establish an acceptable way to proceed, take the unresolved choice to client leadership before changing the account's status.

Rehearse the Work Before Expanding It

Choose the first rollout group to cover the sign-in paths you need to understand, with client approval and support available. Include the applications and working arrangements that could change the result. A group made only of technically confident office users would leave other paths untested.

On a project-scoping podcast, Erick Simpson suggests a paid proof of concept with a limited business unit or user group when the requested work is unfamiliar. He presents it as a way to work through uncertainties before quoting and conditionally extending the solution. Agree the learning objective and commercial treatment with the client rather than silently treating discovery as finished implementation.

Ask the project lead to document enrollment, normal sign-in, loss of the chosen authentication method, and the approved recovery route. Rehearse access recovery with authorized test accounts and confirm the identity-checking procedure before giving support staff a runbook. Record unexpected results as project issues with owners.

Define the decision to expand before the rehearsal. Require the agreed sign-in tests to pass, support staff to be prepared, and unresolved exceptions to have decisions. If a result fails, pause the affected work and follow the approved change or recovery procedure. Don't improvise a broad exemption to keep the schedule looking healthy.

Put Support Capacity Into the Schedule

Separate the technician carrying out changes from the person handling ordinary support during the rollout. They can be existing staff with explicit assignments. Give the service lead the rollout schedule, the affected client groups, the expected support tasks, and a route to the technical owner.

Base the next group's size on the work observed in the rehearsal and the capacity actually available. Count preparation, enrollment help, testing, exception investigation, and documentation. Don't insert a fixed users-per-technician figure that your own work records can't support.

Tell users when their access will change, what preparation they need, and how to reach authorized help. Have the client confirm who is unavailable, who needs an alternative arrangement, and which business activity must be protected. Adjust the schedule from those answers before enforcing the change.

Close With Evidence the Service Desk Can Use

Have the technical lead reconcile the completed work against the full inventory. For each client, retain the tested coverage, configuration evidence, outstanding exceptions, and the next responsible person. Keep registration progress separate from the evidence that the intended requirement applies.

Hand the service desk a current support procedure and a clear owner for future account and application changes. Ask the account lead to review the remaining client decisions with the person authorized to make them. Completion is a documented coverage decision with visible gaps, rather than a reassuring email that everyone has been enrolled.