Getting to near-total MFA coverage

why near-total coverage is the real target

Partial MFA gives a false sense of progress. A company that turns on MFA for the main staff population and reads 90% coverage on the dashboard often treats the rollout as finished. The 10% that remains is rarely random. It tends to be the accounts that were awkward to enrol: shared logins, service accounts, contractors, an executive who asked for an exception, a legacy mailbox nobody wanted to touch. Those are also the accounts an attacker prefers, because a password is all that stands in the way.

An attacker does not test every account against your strongest control. They look for the account that still accepts a password alone, and they target it. Credential stuffing and password spray campaigns are built to find exactly these accounts at scale. Ninety percent coverage means one in ten accounts is still a single-factor target, and the attacker only needs one.

This is why the goal is a number close to 100%, account by account, rather than a high average. Coverage is only meaningful when it includes every authentication path and every account type.

the methods, strongest to weakest

Not every second factor offers the same protection. "MFA" covers a range of methods that differ widely in how well they resist a real phishing attempt, and a coverage number that counts all of them equally hides this.

• Passkeys, FIDO2 security keys · Strength: Strongest (phishing-resistant) · What it resists: Phishing, adversary-in-the-middle proxies, credential replay. The factor is bound to the legitimate domain. · What it does not resist: Physical theft of the device combined with the PIN or biometric that releases it, a narrow case.
• App-based push with number matching · Strength: Strong · What it resists: Push fatigue and blind approval, because the user has to type a number shown on screen. · What it does not resist: Adversary-in-the-middle proxies in some flows. Better than plain push, not phishing-resistant.
• TOTP authenticator app codes · Strength: Good · What it resists: Password-only attacks, SIM-swap, SMS interception. The code never travels over the phone network. · What it does not resist: Adversary-in-the-middle phishing, which captures the code in real time during its short validity window.
• SMS and voice one-time codes · Strength: Weakest · What it resists: Password-only attacks at the most basic level. · What it does not resist: SIM-swap, SS7 interception, and real-time phishing. CISA and NIST SP 800-63B treat SMS as the weakest available factor.

The practical reading: any MFA is better than none, so SMS is still a meaningful improvement over a password alone for a standard user. The gap between the top and bottom of the table is large, and it matters most for the accounts with the most access.

For administrators, use phishing-resistant factors. Passkeys or FIDO2 security keys for every admin account is the standard to aim for. Admins are the accounts an adversary-in-the-middle phishing kit most wants, and those kits defeat SMS, TOTP, and ordinary push. Cyber insurers have started to ask specifically whether privileged accounts use phishing-resistant MFA rather than any MFA, which reflects where the risk concentrates.

the single highest-value move: admins first

If you do one thing before anything else, enforce MFA on every administrator account.

An admin account without a second factor is the highest privilege in your environment protected by a password alone. A compromised global administrator account can create accounts, change policy, disable logging, and reach data across the whole tenant. The blast radius is the entire organization.

Admin accounts are also a small, knowable population. You can list every global administrator, every Workspace super admin, every privileged role in Entra, and every admin console for the major SaaS tools, then confirm each one has a phishing-resistant factor enforced. This is a short project with a large effect. It does not depend on a company-wide rollout or any user communication campaign.

A related point on hygiene: admin work should happen on separate, named admin accounts, not on the daily-driver account a person also uses for email and browsing. Separating the two, and putting the strongest factor on the admin account, is the baseline to aim for.

legacy authentication: the bypass that makes the number lie

A coverage rollout that ignores legacy authentication produces a number that is not true.

Legacy protocols such as IMAP, POP3, SMTP basic authentication, and older email and calendar clients were designed before modern authentication existed. They authenticate with a username and password sent straight to the server. There is no step in that flow where an MFA challenge can be inserted. When a client connects this way, the MFA policy is not evaluated at all.

This is not a marginal path. Microsoft has reported that the large majority of password spray and credential stuffing attacks against Microsoft 365 ride on legacy authentication, precisely because it skips every control layered on top of interactive login. An attacker who finds one mailbox still reachable over SMTP basic auth has a password-only door into your tenant.

Blocking legacy authentication is part of the rollout. On Microsoft 365 and Entra, this means a conditional access policy that blocks legacy authentication flows, ideally rolled out in report-only mode first so you can see which accounts and devices still use it before you enforce. On Google Workspace, it means disabling access for less secure apps and moving any remaining integrations to OAuth. The common offenders are shared mailboxes, scanners and multifunction printers, older CRM connectors, and developer tools wired directly into Exchange. Each needs a modern-auth path or a managed alternative before the block goes live.

conditional access and security defaults

MFA works when it is enforced by policy. It fails when it depends on users opting in. People defer the prompt, skip the enrolment email, and route around a request that is optional. Enforcement is what turns a registered method into a protected login.

