Essential Eight Series Part 5: Multi-Factor Authentication: Strong in Theory, Uneven in Practice
Most organisations we work with have MFA. They'll tell you so with confidence. And they're not wrong , but they're often not as right as they think.
MFA has become the default answer to identity risk, and for good reason. Done well, it dramatically reduces the likelihood of a credential-based breach. The problem is that "done well" is harder than it looks. In practice, MFA coverage is almost always uneven. Well-implemented on some systems, absent or easily bypassed on others.
That gap is exactly where attackers spend their time.
Not All Access Is Created Equal
Think about how many different ways an employee might access your systems in a day. There's the obvious stuff: email, file storage, business applications. But there's also the VPN, the admin portal, cloud management consoles, infrastructure tooling, third-party SaaS platforms, and a long tail of internal systems that have been running quietly for years.
MFA tends to get deployed where it's easiest - Microsoft 365, the main SSO, maybe the VPN. That's a reasonable starting point. But it leaves a significant number of access paths unprotected, and those paths often lead to the most sensitive parts of the environment.
An attacker who can't get through your Microsoft login might still find an unprotected admin interface, a legacy remote access tool, or a cloud management console that was set up before MFA enforcement was on anyone's radar.
The Legacy Authentication Problem
One of the most consistent gaps we see is legacy authentication protocols - SMTP, IMAP, POP3, and older Exchange authentication mechanisms that don't support modern MFA at all.
These protocols predate the way we think about identity security today. They were designed for a world where the network perimeter was the primary defence. That world doesn't exist anymore.
If your organisation still has legacy authentication enabled - and many do, often to support older devices, printers, or line-of-business applications - then you have accounts that can be authenticated without any MFA challenge at all. Blocking legacy authentication often surfaces dependencies that nobody knew were still active, which is uncomfortable in the short term but exactly the kind of visibility you need.
MFA Fatigue: When Frequency Becomes the Attack
There's a relatively simple attack that has been surprisingly effective against organisations with otherwise solid MFA: just ask.
Push notification MFA works by sending an approval request to the user's phone. Attackers who have obtained valid credentials will trigger request after request, banking on the user eventually tapping "approve" out of frustration, confusion, or the assumption that the prompts are a system glitch. It's called MFA fatigue or MFA bombing, and it works more often than it should.
The countermeasure is straightforward. Number matching or additional context in the approval prompt makes it much harder for a user to blindly approve a request. But those controls require configuration, and many organisations haven't applied them.
This is a good example of a broader pattern: the technology exists, the setting is there, but nobody turned it on.
Service Accounts: The Identity Nobody's Watching
Service accounts are easy to overlook in MFA discussions because they're technically not people. They're credentials used by applications, scripts, and automated processes to authenticate to other systems.
That framing leads organisations to treat them differently and attackers know it. Service accounts often have significant privileges, rarely get reviewed, and almost never have MFA applied. In many environments, the password hasn't changed in years.
Hardening service accounts means understanding what they are, what they have access to, and whether that access is still necessary. It also means applying controls appropriate to the risk. Whether that's managed identities, certificate-based authentication, or at minimum, tightly scoped permissions and regular review.
Conditional Access: Getting Smarter About Trust
The most mature implementation of MFA isn't just "always ask for a second factor." It's making authentication decisions based on context - where the user is, what device they're on, what they're trying to access, and whether the pattern looks normal.
Conditional access policies let you apply MFA selectively and intelligently: requiring stronger authentication for admin roles or sensitive applications, blocking access entirely from high-risk locations, and stepping up verification when something looks unusual. Combined with risk signals from your identity platform, this creates an authentication layer that responds to behaviour rather than just policy.
It also means you stop treating a low-risk employee logging in from their work laptop at 9am the same way you treat an unusual login from an unfamiliar country at 3am.
Where Identity Meets Infrastructure
One of the observations that comes up regularly in our work: MFA tends to protect identity platforms well. Your Microsoft or Google environment is probably in reasonable shape. The gaps appear when you look at how people access infrastructure directly.
Server management interfaces, hypervisor consoles, network device administration, firewalls, backup and recovery platforms, and even HR platforms. These often sit outside the main identity stack, with their own local credentials and no MFA requirement. From a pure business risk perspective, these are some of the highest-value targets in the environment.
The Essential 8 requirement for MFA applies not just to user accounts, but to privileged access. If your system administrators can reach the most sensitive parts of your environment without any additional authentication challenge, you have a gap worth addressing.
What Should You Do?
Strong MFA implementation isn't just coverage. It's coverage in the right places, with the right controls, and with the configuration actually turned on.
That means:
MFA enforced across all external-facing access, including VPN, remote desktop, and cloud platforms
Legacy authentication protocols blocked or tightly controlled
Push notification MFA upgraded to number matching or phishing-resistant methods (passkeys, FIDO2 hardware keys) for privileged accounts
Service accounts inventoried, reviewed, and handled appropriately
Conditional access policies in place that reflect actual risk
Infrastructure access, not just application access, covered
Most organisations are somewhere on this journey. The goal isn't perfection, it's knowing where your gaps are and working through them in order of risk.
The Practical Next Step
If you're not sure where your MFA coverage actually stands, the starting point is an honest audit. Not of what your policy says, but of what the authentication logs show. Legacy authentication attempts, accounts without MFA enrolled, admin access that bypasses conditional access policies: these show up in the data if you look for them.
If you'd like help working through that assessment, or you want to understand what your current configuration means for your Essential 8 maturity, we're happy to have that conversation.
Continuing the Series
This article forms Part 5 of our Essential Eight series examining how these controls operate in real environments.
Next, we will look at Microsoft Office Macros, still an easy entry point into your network.