Multi-factor authentication for small teams, a practical rollout guide

Multi-factor authentication is the single most effective control a small organisation can turn on. Microsoft's analysis of attacks on its own services found that an account with it turned on is more than 99.9 percent less likely to be compromised. The Information Commissioner's Office increasingly cites its absence as an aggravating factor in monetary penalty decisions when small organisations are breached.

Despite this, rollout stalls in most small teams. The reasons are the same everywhere. The person who understands the settings is not the person who has to explain it to everyone else. The plan is made for the ideal case and falls apart on the first exception. Nobody wants to be the one who locks a director out of their own email at 6pm on a Friday.

This guide gives you a rollout plan that works in a team of two to fifty people. It assumes you have never done this before and that you have to keep the business running while you do it.

Why this is the most important control you will implement

Almost every serious incident in a small organisation starts with a stolen or guessed password. Someone reused a password on a site that was breached. Someone was phished. Someone left a laptop unlocked in a coffee shop. The password itself is not usually the failure; the failure is that the password on its own was enough to get in.

Multi-factor authentication means that even if the password is compromised, the attacker still cannot log in without a second factor: a code from a phone, a hardware key, a fingerprint. Turning MFA on is the difference between "the attacker has our password, so they have our email" and "the attacker has our password, so they have half of nothing".

The three types of second factor and when to use each

Not all MFA is equal. The three main types, from least to most robust:

SMS codes. A code is texted to your phone. Better than nothing. Vulnerable to SIM-swap attacks, where someone convinces your mobile provider to port your number to a SIM they control. Adequate for low-risk personal accounts, insufficient for anything containing regulated data.

Authenticator apps. A six-digit code generated on your phone by an app like Microsoft Authenticator, Google Authenticator, Authy, or 1Password's built-in one. The code changes every 30 seconds and is not sent over the network, so cannot be intercepted. Free, universally supported, and appropriate for the great majority of small-business use cases.

Hardware keys (FIDO2 / WebAuthn). A physical USB or NFC key such as a YubiKey. The strongest option. Cannot be phished, cannot be intercepted, cannot be stolen without physically taking the key. Appropriate for administrator accounts and for staff who handle particularly sensitive data.

For a small team the practical answer is: authenticator apps for everyone by default, hardware keys for administrator accounts on your primary email tenant, your identity provider, and your finance systems.

The rollout in order

The following order matters. Do it in this sequence and you will not lock anyone out.

Step 1: Pick the authenticator app

Choose one authenticator app and standardise on it for the whole team. Do not let people pick their own; that becomes a support nightmare a year from now when someone changes phone.

The practical choices for a small business:

• Microsoft Authenticator if you are a Microsoft 365 organisation. Integrates with number-matching prompts and handles push approvals.
• Google Authenticator if you are a Google Workspace organisation, or as a neutral choice.
• 1Password if your team already uses 1Password and you want codes stored alongside passwords for continuity when someone changes device.

Whatever you choose, use it for every service across the team. Consistency reduces support load.

Step 2: Enable it on your own account first

Before rolling out to anyone else, enable MFA on your own account for every service you use. This does two things. It gives you the exact click-through knowledge you will need to help other people. And it means that if anything goes wrong for other users, they can escalate to you and you have not locked yourself out too.

Test that you can log in from a fresh browser, that recovery codes work if you deliberately fail an MFA challenge, and that you can reset a user in your organisation's admin console without needing your own second factor to do so.

Step 3: Enable it on administrator accounts

Any account with administrator privileges on any of your systems gets MFA next. This includes:

• The primary administrator on your Microsoft 365 or Google Workspace tenant.
• Domain registrar accounts (the account that owns your DNS is arguably the highest-value target you have; if an attacker takes it they can redirect email and set up phishing sites on your own domain).
• Hosting control panel accounts.
• Financial software administrator accounts (Xero, QuickBooks, Sage).
• The password manager itself.

