The MFA you deployed is not the MFA you think you deployed

You rolled out multi-factor authentication. Push notifications, company-wide, enforced by policy. The compliance dashboard turned green and the control got marked effective. It was, by any reasonable measure, a good quarter.

Then somebody rang the help desk, said they'd lost their phone, answered a question about their start date and another about their manager's name, and had their factors reset inside four minutes. They signed in. They were not the employee.

Nothing failed. Every control worked exactly as configured. The attacker simply used the door that was cheapest, which is the only thing attackers have ever reliably done.

Your authentication strength is your weakest enrolled path

Here is the uncomfortable arithmetic. An attacker does not have to beat your strongest factor. They have to beat your weakest accepted one. So your real authentication posture is not what the policy says — it is the minimum over every path that results in a session:

• the primary factor you deployed and talk about
• every fallback factor still enrolled on the account
• the self-service recovery flow
• the help-desk reset procedure
• whatever the VIP exception process turned into

Most organisations measure the first one. The attacker measures the fifth.

If SMS is still enrolled as a backup, you deployed SMS. The push notification is decoration on top of a factor a competent attacker can intercept or social-engineer around.

What the techniques actually do to each combination

Run the common account-takeover techniques — credential stuffing, real-time phishing proxy, SIM swap, push fatigue, token theft, help-desk impersonation, consent phishing — against typical configurations, and the picture is less flattering than the dashboard:

Two things stand out. The jump from password-and-SMS to a number challenge is enormous — bigger than most roadmap items anyone is arguing about. And the step after it, to genuinely phishing-resistant authentication, mostly removes the category rather than reducing it, because a credential that cannot be replayed against a proxy is not a credential an intermediary can steal.

But all four rows assume the enrolled set is clean. Leave SMS enrolled as fallback on the passwordless row and it does not score five. It scores close to fifty-seven, because that is the door that is open.

Push fatigue is a design flaw, not a user failure

Plain push approval asks a tired person, at an arbitrary moment, to distinguish a login they initiated from one they did not, with no information beyond "approve?". Send that prompt forty times at eleven at night and somebody taps yes — not because they are careless, but because the control was designed in a way that makes the wrong answer easier than the right one.

Number matching fixes this almost entirely, and the reason is worth stating precisely: it changes the interaction from recognition to transcription. You cannot transcribe a number you cannot see. The attacker's screen has the number; the victim's phone does not. The whole technique collapses — not because users got more careful, but because the design stopped requiring them to be.

That is the general lesson. Controls that depend on people being alert at the worst moment are not controls. Controls that make the attack structurally impossible are.

The recovery lane is the real policy

If there is one thing worth taking from this: write down your recovery flow, then read it as though you were the attacker.

What does the help desk ask? Start date, manager's name, the last four of a payroll number? All of that is on LinkedIn, in a breach dump, or available by ringing a colleague and being friendly. If the reset procedure is weaker than the login procedure — and it usually is, because it was designed for a locked-out employee on a Monday morning, not an adversary — then the reset procedure is your authentication policy. Everything in front of it is presentation.

The fix is rarely more factors. It is usually: make recovery as strong as login. A second human approver. Verification against something an attacker cannot read. Re-enrolment that requires physical possession of something. Less convenient, and exactly as inconvenient as signing in, which is the point.

Model it before you ship it

Every one of these decisions is cheap while it is still a choice and expensive once it is a rollout. Re-enrolling thirty thousand people onto a different factor because the first combination had a hole in it is a programme, with a budget and a steering committee. Choosing the right combination in the first place is an afternoon.

That is the entire argument for simulating it. Drag the factors you are actually considering into the sign-in lane and the recovery lane — including the fallbacks you were planning to leave enrolled "just during migration", which is how they become permanent. Run the techniques. Look at what still gets in, and at which single change moves the number most.

It is the same principle we apply to provisioning: find the risk at the moment when changing your mind costs nothing. For authentication, that moment is before the rollout email goes out, not after the first incident review.