SECURITY
MFA isn’t finished when you switch it on
5 min read
Enabling multifactor authentication is the start of the control, not the completion of it, because coverage gaps, weak second factors and an unreviewed exemption list each leave accounts reachable with a password alone.
Multifactor authentication gets reported as a binary. It is on, the project is closed, the board slide says ninety-something percent.
That percentage is usually measuring registration rather than enforcement, and even where it measures enforcement it says nothing about the strength of the method or the size of the exemption list. Three separate problems, one number.
Problem one: coverage is not what the dashboard says
Registration and enforcement are different things. An account can have an authenticator registered and still be reachable without it, if no policy requires it for the application being accessed, or if legacy authentication is available.
The question worth asking is not what percentage have registered, but how many successful sign-ins in the last thirty days completed without a second factor. That number is usually higher than expected and it is the one that matters.
Problem two: not all second factors are equal
SMS and voice are better than nothing and are the weakest commonly deployed options, susceptible to SIM swap and interception. Push notification approval is stronger and vulnerable to fatigue attacks, where an attacker with a valid password sends repeated prompts until someone taps approve to stop the noise.
Number matching mitigates the fatigue problem. Phishing-resistant methods — hardware keys and passkeys — remove a class of attack entirely and are worth deploying for administrators first even if the wider rollout takes longer.
- Administrators on phishing-resistant methods, as a priority over universal coverage
- Number matching enabled, so approval requires reading a code rather than tapping once
- SMS and voice retired where a stronger method is available to that user
- A documented path for people who genuinely cannot use the primary method
Problem three: the exemption list
Every multifactor rollout creates exemptions. A service account that cannot do interactive sign-in. A legacy application. An executive who objected. A contractor onboarded in a hurry.
Each was granted for a reason and almost none are reviewed. Over time the exemption group becomes a list of the accounts an attacker would most like to have, which is precisely the inverse of the intent.
The fix is procedural: exemptions in a named group, each with a recorded reason and owner, reviewed quarterly, with service accounts moved to managed identities or certificate-based authentication where the platform allows.
What good looks like after a year
Sign-ins completing without a second factor are a known, small and documented set. Administrators use phishing-resistant methods. The exemption list is shorter than it was six months ago rather than longer.
None of those are visible on a registration percentage, which is why the percentage is the wrong thing to report.
Questions we get asked
Which multifactor method should we standardise on?
Phishing-resistant methods such as hardware security keys or passkeys where the platform and devices support them, with authenticator app push and number matching as the broad default. SMS is a fallback for people who have no other option, not a standard.
What about service accounts that cannot do multifactor?
Move them off password authentication rather than exempting them indefinitely. Managed identities, certificate-based authentication or workload identities remove the interactive sign-in problem. Where none is possible, the account should be restricted by location, application and privilege, and treated as a known exception with an owner.
How do we stop MFA fatigue attacks?
Enable number matching so an approval requires reading and entering a code rather than tapping a button, and alert on repeated failed or denied prompts for a single account, which is the signature of the attack in progress.