Passwords are not enough: why MFA still is not everywhere

Multi-factor authentication, MFA for short, is the principle that a user identifies with more than one factor: something you know, something you have, and in some cases something you are. It is not a product and not a checkbox, but a property of the way an organisation grants access. The "something you have" factor sits on a spectrum from weak to strong: a code by SMS at the weak end, a push notification in the middle, and a hardware-bound key that only responds to the correct domain name at the strong end. That last class is called phishing-resistant, because the factor cannot be transferred to a spoofed login page. Anyone who says "we have MFA switched on" says nothing yet about where on that spectrum they sit, and even less about where it is and is not in place.

It is precisely that difference that defines the painful conversation in 2026. On paper, almost every organisation has MFA. In practice it is in place where it was easy to switch on, and missing where it truly counts. This is not a matter of ignorance among Operations teams. It is a matter of architecture debt: legacy systems that do not speak modern authentication, service accounts that were never designed to carry a second factor, and connections with third parties where the arrangements date from a time when a password still sufficed. Anyone who wants MFA in place "everywhere" discovers there is no button that switches it on everywhere. They need a sequence.

Why is MFA still not everywhere?

The short answer is that in the typical corporate environment MFA runs into three kinds of hard edges, and each of those edges calls for a different solution than "flipping the toggle".

The first edge is legacy. Part of the application landscape speaks protocols from another era. Old mail clients, file shares, some industrial management interfaces, on-premise applications that never received a federation connection. Those systems accept a password and nothing else. Landing a second factor on them requires either a replacement client, or a gateway in front of them, or disconnecting the network the system hangs on. These are interventions in the architecture, not a setting in an admin portal. As long as that intervention is not planned, the edge remains, and with the edge a path that an attacker follows without trouble once a password has leaked.

The second edge is service accounts and machine-to-machine traffic. A service account is an account that is not used by a person but by a process: a batch job, a connection between two systems, an agent that collects telemetry. A second factor in the sense of "something you have" does not naturally fit something that is not a person. The modern implementation of this is certificate-bound or identity-bound machine credentials with a short lifespan, controlled by a central policy. But the existing landscape often still hangs together on long, fixed service-account passwords, sometimes shared between environments, sometimes documented in a spreadsheet whose owner no one can still name. For those accounts, something applies that NIST sets out in SP 800-63B and that NCSC also repeats in its guidance: a second factor only makes sense if there is an identity you can bind it to. For a nameless shared service account, the first step is not MFA, but putting the identity in order.

The third edge is third-party connections. The accountant who works in your financial system, the supplier who needs access to your management portal, the vendor who provides remote support. Here your MFA policy is not the only variable. The other party has its own access model, its own identity provider, and its own set of constraints. An organisation that leans here only on "we require MFA" discovers that enforcement is weaker than it thinks: a shared account on the other side, an exception that was once "temporary", a connection through an API key that knows no second factor. Phishing-resistance on your own workplace yields little if the access route through a third party remains vulnerable.

What does phishing-resistance mean in practice?

Not every MFA implementation offers the same protection, and that is the difference the common talk of "MFA on" conceals. The factor you add has its own vulnerability. A code by SMS can be intercepted through SIM swapping or through a spoofed login page that has the user type the code over themselves. A push notification is susceptible to what is known as push bombing: the attacker hammers the button until the user approves out of irritation. The strongest class, hardware-bound keys that follow the original FIDO protocol, is by FIDO Alliance design bound to the domain the user pairs with. A spoofed page on a different domain name receives no valid response, however convincing the page may look.

For Operations teams this means that "MFA" without mention of the type is a meaningless status. An organisation can report that 100 percent of its accounts have MFA, and at the same time be almost entirely susceptible to modern attacks because the added factor sits on the weak part of the spectrum. CISA points this out consistently in its publications: for the most targeted attacks on senior or privileged accounts, only phishing-resistance is a serious answer, and for the rest of the organisation any non-SMS form is already a major step forward. The practical line is therefore not "everything at the strongest level", but "the strongest level first where the damage would be greatest".

Which sequence works in practice?

This is where the architecture choice returns. An MFA rollout that wants to do everything at once gets stuck at the weakest point: the legacy edge that does not take part, the service account that cannot, the external connection that lives somewhere else. A rollout that works phase by phase delivers risk reduction that is visible at each step and stays explainable. Three priorities in this order make it workable.

Privileged accounts first. Domain administrators, cloud administrators, accounts with access to the identity provider itself, accounts that can create or reset other accounts. This is where phishing-resistance belongs, not because every employee will have it tomorrow too, but because the loss of one of these accounts immediately undermines the entire model. Anyone who leaves SMS or a simple push in place here hands an attacker, after one successful phishing attempt, a lever over the rest of the environment.

External access second. Every route by which someone from outside comes in: VPN, remote desktop, remote management for suppliers, federated access for external parties, management of public applications. This is the edge attackers try first, because they can see the outside of your network. This calls for at least a phishing-resistant or comparably strong level, and here too the arrangements with third parties should be explicitly recorded: which factor, on which domain, with which exceptions, and what happens when the other party lets that exception lapse.

Internal critical applications third. The core financial system, the customer database, the source code environment, production control in an industrial setting. Here the rollout can be phased, because the attack route is longer and the intermediate controls count. But the phasing must end, and that end should be recorded before the next priority begins, otherwise the rollout stays stuck at eighty percent, as regularly happens in practice.

What stands out about this sequence is what is missing from it. Not the ordinary employee mailbox first, not the general desktop login. These are not unimportant, but they are not the place where one leaked account topples the entire model. The sequence is built on impact radius: where would an attacker gain the most scale after one successful step. That is a different criterion than "where is the largest number of accounts", and it is precisely the criterion that shifts the discussion from "MFA as a feature" to "MFA as an architecture measure".

What this means for execution

The practical consequences for Operations teams are sober. For each priority, it should be recorded in advance what the strongest achievable level is in your environment, which exceptions you accept and with what expiry date, and who owns the phase-out of the exceptions. Without an owner, every exception becomes permanent. For service accounts, the first step is an inventory, not a second factor: which accounts exist, who uses them, what is their actual function, and which of them can be replaced by identity-bound machine credentials with a short lifespan. Only after that comes the question of whether a second factor is still needed, and in what form.

For the user experience, something similar applies to what is already visible in other security programmes: the stronger the factor, the lower the friction in the daily routine, provided it is rolled out well. A hardware-bound key that sits plugged in at the workplace asks less of the user than the sum of password, SMS, push notification and periodic password change that often still exist side by side today. The gain is not only in security, but also in clearing away a layer of controls that have historically been stacked on top of each other without anyone ever critically revisiting them.

The logical next step

MFA is not everywhere because the toggle was never the problem. The problem is the sequence, the exceptions no one closes, and the assumption that a checkbox at the identity provider means the same as protection at the edge where it counts. Anyone who takes the sequence into their own hands, privileged accounts first on phishing-resistance, external access second, internal critical applications third, and service accounts under a regime of their own, gets a rollout that is traceable and stays standing. Anyone who waits until an audit prescribes the sequence gets a plan that is correct on paper and stays stuck where the architecture makes it difficult.

A good next step is to make that sequence concrete alongside someone who can weigh both the architecture and the execution, without having to sell a product. Then the choice stays yours, and it stays explainable to whoever has to approve it.