Cyber Security
What is MFA and why your business needs it
Multi-factor authentication explained for UK small businesses: authenticator apps vs SMS, phishing-resistant MFA, conditional access and shared mailboxes.
By Dig IT SolutionsUpdated 8 September 20266 min read
Short answer
Multi-factor authentication (MFA) requires a second proof of identity, such as an authenticator app prompt or a security key, in addition to a password. It stops most account takeovers because a stolen or reused password is no longer enough on its own. Enforce it on email, remote access and cloud systems, preferring authenticator apps or passkeys over SMS codes.
Most account breaches in small businesses start with a password that was stolen, guessed or reused. Multi-factor authentication (MFA) is the control that makes that password useless on its own, and it is the single most cost-effective security measure a business can enforce. Most Microsoft 365 licences include it. The question is not whether to use it, but which kind, for whom, and how to enforce it without creating a support headache.
What MFA is
Authentication means proving you are who you say you are. A password is one factor: something you know. MFA adds at least one more: something you have (a phone with an authenticator app, a security key) or something you are (a fingerprint or face). An attacker who has your password from a leaked database or a phishing page still cannot log in without the second factor.
The NCSC recommends MFA for all important accounts and specifically for any cloud service holding business data. Cyber Essentials requires it on all cloud services that offer it. Microsoft has reported that MFA stops the great majority of automated account-compromise attempts. In our experience, businesses that enforce MFA for every user almost entirely stop seeing the mailbox takeovers that lead to invoice fraud.
The types of MFA, from weakest to strongest
Not all second factors are equal, and attackers have adapted to the weaker ones.
| Method | How it works | Weakness | Suitable for |
|---|---|---|---|
| SMS or voice code | A code is texted or read out | SIM-swap fraud, relay by phishing pages, phone number changes | Fallback only |
| Authenticator app code (TOTP) | Six-digit code from an app, changes every 30 seconds | Can be typed into a phishing page and relayed in real time | Acceptable for standard users |
| Authenticator push with number matching | Approve on the phone by entering a number shown on screen | Real-time relay by proxy phishing kits is still possible, but MFA fatigue is defeated | Minimum standard for all users |
| Security key (FIDO2) or passkey | A hardware key or device-bound credential that only works on the genuine site | Requires the key or device to be present | Administrators, finance, directors, and ideally everyone |
| Windows Hello for Business | Face or fingerprint on a managed Windows device, bound to that device | Only on managed devices | Office and laptop users on company hardware |
The important distinction is phishing resistance. Codes and push prompts can be relayed: a fake Microsoft login page passes your password and your code straight to the real site and takes the resulting session. Security keys and passkeys cannot be relayed, because the credential is tied to the genuine web address. Attack kits that do exactly this relay are now cheap and common, which is why we move administrator, finance and director accounts to phishing-resistant methods first.
MFA fatigue and how to beat it
Once attackers had lists of leaked passwords and their targets had push-based MFA, a new trick appeared: log in repeatedly so the user's phone buzzes again and again until they approve one prompt to make it stop, or approve by reflex. Microsoft's number matching, where the user must enter the number displayed on the login screen, stops this because you cannot approve by accident. It is on by default in Microsoft Authenticator now, but older setups and third-party apps may not have it. Staff also need the rule: never approve a prompt you did not trigger, and report it if you get one. See our phishing guide for how these attacks are combined.
Enforcing it: security defaults versus conditional access
Enabling MFA and enforcing it are different things. Many Microsoft 365 tenants have MFA "available" while a third of users have never registered, or have an exception because a director found it annoying. Attackers find those accounts.
Security defaults are Microsoft's free, one-switch baseline: MFA registration required for everyone, legacy authentication blocked, administrators always challenged. For a very small business with no special requirements, it is a reasonable start.
Conditional access, available with Microsoft 365 Business Premium and Entra ID P1, is the proper tool. Policies decide when to require MFA and what else to require: block sign-ins from countries you do not operate in, require a compliant or managed device to reach SharePoint, require phishing-resistant MFA for admin roles, block legacy protocols that bypass MFA entirely, and challenge again when a sign-in looks risky. It also allows sensible exceptions that do not weaken security, such as skipping the prompt on trusted, managed devices in the office. Our conditional access explainer goes into the policies we deploy as standard.
Whichever route you take, block legacy authentication. Old protocols such as basic SMTP and IMAP do not support MFA and are the back door attackers try when the front door is locked.
Where MFA is needed beyond Microsoft 365
Email is the priority, but it is not the only target. Apply MFA to:
- Remote access: VPN, remote desktop gateways and any remote support tool. An unprotected VPN with a leaked password is a common ransomware entry point.
- Accounting and payroll systems, online banking and payment platforms.
- The CRM and line-of-business applications holding customer data.
- Administrative interfaces: the firewall, the Wi-Fi controller, the backup console, the domain registrar, the website. Losing the backup console to an attacker is how backups get deleted before ransomware runs.
- Social media and marketing accounts in the company's name.
If a supplier's system does not offer MFA, raise it with them and weigh it at renewal.
Shared mailboxes and shared accounts
The commonest rollout question is "what about accounts@ that four people use?". A shared mailbox should have no sign-in of its own. In Microsoft 365, convert it to a shared mailbox (which needs no licence), grant the four people permission to open it and send from it, and each opens it from their own MFA-protected account. Nobody knows a password for it because it does not have one, and when one of the four leaves, you simply remove their permission.
Genuinely shared accounts on third-party systems that cannot be split are harder. Where they cannot be avoided, put the credentials in a password manager with the MFA seed stored there too, so access is through each person's own protected login and can be revoked individually. Then keep asking the vendor for named accounts. Our offboarding checklist shows why shared credentials are such a problem when people leave.
Rolling it out without a revolt
MFA fails when it is imposed badly. What works:
- Tell people why, briefly, with a real example of invoice fraud.
- Register two methods per user at enrolment: the authenticator app plus a second (a security key, a second device, or Windows Hello on a managed laptop). That eliminates most "lost phone" lock-outs.
- Use conditional access to reduce prompts on trusted, managed devices, so people are challenged when it matters rather than constantly.
- Set a deadline and enforce it. Registration campaigns in Microsoft 365 nudge users, then the policy closes the gap.
- Give the service desk a recovery process with identity verification, so a lost phone is a ten-minute fix, not a day off.
- Move administrators and finance to security keys first. They are the accounts an attacker wants, and a pair of keys costs less than a lunch.
For businesses we support this is a standard part of Microsoft 365 security hardening, alongside legacy authentication blocking, app consent restrictions and sign-in alerting.
What MFA does not do
MFA protects the login. It does not stop a user granting a malicious app permission to read their mailbox (consent phishing), and it does not help if the device itself is compromised and the session is stolen. That is why it sits alongside endpoint detection and response, email filtering and staff awareness. It is the first control to put in place, not the last.
What to do next
If you are not certain that every user in your business, including directors and shared mailboxes, is covered by enforced MFA with legacy authentication blocked, an IT health check will confirm it in an afternoon and show what else in your Microsoft 365 tenant is still on default settings.

