Multi-Factor Authentication: A Complete Guide for Teams

If you could implement just one security control across your organisation and nothing else, multi-factor authentication (MFA) should be it. Microsoft's research consistently shows that MFA blocks more than 99% of account compromise attacks. Phishing, credential stuffing, password reuse exploits — the vast majority of them are stopped dead the moment a second factor is required.

Yet MFA adoption in small and mid-sized businesses remains patchy. Rollout gets delayed, exceptions multiply, contractors slip through the cracks. This guide covers everything you need to get it right.

Why MFA Is Non-Negotiable

Passwords are fundamentally broken as a sole authentication mechanism. They get reused across sites. They get phished. They get stolen from databases. They get guessed. The question isn't whether attackers can obtain your team's passwords — it's when.

MFA solves this by requiring a second proof of identity that attackers can't easily obtain just by knowing a password. Even if a password is compromised, the account isn't. That's a massive reduction in risk for a relatively small operational overhead.

The threat this addresses is real and targeted at businesses of every size. Credential-based attacks are largely automated, scalable, and indiscriminate. A five-person startup faces the same credential-stuffing bots as a Fortune 500 company.

Types of MFA

Not all MFA is created equal. The choice of factor matters, and different options suit different contexts.

TOTP Apps (Time-Based One-Time Passwords)

Apps like Google Authenticator, Authy, and Microsoft Authenticator generate a six-digit code that changes every 30 seconds. These are widely supported, free, and significantly more secure than SMS. The codes are generated on-device without any network connection, meaning they can't be intercepted in transit.

The main downside is device dependency — if a team member loses their phone without a backup, access recovery becomes painful. Encourage staff to set up backup codes or a secondary device where possible.

Hardware Keys

Physical security keys such as YubiKey use standards like FIDO2 and WebAuthn. They are the gold standard for MFA security. Unlike TOTP codes, hardware keys are phishing-resistant by design — they cryptographically verify the domain they're being used on, so a fake login page can't capture a valid response.

The downsides are cost (roughly £25–£60 per key) and the need to manage physical hardware. For high-privilege accounts — senior leadership, administrators, finance — hardware keys are worth the investment. For general staff, TOTP apps are usually sufficient.

Push Notifications

Apps like Duo and Microsoft Authenticator can send a push notification to a registered phone for approval. These are convenient and have strong adoption rates, but they have a known weakness: push fatigue. Attackers sometimes flood a user with push requests hoping they'll approve one by mistake. If you use push-based MFA, make sure number-matching is enabled — this requires the user to confirm a specific number shown on the login screen, which eliminates accidental approvals.

SMS Codes

SMS is the weakest form of MFA still in common use. SIM-swapping attacks, where an attacker convinces a mobile carrier to transfer a phone number to a SIM they control, can defeat it. SMS codes can also be intercepted via SS7 vulnerabilities in the global mobile network.

SMS MFA is better than no MFA, but it should be treated as a fallback rather than a primary factor. If a service offers TOTP or push as an option, use that instead.

Which Accounts Need MFA First

You probably can't roll out MFA to everything simultaneously. Prioritise in this order:

1. Identity providers and SSO platforms — Okta, Azure AD, Google Workspace. These are the keys to the kingdom. If an attacker gets into your IdP, they have access to everything connected to it.
2. Email — Email is used to reset every other password. Control of someone's email means control of their digital identity.
3. Cloud infrastructure — AWS, GCP, Azure root and admin accounts especially. Compromised cloud credentials can result in large bills, data theft, or ransomware within hours.
4. Financial systems — Banking, payroll, accounts software.
5. Code repositories — GitHub, GitLab. Source code compromise can introduce supply chain risks.
6. Everything else — CRM, HR tools, collaboration platforms.

Rolling Out MFA Across Your Team

A technically correct rollout that your team ignores is worse than a messier one they actually follow. Communication and training matter as much as configuration.

Start with a simple explanation of why MFA is being introduced. People comply better when they understand the reason. A short internal message covering what you're rolling out, when, and why is usually enough.

Set a deadline. "MFA is required for all accounts by [date]" creates urgency. Give people two to three weeks to set it up, with reminders at the one-week and 48-hour marks.

Designate a go-to person for troubleshooting. Even with clear instructions, some people will get stuck. Reducing that friction increases compliance.

Don't forget the recovery path. Set up backup codes or recovery options before enforcement goes live, not after someone is locked out.

Common Pitfalls and How to Avoid Them

Exempting "important" people. Executives and founders are among the most targeted individuals in an organisation. They often receive the most dangerous phishing attempts. No exemptions.

Leaving legacy protocols active. Some older email clients and tools don't support modern authentication and bypass MFA entirely via basic auth. Disabling legacy authentication protocols is essential for the protection to hold.

Not enforcing it — just enabling it. Enabling MFA as an option is not the same as requiring it. Set policies to enforce MFA, not just recommend it.

Ignoring recovery. Account lockouts are real. Have a clear, documented recovery process so a lost phone doesn't become a business disruption.

MFA for Contractors and External Access

Contractors and external collaborators are a significant risk surface. They often use personal devices, personal email accounts, and their own security practices (or lack thereof).

For external access to your systems, require MFA just as you would for employees. If your identity provider supports it, you can extend policies to guest accounts. If contractors are accessing specific tools directly, verify those tools require MFA and confirm it's enabled on the contractor's account.

For particularly sensitive access — production systems, financial data, customer records — consider requiring hardware keys rather than TOTP apps for external parties, regardless of the inconvenience.

Conclusion

MFA is not a heavy lift, but it requires active management to do properly. Enabling it without enforcing it, leaving exceptions in place, or failing to handle edge cases like legacy protocols or contractor access will undermine the protection it provides.

Done right, MFA is the most efficient use of security investment available to a growing team. It doesn't require a large budget, deep technical expertise, or months of planning. It requires a decision, a deadline, and follow-through. Start this week.