MFA at work: how to roll it out so it works

If we had to name one change with the biggest security impact for a typical company, it would be multi-factor authentication (MFA). The vast majority of attacks we analyse — from M365 account takeovers to ransomware entries via VPN — start with a password: stolen, phished or simply reused. MFA breaks that scenario. And yet we still find deployments that protect only on paper: MFA “for volunteers”, exceptions for the board, phishable methods. Below is a complete rollout guide.

Why the password alone has lost

Passwords fail systemically, not individually. They leak from third-party services and get tested everywhere (credential stuffing), users repeat them across accounts, and phishing extracts them directly. Adding a second factor means the password alone stops being enough — the attacker also needs something you have (a phone, a key) or something you are (biometrics). Industry data has been unambiguous for years: MFA blocks the overwhelming majority of automated account attacks.

But — and this “but” matters — not all MFA protects equally.

MFA methods: from weakest to strongest

SMS and voice codes. Better than nothing: they stop mass password attacks. Weaknesses: SIM swapping (number takeover), real-time phishing of the codes, delivery failures. Treat as the minimum for low-risk accounts.

Authenticator app codes (TOTP). Google/Microsoft Authenticator and similar. More robust than SMS (nothing travels over the mobile network), but the code can still be phished on a fake login page.

Push notifications. Convenient but vulnerable to MFA fatigue: an attacker with the password bombards the user with prompts until they approve “for some peace and quiet”. If push, then only with number matching and sign-in location shown.

Hardware keys and passkeys (FIDO2/WebAuthn). The gold standard: authentication is cryptographically bound to the domain, so a fake page cannot obtain a valid response — phishing and adversary-in-the-middle attacks stop working. Passkeys do the same without a physical key, syncing across the user’s devices — we covered them in our passkeys article.

The practical rule: SMS/TOTP as the floor for everyone, FIDO2/passkeys as the standard for privileged and finance accounts — and eventually for the whole organisation.

A rollout plan in five steps

Step 1: inventory. List systems with logins: central identity (M365/Google), VPN and remote access, finance systems, admin panels, key SaaS apps. Establish which support MFA/SSO and which don’t (the latter go on the replace-or-hide-behind-SSO list).

Step 2: priorities. An order that reflects real risk: (1) administrators of everything, (2) remote access — VPN, RDP, panels, (3) email and central identity, (4) finance and HR, (5) the rest of the organisation. Secure the first three groups in weeks, not quarters.

Step 3: policies, not voluntariness. MFA enforced centrally (e.g. via conditional access), with no “skip” option. Exceptions only temporary, documented, with an expiry date and compensating controls (source address restrictions). The worst deployments we’ve seen shared one trait: a two-year-old “temporary” exception for a VIP.

Step 4: enrolment and communication. Plan an enrolment window with clear instructions (visuals, 5 minutes, examples), helpdesk support and a hard deadline. Communicate the “why”: one story about a swapped invoice works better than a policy document. Require two methods per person from day one (primary + backup) — it eliminates 90% of “I can’t log in” tickets.

Step 5: close the side doors. MFA doesn’t work if it can be bypassed: disable legacy authentication protocols, enforce MFA on APIs/SSH where possible, and review service accounts — certificates and managed identities instead of passwords without MFA.

The recovery process: the weakest link

An attacker who can’t beat MFA will attack the process of resetting it. The high-profile breaches of recent years (including social engineering groups targeting helpdesks) started with a phone call: “hi, board member here, lost my phone, please reset my MFA”. Therefore:

• an MFA reset requires identity verification through a second channel (video, a manager, in person — depending on account sensitivity),
• registering a new method on a privileged account triggers an alert to the security team,
• backup codes exist but are stored like passwords (a manager, a safe), not in phone notes,
• the helpdesk has a simple refusal script: things it never does over the phone, no matter who is calling.

Traps that spoil the rollout

• MFA only “from the internet”. Enforce it inside the network too — otherwise one compromised device opens everything (Zero Trust thinking).
• 90-day session memory. Overly long sessions cancel the effect; for sensitive systems require re-authentication more often and on context changes.
• No monitoring. Failed MFA attempts and sign-ins from new locations are valuable signals — they should reach your monitoring, not a void.
• Forgotten systems. The old “vendor” VPN, the printer panel, the emergency account — an audit will find them faster than an attacker, if you order it in time.

Frequently asked questions (FAQ)

Employees don’t want to install anything on private phones. What now? You have three honest options: hardware keys (no app, tens of złoty per person), hardware TOTP tokens, or company phones for roles that need them anyway. Forcing an app onto private devices without a conversation ends in conflict — and a USB key often turns out cheaper than hours of debate.

Does MFA slow work down? Deployed well — minimally: a login from a trusted office device may require MFA once a day, and a passkey is faster than typing a password. The pain comes from bad policies (a prompt every 15 minutes) — that’s configuration, not the technology.

What about shared accounts (reception, warehouse)? First try to eliminate them (named accounts + roles). If they truly must exist: a hardware key tied to the workstation plus login restricted to specific devices/networks. A shared TOTP in a password manager is the last resort, with who-and-when logging.

What does an MFA rollout cost in a 100-person company? In licences, often nothing (MFA is included in M365/Google plans). The real cost is time: a 2–4 week project (inventory, policies, communication, enrolment support) plus perhaps FIDO2 keys for key accounts. It remains the cheapest major risk reduction on the market.

We’ve deployed MFA — are we safe? Safer by an order of magnitude, but MFA doesn’t protect against everything: sessions can be stolen after login (malware), OAuth apps bypass the login flow, and AiTM phishing breaks the weaker methods. MFA is one piece of the puzzle — together with monitoring, patching and tests that check the whole. We’re happy to verify your deployment in practice — get in touch.

Summary

Effective MFA is: enforced by policy (not voluntary), phishing-resistant for key accounts, with side doors closed (legacy auth, service accounts) and a hardened reset process. That set stops most real account attacks — at a fraction of the cost of any other control with a comparable effect. If you want to know whether your MFA would survive contact with a real attacker, we’ll test it — including the account recovery process.