Rolling out multi-factor authentication: what should a small business plan first?
An MFA rollout should protect important accounts without leaving the person running payroll unable to sign in. Start with the accounts your business depends on, who owns the change and how people will recover access. Then choose suitable sign-in methods, prepare staff and test the arrangement before making it compulsory more widely.
Multi-factor authentication (MFA) checks your identity using two or more different types of evidence, such as a password plus confirmation from a registered device. But installing an authenticator app is only one part of the job. A useful MFA rollout plan should leave you confident that important accounts are covered and people can still do their work.
This guide is for the business owner or office manager organising that change with an IT provider. It focuses on the decisions to make, rather than settings to copy into a live system.
1. Name the people responsible for the rollout
You need someone who can approve the change, someone qualified to configure it and a clear support contact for staff. In a small business, some of these roles may be held by the same person. Make that explicit rather than assuming the office manager will sort out every sign-in problem.
Agree which business activities cannot be interrupted. Payroll, customer appointments and a busy sales period may affect the timing. Decide who can stop or adjust the rollout if testing reveals a problem.
Write down the support route before sending registration instructions. A colleague who cannot sign in to email needs a way to ask for help that does not depend on opening that email account.
2. List the accounts and services that matter
Start with email and files, then work through finance, payroll, remote access and important supplier portals. Include administrator accounts, contractors and people who only sign in occasionally. Ask the person responsible for each service to confirm how it is used.
For each service, record:
Who owns it and who needs access
How people sign in today
Whether MFA is available and already required
Any account or application that needs technical investigation
Who will confirm that protection is working after the change
Turning on MFA in Microsoft 365 does not automatically secure unrelated services. Check each service's sign-in arrangement, including any connection to a central identity system.
Separate human accounts from automated jobs and integrations. An unattended process cannot necessarily respond to the same prompts as an employee. Have your IT provider review the appropriate authentication method rather than relying on a shared staff login or a permanent exclusion.
3. Choose methods people can use securely
Authentication methods differ. The NCSC's guidance on MFA methods explains why phishing-resistant approaches, such as suitable FIDO2 security keys or passkeys, offer stronger protection than methods that rely on entering a code into a website.
Ask which stronger methods your services support and which are practical for your team. An authenticator app can offer several sign-in methods. Ask which method you are using: ordinary app codes and approval prompts do not automatically provide phishing-resistant protection.
Check the everyday constraints before choosing:
Does everyone have a suitable device, and what is the arrangement for personal phones?
Are there accessibility needs or locations with poor connectivity?
What happens when someone replaces or loses their device?
Can the same approved approach work across the important services?
Choose supported backup or recovery arrangements as part of this decision. Do not leave each employee to improvise a workaround. Available controls vary by service, configuration and licence, so this is a discussion with the person setting it up rather than a universal settings checklist.
4. Prepare registration and recovery together
Staff need to know what is changing, why, when they must register and how to recognise genuine instructions. Use a familiar communication route and explain how to check an unexpected request. Nobody should share a password or verification code with a colleague to get the rollout finished.
Give people time and help to register correctly. Then distinguish two questions: “Has this person registered a method?” and “Is MFA actually required for the access we intended to protect?” A completed registration list does not answer both.
Rehearse a lost-phone or replacement-device situation before the wider change. Who does the employee contact? How will their identity be checked before a reset? Which approved recovery route will restore access? Do not make switching off MFA the normal answer to a lockout.
Microsoft's deployment guidance covers preparation, registration and recovery for Microsoft Entra. Your provider should adapt the approach to the services and controls you actually use.
5. Give every exception an owner and a review date
A forgotten exception can leave an important account outside the intended protection. If something cannot move straight away, record the reason, accountable owner, protective measures and a date to review or remove the exception.
Do not assume every platform allows the same exclusions or staged enforcement. Investigate old applications and integrations before changing policy. The NCSC's MFA anti-patterns guidance is useful background for that technical discussion.
Administrative emergency access is a separate design issue from an employee losing a phone. Ask your IT provider to establish, protect, monitor and test the emergency route. It should not become a shared everyday account or a blanket recommendation to leave an administrator without MFA. Microsoft's emergency-access guidance provides the platform-specific considerations.
For a broader view, our Cyber Essentials checklist explains the other technical controls to consider.
6. Test the work, then check the protection
Where your platform and controls support it, start with a small, representative pilot. Include the working patterns that could expose a problem: office and remote work, occasional users, important applications and recovery from a missing device. Keep existing protections in place while your provider agrees a safe approach.
The pilot needs to prove more than “I signed in once”. Can people complete their essential work? Are instructions understandable? Does the help route work? Can the technical owner show that the intended accounts and services are covered?
Ask your provider to review configuration and available sign-in evidence. A fresh prompt on every visit is not the only possible sign of protection; session behaviour varies. Equally, app registration alone is not proof that enforcement is correct.
Expand the rollout at a pace your support arrangements can handle. Afterwards, review unresolved problems, remaining exceptions and ownership. Add the agreed registration and recovery steps to your processes for new starters and device changes.
A worked example: a rollout decision before payroll
Hypothetical example: a 12-person consultancy uses Microsoft 365 for email and files, a separate payroll portal and a scheduling tool. Priya, the office manager, coordinates the change; Alex, the IT provider, handles configuration; the director approves timing. Payroll is due on Friday. One colleague needs a method that does not rely on a personal phone, and the external bookkeeper signs in only monthly.
Priya gives Alex the service and account list, essential tasks and device constraints. Alex checks each service’s supported methods and controls, includes an approved non-phone method for the colleague to test, agrees recovery arrangements and plans a representative pilot where the platform supports one. Existing protection stays in place. The payroll portal needs its own coverage check; Microsoft 365 settings are not assumed to protect it.
The pilot covers normal office and remote work, opening an authorised payroll preview without submitting a payroll run, and recovering from an unavailable device. Their illustrative decision record, dated 20 October, might read:
Email and files: everyday-task and enforcement checks passed, including the agreed non-phone method. Priya has checked usability; Alex has reviewed the intended MFA enforcement and available sign-in evidence. Expansion remains on hold until recovery is retested.
Payroll portal: hold the planned change. The bookkeeper’s backup method has not been tested. Alex will arrange a supervised test on 21 October and report the result before the director decides whether to proceed.
Recovery: hold wider rollout. The lost-device rehearsal exposed help instructions stored only in email. Priya will provide a contact route staff can reach while locked out; Alex and a pilot user will retest recovery on 21 October.
The director reviews the unresolved items with Priya and Alex before approving wider enforcement. The shared recovery hold must be cleared before any next wave. The value is a specific decision: what can proceed, what needs fixing and who will check it before payroll. A colleague covering Priya can use the same record, instead of relying on a reassuring but incomplete list of registered users.
Your five decisions before starting
You do not need a long strategy document to make progress. Write down these five things and agree them with the person implementing the change:
Accounts and services covered, with any gaps identified
A rollout owner and a support contact
Approved sign-in methods that suit your team
A verified recovery route, including a lost-device test
Pilot and rollout timing, with a check of protection afterwards
If you are unsure which accounts need attention or how to introduce MFA without disrupting your team, a discovery call is a useful starting point. We will talk about how your business works and the protection and support that may suit it. See what managed cyber security can involve for a small business.
Comments