“Yes, we have MFA.”

Good.

But that’s not the question I’d stop at.

I’d ask:

Where don’t you have MFA?

Security controls have a habit of sounding absolute when they’re anything but.

A business can genuinely have multi factor authentication enabled and still have accounts, applications, protocols or administrative paths sitting outside that protection.

The problem isn’t MFA.

The problem is the assumption that because a security control exists, it must be protecting everything we think it is.

And that gap between “we have it” and “we’ve verified it” is worth looking at.

MFA works.

Let’s get something out of the way first. MFA is a good thing. CISA recommends requiring MFA wherever possible, particularly for remote access and privileged or administrative accounts. Microsoft provides several mechanisms for enforcing MFA across Microsoft 365 and Entra ID environments.

So this isn’t another article announcing that passwords are terrible and everyone should enable MFA.

We know.

The more interesting question starts after MFA has been enabled.

Because: 

“We use MFA” and “all of our important authentication paths are protected by MFA” are not necessarily the same statement.

The coverage problem.

Imagine a fairly ordinary business using Microsoft 365. Employees have Microsoft Authenticator installed. They receive authentication prompts. MFA is part of everyday life.
Ask management whether the company uses MFA and the answer is unquestionably:
Yes.
Now look a little deeper.

+ What about privileged or administrative accounts?
+ Old accounts nobody has thought about recently?
+ VPN or remote-access systems?
+ Third-party SaaS applications?
+ Service and application identities?
+ Emergency-access accounts?
+ Older applications?
+ Systems maintained by an external IT provider?

Suddenly we’re asking a different question.
Not:
Do you have MFA?
But:
Where is MFA actually enforced?

That distinction matters.

Microsoft specifically recommends blocking legacy authentication because older authentication protocols do not support MFA. Depending on the environment, older applications and protocols can therefore create authentication paths that don’t receive the protection everyone assumes is there.

Which creates an entirely plausible situation:

The organisation has MFA.
The user has MFA.
But a particular way of authenticating may not enforce it.

That’s a rather different security picture from the reassuring green tick beside: 

MFA: Enabled.

Exceptions aren’t automatically vulnerabilities.

There’s an important distinction here. Discovering an account or system that doesn’t use MFA doesn’t automatically mean somebody has screwed up.

There can be legitimate exceptions to the normal authentication setup. Emergency-access accounts, for example, may need to remain usable when normal sign-in methods fail. They still need strong, independent authentication and close monitoring. Non-human identities and applications can have different authentication requirements. Older business-critical systems may have technical limitations. Real environments are messy.

Security doesn’t improve by pretending otherwise. The useful question is whether those exceptions are known and intentional.

If something sits outside a security control, ask:

+ Why does the exception exist?

+ Who or what can use it?

+ What can it access?

+ How is it protected instead?

+ Is its use monitored?

+ Does it still need to exist?

An understood exception with appropriate safeguards is one thing. An authentication path everybody forgot about three years ago is something else entirely.

Not all MFA is equal.

There’s another layer. Even where MFA is enforced, the authentication method itself matters. SMS codes, push notifications, number matching, passkeys and hardware security keys don’t provide identical resistance to attack. CISA recommends moving toward phishing-resistant MFA, particularly for higher-risk access. 

So our original question starts evolving:

Do we have MFA?

↓

Where is it enforced?

↓

Where isn’t it enforced?

↓

Why do those exceptions exist?

↓

What authentication methods are we using?

↓

Are they appropriate for what they protect?

Now we’re no longer ticking a box. We’re beginning to understand the control.

This isn’t really an article about MFA.

Here’s the more interesting part.
The exact same problem appears throughout cybersecurity.
“We have backups.”
Great. When did you last successfully restore one?
“We have endpoint protection.”
Excellent. Are all the devices you think are protected actually enrolled and reporting?
“We patch our systems.”
Which systems aren’t being patched?
“We have a firewall.”
What can actually be reached from the internet?
“Our IT provider handles security.”
Which security responsibilities belong to them, and which still belong to you?

There’s nothing inherently wrong with any of those statements. The problem begins when the existence of a control becomes evidence of its effectiveness. It isn’t. A backup that has never been restored is an assumption about recoverability. A security agent that nobody checks is an assumption about endpoint coverage. A firewall configuration that hasn’t been reviewed is an assumption about exposure. And MFA that hasn’t been examined for coverage and exceptions is an assumption about identity protection.

From assumption to evidence.

You don’t need to distrust every security control in your business. You need to understand the important ones well enough to know what they actually do. For MFA, four questions are a good place to start:

1. Where is MFA enforced?
Identify the important accounts, applications, remote-access systems and administrative interfaces that are covered.
2. Where isn’t it?
Look for exceptions, older systems, third-party services and unusual authentication paths.
3. Why do those exceptions exist?
Separate deliberate technical decisions from forgotten configuration and historical baggage.
4. How are those exceptions protected instead?
Consider access restrictions, monitoring, stronger authentication mechanisms, network controls or whether the exception can be removed entirely. None of this requires a 94-page spreadsheet with seventeen shades of traffic-light coloring. 

The objective is simpler: 

Know what you’re relying on.

Then find evidence that it’s doing what you think it’s doing.

Cybersecurity starts with understanding.

MFA remains one of the most useful security controls an organisation can implement.
But having MFA isn’t the destination. Understanding where it works, where it doesn’t, what sits outside it and why is what turns a security feature into a meaningful security control. And the principle extends far beyond authentication. 

Because there’s an important difference between:

“We have it.”

and

“We’ve verified it.”

One is an assumption.  The other is evidence.

Know where you stand. Tanosec’s Cybersecurity Assessment looks beyond whether security controls simply exist. We help organisations understand what’s working, where meaningful gaps remain and what deserves attention first.
Cybersecurity Assessments from R14,500.