Administrators should also have a hardware key as their second factor, not just an authenticator app. Buy two: one to carry, one in a locked drawer or safe. Losing your only hardware key on the day you need to reset a compromised user's account is a bad afternoon.

Step 4: Enable it on high-value user accounts

The next tier is anyone who has access to particularly sensitive data. In a law firm, this is anyone with access to client files. In a dental practice, it is anyone with access to the practice management system. In a marketing agency, it is anyone with access to client social media accounts, which will be worth more to attackers than you might expect.

Enable MFA on these accounts before the broader rollout, and make sure they understand what they are being enrolled in and why. These are the people whose accounts, if compromised, cost you the most.

Step 5: The team-wide rollout

Now the general rollout. The key to doing this without a support disaster:

Announce it two weeks in advance, in writing, with a specific date. Not "we will be rolling out MFA soon". A date. A time. A named person to contact for help.

Provide the enrolment instructions with screenshots. For each service (email, cloud storage, accounting, CRM), a numbered list of clicks with screenshots is worth more than an explanation of what MFA is. People do not need to understand the theory; they need to complete the enrolment.

Run a drop-in session on the day. Book a meeting room or a video call. Anyone who cannot get through the enrolment on their own drops in and does it with you watching. Half an hour of your time on rollout day saves days of tickets later.

Do not enforce until everyone has enrolled. Most identity providers let you require MFA on a rolling basis. Do not flip the "required" switch until you have confirmed every account has a factor registered. Otherwise the first person who tries to log in on Monday morning without having enrolled is locked out.

Step 6: The exception process

There will be exceptions. Plan for them in advance rather than after they happen.

The main exceptions in a small business:

• A user's phone is lost or broken. They cannot generate a code. You need a documented reset process where an administrator confirms their identity (in person, or via a video call, not just by email) and issues a temporary code that lets them re-enrol a new device.
• A user is on holiday abroad and cannot receive SMS codes. This is why authenticator apps beat SMS. Recovery codes generated at enrolment and stored securely also help.
• A user leaves the organisation. Their MFA needs to be removed as part of the offboarding process. If they had a hardware key, it comes back. If they had an authenticator app on their personal phone, the app entries need to be removed. If it is a shared account (which it should not be, but sometimes is), the second factor needs to be re-issued to the person taking over.

Document this process. A one-page runbook is enough. Put it somewhere everyone in the team can find without needing to ask.

The mistakes that trip people up

Rolling out to everyone before enrolling yourself. Guaranteed to end badly. Do your own account first.

Making SMS the only option. Fine for the initial rollout in a hurry, but plan to move to authenticator apps within a few months. SMS codes are the weakest form of MFA and are increasingly rejected by insurers and certification schemes as insufficient.

Not having recovery codes. Every service that supports MFA gives you a set of one-time recovery codes at enrolment. Print them, put them somewhere safe, do this for every account. The alternative when a phone is lost is a support call to the service's account recovery team, which for most business services takes days.

Enforcing MFA on the same day you announce it. Two-week notice. Written. Named contact. Do not skip this.

Assuming your accountant, your auditor, or your outsourced IT provider have MFA on the accounts they use to access your systems. They probably do not. Ask them. If they do not, either help them enrol or reduce their access to what they need to do their job.

What to do after rollout

Rollout is not the end. A quarterly check:

• Every user's MFA is still active on every service. People sometimes disable it during a phone change and forget to re-enable.
• Every administrator account has both a phone factor and a hardware key.
• No shared accounts exist that cannot have individual MFA per user.
• Recovery codes are still where they should be, for every account.
• The exception process has been used in the last quarter and worked; if it has not been used, run a fire drill.

The cost

Authenticator apps: free. Recovery code printing: pennies. Hardware keys: £45 per key from Yubico, two keys per administrator account is £90 per administrator. For a team of ten with three administrators, the total hardware cost is under £300. Compared to the cost of a single breach that MFA would have prevented, this is not a budgeting decision.

← Back to the blog