MFA: How Multi-Factor Authentication Actually Protects Your Business

What MFA is and why passwords alone fail

A password is something you know. MFA adds something you have (a phone, a hardware token) or something you are (fingerprint, face). An attacker who phishes your password or buys it from a credential dump still can't log in, because they don't have the second factor. This is why MFA is the single most effective control against account takeover—most attackers move on to softer targets rather than defeat the second layer.

The weakness in password-only authentication is reuse and predictability. Staff use the same password across multiple sites, and when one site is breached, those credentials appear in lists that attackers test everywhere. MFA breaks that chain. Even if your finance manager's password is in a breach dump, the attacker hitting your Microsoft 365 login still needs the code from her phone.

MFA is mandatory for Cyber Essentials certification and appears in every cyber insurance questionnaire. It's no longer treated as a nice-to-have; insurers and certification bodies recognise that without it, you're one phishing email away from a breach.

The common MFA methods and what they're good for

SMS codes are the easiest to deploy—staff already have phones, and setup takes seconds. The code arrives by text, you type it in, you're done. The downside is SIM-swap attacks: an attacker convinces your mobile provider to port your number to a new SIM, then intercepts the codes. It's rare but not theoretical, and it's why SMS is acceptable for basic email access but not recommended for admin accounts or financial systems.

Authenticator apps—Microsoft Authenticator, Google Authenticator, Authy—generate time-based codes on the phone itself. They're not vulnerable to SIM swaps because nothing travels over the phone network. The app and the server share a secret during setup, and both generate the same six-digit code every thirty seconds. Setup is slightly harder (scan a QR code), but once it's done, it's faster than SMS and works offline.

Push notifications are the smoothest user experience: a prompt appears on your phone, you tap Approve, and you're in. Microsoft Authenticator and Duo support this. The risk is notification fatigue—if an attacker hammers your account with login attempts, the flood of prompts might trick you into approving one. Some systems now require you to type a number shown on the login screen into the app, which stops that attack. Hardware tokens like YubiKeys are the gold standard for high-value accounts. You tap the token to a USB port or hold it near your phone; no code to type, nothing to intercept. They cost £20–40 each and last years, so the barrier is logistics, not budget.

Where to enforce MFA first

Start with Microsoft 365 and email. Email is the gateway: if an attacker controls your inbox, they reset passwords everywhere else, intercept invoices, and impersonate you to clients. Microsoft 365 supports MFA natively through Entra ID (formerly Azure AD), and you can enforce it per-user or per-group. Rolling it out to all users at once causes a spike in helpdesk calls; rolling it out to one department at a time—starting with finance and management—spreads the load and lets you fix the common stumbling blocks before everyone hits them.

VPN and remote desktop access should be next. These are direct paths into your internal network, and they're常 targeted because many businesses still use password-only authentication. If your VPN supports RADIUS, you can integrate almost any MFA provider. If it doesn't, you're looking at a VPN replacement or an MFA-capable firewall in front of it. Remote desktop gateways (RD Gateway, Guacamole) can enforce MFA before allowing RDP sessions, which stops attackers brute-forcing exposed RDP ports.

Admin accounts and privileged access come last in sequence but first in importance. Any account that can create users, change permissions, or access financial systems should have MFA enforced and—ideally—use hardware tokens rather than app-based codes. These accounts are the ones attackers specifically hunt for, and they're the ones your cyber insurer will ask about.

Common deployment problems and how to solve them

The biggest practical barrier is staff who don't have smartphones or can't install apps on them. For them, hardware tokens work, or you can issue a small number of SMS-based codes as a fallback. Some organisations buy cheap Android devices purely for authenticator apps and issue them like key fobs. The cost is under £50 per person, and it solves the BYOD objection.

Legacy applications that don't support modern authentication are the other common blocker. Older IMAP/SMTP clients, label printers, scanners, and some CRM integrations authenticate with a username and password and have no mechanism for a second factor. Microsoft 365 handles this with app passwords—single-use passwords generated in the portal that bypass MFA for that specific app. You create one, paste it into the device, and it works until you revoke it. The device itself becomes the second factor because it's physically controlled. This isn't as secure as proper MFA, but it's better than leaving MFA off entirely just to accommodate one scanner.

Account lockouts happen during rollout, usually because someone changes their phone and forgets to reconfigure the authenticator app, or because they're travelling and their phone dies. You need a documented recovery process: either a set of backup codes generated during setup and stored in a safe place, or a helpdesk procedure for temporarily disabling MFA so they can log in and re-enroll. Without that process, your first lockout will be the MD calling from an airport, and you'll make an on-the-spot decision you shouldn't have to make.

What MFA doesn't protect against

MFA stops attackers from logging in with stolen passwords, but it doesn't stop malware already running on a device. If a user approves an MFA prompt while malware is active in their browser, the attacker rides that authenticated session and doesn't need the password or the second factor. This is why MFA works best alongside endpoint protection—EDR that detects malicious processes before they can hijack a session.

It also doesn't prevent social engineering attacks where the user is tricked into approving a login. An attacker calls pretending to be IT support, asks the user to approve a notification, and the user complies. Training helps, and so does the number-matching feature in modern authenticator apps—the user has to type a number from the login screen, which is harder to socially engineer over the phone.

MFA is a control, not a cure. It dramatically raises the bar for attackers, but it's part of a broader security posture that includes patch management, email filtering, endpoint protection, and backup. Deployed properly, it removes the easiest attack vector; deployed badly—with too many exceptions or recovery paths that bypass it—it becomes security theatre.

How we help businesses deploy and manage MFA

IPFour configures MFA across Microsoft 365, VPN, and remote access as part of managed IT and security services for SMBs and mid-market businesses in Lancashire and the North West. We handle the technical setup, test it with a pilot group, document the recovery process, and train your staff so the rollout doesn't flood your office manager with login problems. For businesses pursuing Cyber Essentials or responding to cyber insurance requirements, we map the MFA deployment to the specific controls they're asking for and provide the evidence documentation.

Our 24/7 monitoring and helpdesk handle MFA lockouts and re-enrolments as part of the fixed-price support model, so you're not troubleshooting authenticator apps at 7pm when someone's phone breaks. If you're not sure whether your current setup supports MFA or how to enforce it without breaking something critical, we'll audit what you have and give you a deployment plan that works for your business, not a textbook.