What to enforce, what to avoid, and how to get it right across your organisation.
Multi-factor authentication is one of the most effective security controls available to any organisation. It is also one of the most frequently misunderstood. Too many businesses treat MFA as a checkbox, something they enabled once and assumed was handled. The reality is that a poorly implemented MFA deployment can give you a false sense of security while leaving your most critical accounts exposed.
This guide covers what good MFA looks like in practice: which methods to use, which to avoid, the mistakes we see repeatedly in client environments, and a practical approach to rolling it out properly. Whether you are starting from scratch or reviewing an existing deployment, this is the baseline your organisation should meet.
Why MFA matters more than almost anything else
Microsoft’s data is unambiguous: accounts protected by MFA block 99.9% of automated credential attacks. That is not a marketing figure. It reflects the reality that the vast majority of account compromises rely on stolen or guessed passwords, and MFA renders those credentials useless on their own.
The threat landscape has shifted. Password databases from previous breaches circulate freely. Credential stuffing tools are automated and cheap. Phishing kits are sold as a service. In this environment, a password alone is not a security control. It is a liability. MFA adds a second verification step that an attacker cannot replicate remotely, turning a trivial attack into one that requires significantly more effort, sophistication, and proximity.
But the 99.9% figure comes with a caveat: it assumes MFA is implemented correctly. Not all MFA methods are equal, and the way you deploy MFA matters as much as whether you deploy it at all.
MFA methods ranked
Not all second factors offer the same level of protection. The difference between the strongest and weakest commonly-used MFA methods is substantial, and choosing the wrong method for the wrong accounts can leave you exposed to the very attacks you thought you had mitigated.
FIDO2 hardware security keys
FIDO2 keys are the gold standard. A physical USB or NFC device that cryptographically proves your identity without transmitting any secret over the network. There is nothing to phish, nothing to intercept, and nothing to social-engineer. The user taps the key, the authentication completes, and the attacker has no avenue of approach. For privileged accounts, admin access, and anyone with elevated permissions, this is the method to mandate. The cost per key is minimal compared to the cost of a single compromised admin account.
Authenticator apps with number matching
Microsoft Authenticator and similar apps that support number matching represent a significant step up from basic push notifications. When you sign in, the app displays a number that you must match on screen before approving. This defeats MFA fatigue attacks entirely, because blindly tapping 'approve' no longer works. The user has to actively engage with the prompt. For most organisations, this is the strongest practical method for the general workforce: it requires no additional hardware, works across platforms, and provides genuine resistance to common attack patterns.
Push notifications without number matching
Standard push-based MFA is better than nothing, but it has a well-documented weakness. In an MFA fatigue attack, the attacker triggers repeated authentication prompts until the user, frustrated or confused, taps approve to make them stop. This is not theoretical. It was the method used in the 2022 Uber breach and several high-profile incidents since. If you are still using push notifications without number matching, you should upgrade. The configuration change takes minutes and the security improvement is substantial.
SMS verification codes
SMS codes are the weakest widely-used MFA method and should be treated as a last resort. They are vulnerable to SIM swapping, where an attacker convinces or bribes a mobile carrier into transferring your number to their SIM. They are vulnerable to SS7 network interception. They arrive in plain text and can be read from lock screen notifications. If SMS is the only MFA option available for a particular service, use it, because any MFA is better than none. But do not choose it when stronger alternatives exist, and never rely on it for privileged or administrative accounts.
“The question is not whether you have MFA enabled. The question is whether an attacker who has your password would actually be stopped by it. For most organisations, the honest answer is: it depends on which account they target.”
Common mistakes
We review MFA deployments across dozens of organisations every year. The same mistakes appear consistently, and nearly all of them stem from the assumption that enabling MFA is the same thing as implementing it properly. These are the gaps that attackers actually exploit.
Enforcing MFA selectively
The most common and most dangerous mistake. Organisations enable MFA for regular users but leave admin accounts, service accounts, or executive accounts without it. This is precisely backwards. Privileged accounts are the ones attackers target first and the ones that cause the most damage when compromised. Every account that can authenticate to your systems needs MFA, without exception. If a service account cannot support MFA, that is a risk that needs documenting and compensating controls.
Leaving legacy authentication enabled
Legacy authentication protocols like POP3, IMAP, and older versions of ActiveSync do not support MFA. They authenticate with a username and password alone. If these protocols are still enabled in your environment, an attacker can bypass your entire MFA deployment by authenticating through a legacy pathway. This is not a theoretical risk. It is one of the most common attack vectors we see in Microsoft 365 environments. Block legacy authentication at the tenant level using conditional access policies.
No backup authentication methods
People lose phones. Phones break. Batteries die at the worst possible moment. If your MFA deployment has no fallback method, users get locked out of their accounts and your helpdesk gets flooded with reset requests. Worse, the pressure to resolve lockouts quickly can lead to insecure recovery practices, like resetting MFA over the phone without proper identity verification. Configure backup methods for every user: a secondary device, backup codes stored securely, or a FIDO2 key kept in a safe location.
Not auditing registered MFA devices
After an initial compromise, one of the first things a sophisticated attacker does is register their own MFA device on the compromised account. Once they have done this, they have persistent access that survives a password reset. If you are not regularly reviewing which devices are registered against each account, you will not detect this. Build a quarterly review of MFA registrations into your security operations. Look for accounts with unexpected devices, devices registered from unusual locations, and accounts with only one registration method.
Treating MFA as a one-time project
MFA is not something you deploy and forget. New users join. New applications are added. Authentication policies change. If you do not have an ongoing process for ensuring every new account and every new service is covered by MFA from day one, gaps will appear. Incorporate MFA verification into your onboarding process, your application procurement checklist, and your regular security reviews.
of automated credential attacks blocked by properly implemented MFA
of breaches involve compromised credentials, the exact problem MFA solves
more likely to be breached without MFA on privileged accounts
Implementation approach
A successful MFA rollout is methodical, not rushed. The organisations that get the best results follow a structured sequence that addresses risk, minimises disruption, and builds a foundation for ongoing security rather than a one-off project.
Audit your current state
Before changing anything, understand where you stand. Review every account in your identity provider. Identify which accounts have MFA enabled, which methods they use, and which accounts have no MFA at all. Pay particular attention to admin accounts, shared mailboxes, service accounts, and any accounts that authenticate to cloud services. You cannot fix what you have not measured, and most organisations are surprised by how many gaps this exercise reveals.
Disable legacy authentication
Block legacy protocols at the tenant level before you enforce MFA for users. If you enforce MFA while legacy authentication is still available, you have created a false sense of security. In Microsoft 365, this is done through conditional access policies or security defaults. Test the change in report-only mode first to identify any applications or workflows that still depend on legacy protocols, then remediate those before enforcing the block.
Deploy to privileged accounts first
Start with your highest-risk accounts: global admins, Exchange admins, security admins, and anyone with elevated permissions. These are the accounts that, if compromised, give an attacker the keys to everything. Require phishing-resistant MFA for these accounts, ideally FIDO2 keys or Windows Hello for Business. Do not proceed to wider rollout until every privileged account is protected.
Roll out to the wider organisation
Once privileged accounts are secured, extend MFA to all users. Use authenticator apps with number matching as the default method. Communicate the change clearly, provide simple setup guides, and give users a reasonable window to register their devices. Run the rollout in phases if needed, department by department, but set a firm deadline by which every account must be enrolled. Registration campaigns with conditional access work well here: users are prompted to register the next time they sign in.
Configure conditional access policies
MFA should not operate in isolation. Combine it with conditional access policies that evaluate sign-in risk, device compliance, location, and application sensitivity. A sign-in from a managed device on the corporate network might require MFA once per session. A sign-in from an unfamiliar location on an unmanaged device should require stronger authentication or be blocked entirely. This is where MFA becomes part of a broader zero-trust posture rather than a standalone control.
Monitor and iterate
After deployment, monitor authentication logs for anomalies. Watch for MFA registration events from unexpected locations, repeated MFA failures that might indicate an attacker testing credentials, and successful authentications from unusual device types. Review your policies quarterly. Update your methods as new options become available. Security is a process, not a destination.
Beyond basic MFA
The next evolution is phishing-resistant authentication. Traditional MFA methods, even strong ones like authenticator apps, can be defeated by real-time phishing proxies that intercept both the password and the MFA token simultaneously. This is not theoretical. Tools like Evilginx and Modlishka make it straightforward for attackers to set up convincing proxy sites that capture session tokens as users authenticate.
Phishing-resistant methods like FIDO2 keys and Windows Hello for Business are immune to this attack because they bind authentication to the legitimate domain. The key will not respond to a phishing proxy because the proxy is not the real site. This is why organisations handling sensitive data or operating in high-risk sectors should be planning a migration path toward phishing-resistant authentication for all users, not just privileged accounts.
Conditional access policies add another layer of intelligence. Rather than applying the same MFA requirement to every sign-in, conditional access evaluates context: the user’s location, the device’s compliance state, the sensitivity of the application, and the risk level of the sign-in itself. A user on a managed device in the office might authenticate smoothly. The same user signing in from a new country on an unrecognised device might face additional verification or be blocked entirely. This is MFA as part of a zero-trust architecture, not just a standalone gate.
“MFA is the single control that turns a trivial credential attack into a sophisticated one. It does not make you invulnerable, but it makes you dramatically more expensive to attack. And attackers, like everyone else, follow the path of least resistance.”
Need help getting MFA right?
We help organisations audit their existing MFA deployment, close the gaps, and implement phishing-resistant authentication where it matters most. Whether you are starting from scratch or hardening an existing setup, we can guide you through the process with minimal disruption to your team.
A focused MFA review typically takes a few hours and gives you a clear picture of where you stand and what needs to change. No sales pitch. Just an honest assessment of your current posture and a practical plan to improve it.