topicsidentity & access3 numbers2 guides

MFA gaps

The control works; the coverage lies. Where MFA enforcement quietly breaks down, from legacy admin accounts to the app passwords that bypass it by design.

in one lineAn MFA gap is any account or access path where a second factor is not required, leaving credentials as the only barrier.

the numbers

all the numbers →

1what it is

Multi-factor authentication (MFA) requires a second form of verification beyond a password to authenticate. The user proves they know the password and that they have access to a second factor, typically a code from an authenticator app, a hardware key, or a push notification.

An MFA gap is any account, application, or access path where this second factor is not required. The account can be accessed with credentials alone.

MFA gaps usually come from deployment that stopped halfway. MFA gets enforced in one place while other places are never updated. Legacy configurations predate the current policy and nobody rechecks them. Service accounts get excluded because MFA interrupts automated processes. The gap is rarely a deliberate decision that MFA wasn't needed.

2why it accumulates

MFA is typically rolled out in phases. Email first, because that's where most logins happen and where compromise has the most visible impact. Then VPN, then the main directory, then SaaS tools as they're added.

But rollouts rarely touch everything at once. Old configurations stay. New users get MFA required; people who joined before the policy change may still be running on the old setting. Admin accounts are sometimes excluded during rollout because getting MFA working on every admin account in a live environment takes coordination.

Service accounts are a specific category. MFA typically can't be applied to non-interactive accounts the same way as human accounts. They need a deliberately chosen alternative form of protection, and without one they're often left with none at all.

Over time, each of these gaps is forgotten or assumed to be someone else's responsibility to fix.

3what it costs you

Credentials are compromised regularly. Phishing, password reuse from breaches at other services, credential stuffing at scale. Verizon's DBIR 2026 puts the use of stolen credentials as a factor in 36% of breaches. MFA breaks the path from compromised credential to successful login.

Microsoft's research puts the figure at more than 99.2% of account-compromise attacks blocked by MFA. That figure applies to accounts with MFA enforced. An account without it doesn't benefit from that protection.

The highest-priority gap is admin accounts without MFA. An admin account reached via compromised credentials gives an attacker the highest privilege in the relevant system. A password alone is the only barrier between those credentials and that access level.

The second category is legacy accounts. Accounts created before MFA policy was in place and never updated. They're often less visible because they don't fail authentication, they just authenticate with fewer factors than the current standard.

what it looks like when it goes wrong

Three ways this tends to go, each one taken from a real case.

your company
the gap nobody seesMFA covers most logins, and the ones it misses are the ones attackers find.a password is the only lock
  1. howLeaked passwords are tried against customer accounts until some open.
    what leavespersonal details of customers and their contactswho ends up with itfraudsters
    it happened23andMe, 2023
  2. howAn old password opens a data store that never required a second step.
    what leavesthe whole database in one downloadwho ends up with itan extortion group
    it happenedThe Snowflake wave, 2024
  3. howA stolen password gets through the one remote-access door without a code.
    what leavescontrol of the systems customers rely onwho ends up with ita ransomware crew
    it happenedChange Healthcare, 2024

4what works

The enrollment report is where reality shows up. Any IdP can list which accounts have MFA enrolled and which don't, and which accounts have it enrolled but not actually required at login, a quieter gap that the same report exposes. That single export usually reveals more holes than anyone expected, and admin accounts deserve the first look: an admin account reachable with a password alone pairs the weakest protection with the highest privilege, the most urgent combination an environment can contain.

The report only covers what the IdP sees, so the second question is about bypass paths. An application with its own login page that doesn't route through the IdP gets no benefit from IdP MFA, however strictly enforced. A map of which applications authenticate through the directory and which accept direct logins turns those invisible gaps into known ones. VPN and remote access deserve their own check for the same reason, since VPN authentication runs separately from the IdP in many configurations, and an environment with MFA on every SaaS login but none on the VPN has secured the windows and left the door.

Service accounts are the category where standard MFA genuinely doesn't fit, and the workable pattern is compensating controls: IP restrictions, short-lived tokens, dedicated narrowly scoped credentials, and monitoring for unusual access patterns. The distinction worth maintaining is between an account deliberately protected another way and an account that simply fell outside the policy. Most MFA gaps belong to the second group, and closing them is mostly the work of finding them.

on the record

← all topics

your turn

what you can do about it

  1. this week

    Export your MFA enrollment report and start with admin accounts.

    Then list the apps and VPN logins that do not go through your identity provider.

  2. go deeper

  3. if you're not sure where to start

    Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.

    open the checklist →

the letter · every two weeks

one access gap in your inbox, with the fix.

Every issue takes one way access creeps in, shows a real incident where it went wrong, and ends with one thing to check that week. Written for the people who run the tools, without a security team behind them.

  • 1one mechanism, explained plainly
  • 2one real incident, taken apart
  • 3one step you can take on Monday

get the next issue

One email every two weeks. Your address stays here and is never passed to vendors. One click to unsubscribe. Privacy.