Identity & Access · Chapter 15 of 16
MFA architecture, and how it actually gets bypassed
Which factor where, when to ask again, and the attack that makes most multi-factor deployments worth less than their owners think.
The passwordless chapter covers what the modern factors are. This one is the engineering — which factor for which population, when to challenge again, and the specific way well-intentioned deployments fail.
The three factors, and why the classification is less useful than it looks
Something you know (a password), have (a phone, a key), or are (a fingerprint). Every course teaches this and it is nearly useless for design, because it groups an SMS code with a hardware key — both ‘have’ — when they differ by more than an SMS code differs from a password.
The attack that defines modern MFA design
Adversary-in-the-middle, and why “we have MFA” is not an answer
The user clicks a link and lands on a site that proxies the real one in real time. It shows them the genuine login page, because it is fetching it.
They type their password. The proxy forwards it. The real site asks for a code. The proxy shows them that prompt too. They type the code. The proxy forwards it and receives back a valid session cookie.
The attacker now has the session, not the credential — which means resetting the password does not evict them, and the login looks entirely legitimate in your logs because it was.
Every factor in the top three rows above falls to this, including the authenticator app people install specifically to be safe. The only structural defence is a credential that refuses to work on the wrong domain.
Which is why the practical answer to ‘how do we stop phishing’ is not training. It is origin-bound credentials, and it is the one control in this whole book that removes a threat category rather than reducing it.
And the corollary people miss: because the prize is the session, session lifetime is an authentication control. A stolen cookie valid for thirty days is thirty days of access; one that must be re-proved against device state in an hour is not. Token lifetime and re-authentication policy belong in the MFA design, not in a separate ticket.
Where MFA goes, and where it does not
Prompting for everything is a design failure, not diligence. Users route around friction — that is not a character flaw, it is the predictable outcome, and the route around is usually worse than the thing you were preventing.
| Population / action | What to require | Why |
|---|---|---|
| Ordinary staff, ordinary access | Phishing-resistant factor at sign-in, then a long session | One strong authentication beats five weak interruptions |
| Administrators, always | Hardware-backed, no fallback | The account that can grant access must not be recoverable by helpdesk |
| Anything irreversible | Step-up at the action, not at login | Payment, key export, permission grant, production delete |
| A new or unmanaged device | Step-up, plus device registration | This is the signal that most reliably indicates an intruder |
| Machine-to-machine | Not MFA at all — workload identity | See machine identity. A service account with a TOTP secret in a config file is a password with extra steps. |
Step-up authentication is the piece most deployments lack. The idea is simple: authenticate the session lightly, and re-authenticate the action. The user signs in once in the morning; the moment they try to change payment details, they prove themselves again. It concentrates friction on the handful of actions that justify it, and it is what makes a long session safe rather than reckless.
Adaptive or risk-based authentication takes the same idea and drives it from signals — an unfamiliar device, an impossible journey between locations, an unusual hour, a service the user has never touched. Worth having, and worth being honest about: it is a detection system, so it has false positives, and every false positive is a person locked out of their job. Tune it against a real population before you enforce it, and decide in advance who can unblock someone at 6am.
The parts everyone forgets
- Recovery is your real security level. If a hardware key can be bypassed by a phone call to a helpdesk, your authentication strength is the helpdesk script. Attackers know this and target it directly — several of the most damaging recent intrusions were social engineering of support staff, not defeats of a factor. Design recovery with the same seriousness as enrolment, or better.
- Enrolment is the other hole. If a new factor can be registered with only the existing weak one, you have not upgraded anything — an attacker who phishes the code enrols their own key and becomes legitimate.
- Legacy protocols bypass all of it. An old mail or directory protocol that cannot present a second factor is an open door beside a locked one. Blocking legacy authentication is usually a bigger single improvement than the MFA rollout itself, and it is the step that gets deferred because it breaks something.
- Break-glass accounts need a written home. Excluded from conditional policy by necessity, credential split and held physically, alerting on every single use. Every organisation has them; the mature ones know how many.
- Count coverage honestly. ‘95% of users have MFA’ is the wrong metric. The right questions: which 5%, are any of them administrators, and how many sign-ins in the last month completed without a phishing-resistant factor?
The rollout order that actually reduces risk fastest, which is not the order most programmes use.
1. Block legacy authentication. Free, and it closes the bypass that makes everything else decorative.
2. Hardware-backed factors for administrators. A small population, the largest single risk reduction available.
3. Number matching on push, everywhere it exists. Usually one setting.
4. Passkeys for the general population, then retire the weaker factors — and note that leaving SMS enabled as a fallback preserves the attack you were removing.
5. Step-up on irreversible actions.
Most programmes run 4 first because it is the visible one, leave 1 for later because it breaks an old integration, and are surprised when the incident arrives through the door they left open.
Check yourself