MFA Is On. But Is It Actually Protecting You?

Turning on MFA is not the same as being protected by MFA. Here's the difference — and why most businesses are more exposed than they think.

'We have MFA turned on.' It's one of the most common things we hear when we first talk to a business about their security posture. And it's often followed by a quiet assumption: we're covered. The reality is more complicated — and more important to understand.

MFA Enabled Is Not the Same as MFA Enforced

Multi-Factor Authentication is one of the most effective security controls available. When properly implemented, it stops the vast majority of credential-based attacks — which is how most breaches start. But 'having MFA' and 'having MFA that actually works' are two very different things.

We regularly find businesses where:

✗MFA is turned on for most users — but not all. And the exceptions are often admin accounts

✗MFA can be bypassed by logging in through legacy authentication protocols that don't support it

✗There are no Conditional Access policies, so MFA can be satisfied from any device, any location

✗Helpdesk staff can disable MFA on request — and frequently do when users find it inconvenient

In each of these cases, the business believes they're protected. An attacker knows exactly where the gaps are.

The MFA Fatigue Attack — A Real and Growing Problem

Even when MFA is properly enabled, attackers have adapted. MFA fatigue (also called MFA bombing) is a technique where an attacker who already has a user's password repeatedly sends MFA push notifications to their phone — sometimes dozens in a row. The goal is simple: wear the user down until they approve the request just to make the notifications stop.

This attack has been used successfully against large organisations including Uber and Microsoft. It works on standard push-based MFA — the kind most businesses use. The solution is phishing-resistant MFA — hardware security keys or passkey-based authentication that can't be intercepted or spammed.

What Conditional Access Actually Does — and Why It Matters

Microsoft 365 supports Conditional Access policies — rules that define the conditions under which a login is permitted. Think of it as context-aware security:

→Is this login coming from a managed, compliant device?

→Is the user logging in from an unusual location or country?

→Is this a high-risk sign-in according to Microsoft's threat intelligence?

→Is the user accessing a high-sensitivity application?

MFA without Conditional Access is a lock on your front door with an open window next to it.

The Privileged Account Problem

The highest-value accounts in any Microsoft 365 environment are admin accounts — the ones that can add users, change security settings, access all mailboxes, and reset other people's passwords. If a single admin account is compromised, an attacker can own your entire Microsoft 365 tenant in minutes.

Best practice requires that admin accounts are separate from day-to-day user accounts, protected by phishing-resistant MFA, governed by Privileged Identity Management (PIM), and monitored for unusual activity. Very few SMBs have this in place.

A Quick Self-Assessment

Ask your IT provider or internal team these questions:

?Are there any user accounts or admin accounts that can log in without MFA?

?Do we have Conditional Access policies that block logins from non-compliant devices?

?Are legacy authentication protocols (SMTP, IMAP, POP3) disabled in our Microsoft 365 tenant?

?Do our admin accounts use separate credentials from standard user accounts?

?When did we last audit who has admin privileges in our environment?

If any of these answers are unclear or concerning, that's exactly where to start.

// NOT SURE WHERE YOU STAND?

Book a free IT & security check.

We identify your top 3 risks and tell you exactly what to fix — no jargon, no obligation.

Book a Free Discovery Call →

RELATED SERVICES:

Microsoft 365 Security Essential Eight Cybersecurity & Risk