On Microsoft 365 and Entra, security defaults give you a baseline: MFA required for administrators and a push toward MFA for all users, with legacy authentication blocked. They are a reasonable floor for a smaller organization. Conditional access gives you control beyond that floor: rules that require MFA based on context such as the user, the application, the device state, the network location, and the sign-in risk the platform calculates. On Google Workspace, the equivalent is enforcing 2-Step Verification through organizational unit policy and applying context-aware access rules.

Context-aware rules let you tighten without adding friction everywhere. You can require a phishing-resistant factor for admin consoles, require MFA for any access to sensitive applications, and step up the challenge when a sign-in looks risky, while keeping a routine login on a known managed device straightforward.

One caution: conditional access policies accumulate exceptions over time, each added for a reason that made sense at the moment, and the sum can quietly carve a wide hole in what the policy actually covers. Review exceptions on a schedule rather than setting and forgetting them.

the service and shared account problem, without waiving MFA

This is the part of a rollout where coverage usually stalls. Service accounts and shared logins do not fit the interactive MFA model, and the easy response is to waive the requirement and move on. That waiver is the gap an attacker walks through. Do not waive MFA. Fix the root cause instead.

Service accounts and non-human identities. A service account authenticates programmatically, with a secret, a certificate, or a password. There is no interactive session in which to present a challenge. The answer is a different control set suited to the account type, not an exception. Give the account a managed identity where the platform supports one, so there is no standing credential to steal. Where a managed identity is not available, use certificate-based authentication rather than a long-lived password, scope the account to minimum permissions, rotate its credential on a short schedule, restrict the networks it can authenticate from, and alert on use outside its expected pattern.

Shared accounts. A shared login is one set of credentials used by several people. It breaks MFA in practice, because the second factor has to live somewhere and ends up on one person's device or in a shared inbox. It also breaks accountability, since no single person owns the actions taken through it. Replace the shared login with named accounts, one per person, each with its own MFA. Where several people genuinely need the same privileged function, grant it to their named accounts through a role or group rather than through a shared credential.

The principle across both cases is the same. The accounts that do not fit interactive MFA are not a reason to lower the bar. They are a reason to apply the right control.

a break-glass account

There is one deliberate, tightly controlled exception, and it exists to protect you, not to convenience anyone.

A break-glass account is an emergency-access account with the highest administrative rights, kept aside so that an MFA outage or a misconfigured policy cannot lock you out of your own tenant. If your identity provider's MFA service has an incident, or a conditional access change goes wrong and starts blocking everyone, the break-glass account is how you get back in to fix it. Every well-run Microsoft 365 environment keeps at least one, usually two, and the same logic applies on Google Workspace.

The account is an exception to your conditional access policies by design, which is exactly why it needs heavy compensating control. Name it so it does not advertise itself as a high-privilege target. Give it a long, unique password stored offline in a sealed, secured physical location rather than in the shared password manager. Where it carries a second factor, prefer a hardware key stored separately from the password. Never use it for routine administration. Set an alert that fires on any sign-in. Test it on a schedule, so you know it works before the day you depend on it.

the rollout sequence

1. Measure current coverage. Start with the real number, not the dashboard headline. Count accounts with MFA registered and actually enforced. Separate humans from service accounts. Note which accounts use phishing-resistant factors versus phishable ones. Check whether legacy authentication is still enabled anywhere.

2. Enforce on admins. Every administrator account on a phishing-resistant factor, enforced by policy. Do this before the broad rollout, because it is independent of it and removes the largest single risk first.

3. Block legacy authentication. Roll out the block in report-only mode to find what still uses legacy protocols, migrate or replace those connections, then enforce. Until this is done, the rest of the coverage number is not trustworthy.

4. Phase enforcement for users. Move the general population to enforced MFA in waves rather than all at once. Communicate before each wave: what is changing, why, what the person needs to do, and where to get help. Run a short, staffed support window around each wave so a stuck user gets unblocked in minutes.

5. Handle exceptions properly. Service accounts get their compensating control set. Shared logins get replaced with named accounts. The genuine emergency case gets a documented break-glass account. An exception that is engineered and monitored is fine. An exception that is a quiet waiver is the gap.

6. Hold the line with policy. New accounts get MFA from day one through default policy. Review conditional access exceptions on a schedule and remove the ones that no longer have a reason. Re-measure coverage periodically, because environments drift.

common reasons coverage stalls

The waiver pile. Each account that was hard to enrol got an exception, and the exceptions were never revisited. Treat every exception as temporary until it has an engineered control behind it.

Legacy auth left on. The interactive logins are covered and the dashboard looks good, while a legacy protocol still accepts passwords on a mailbox or an integration.

Service accounts treated as out of scope. Because MFA does not apply to them, they get left out of the program entirely rather than given the control set that does apply. Half the account population can sit unprotected this way.

Phishable factors counted as done. Coverage reads 100%, much of it is SMS, and the admin accounts a phishing kit targets are no better protected than a standard user. The number is met, the resistance is not.