Why MFA Alone Will Not Save You

Opening Claim

Microsoft’s Digital Defense Report 2023 documented session tokens — issued following successful MFA completions — being presented from IP addresses, devices, and network contexts bearing no relation to the contexts of the originating authentications. The authentication logs recorded valid MFA completions. The session tokens were structurally valid. Access was granted. The system behaved correctly under its own validation model in every instance.

The Original Assumption

The trust model underlying MFA treated the authentication event as atomic and complete. A satisfied second-factor challenge produced a session grant scoped to the authentication event — not to the context in which that event occurred. The model assumed session context and authentication context would remain consistent. This assumption was not encoded as a constraint. It was not evaluated.

The problem MFA was designed to solve was specific: credential stuffing, where a stolen password alone was sufficient to authenticate. Adding a second factor closed that attack surface. The trust model was not extended to represent the gap between the moment authentication completed and the moment the resulting session artifact was used.

What Changed

Session tokens are portable objects. A token issued to a browser at one IP address, on one device, in one network location can be presented from any other browser, device, or location without modification. This was always true.

What changed was which part of the authentication lifecycle became the primary point of exploitation. The authentication event itself remained difficult to compromise directly. The session artifact it produced did not carry the same resistance. The Adversary-in-the-Middle (AiTM) attack class operationalizes this property. Proxy frameworks — Evilginx2, Muraena, Modlishka — implement it by positioning a transparent reverse proxy between the user and the legitimate authentication endpoint. The user completes the full authentication ceremony, including the second factor, against the real identity provider. The proxy captures the session cookie from the completed exchange. The trust model was not revised to represent this as a gap. The system continued to evaluate sessions by the rules it had always used.

Mechanism of Failure

The system validated the second factor at authentication time and issued a session token. On all subsequent requests, it validated the token: valid signature, not expired, correct claims. No check ran against the originating IP, device fingerprint, or network context. When a token was presented from a context that did not match its origin, the system found a valid token and returned authorized access. This is the expected behavior for a valid token. Nothing in the system’s trust model required a different response.

TOTP codes, SMS codes, and push-based OOB challenges share a structural property: they are time-bounded secrets that, once relayed in transit, produce session tokens. The AiTM proxy — as documented in Microsoft’s September 2022 incident reporting on the DEV-1101 campaign — captures the completed session cookie rather than the credentials or the second factor in isolation. The result is a valid credential that the issuing system cannot distinguish from one produced by the device and user that originally authenticated. The session token carries no record of the relay. The system evaluating it has no mechanism to ask. Authentication logs show a successful MFA challenge. Session logs show normal access. From inside the system’s observational model, nothing occurred that required a response.

Pattern

Systems validate at creation and inherit that trust forward.

The artifact produced by a successful validation carries the trust established at issuance. Subsequent evaluations check validity — not the conditions under which the artifact was created, and not the conditions under which it is currently being used. The gap between creation context and use context is not evaluated because the trust model does not represent it.

This operates identically in certificate infrastructure. A certificate authority issues a certificate binding an identity to a public key. Systems receiving connections authenticated by that certificate validate it against the issuing authority. They do not re-evaluate whether the entity presenting the certificate controls the private key under conditions equivalent to issuance. If the private key was exported after issuance, the certificate continues to validate. The binding between the certificate and its original context is a historical record the system treats as permanent. Whether the current bearer is the original holder is not in the validation model.

In both cases: trust was established once, encoded in an artifact, and inherited on every subsequent use without re-evaluation of context.

Implication

FIDO2/WebAuthn eliminates the portability gap by encoding origin binding into the credential itself. The authenticator produces an assertion containing a clientDataJSON structure with rpId and origin fields verified against the registered binding — the proxy cannot forge or relay these fields, because the authenticator will not produce a valid assertion for an origin it does not recognize. Presenting that credential from a proxied or mismatched origin fails at the protocol layer. The AiTM proxy cannot relay a credential it cannot produce. The gap between authentication context and session use context does not exist to be exploited because the credential is not separable from its origin context.

TOTP, SMS, and push-based OOB MFA do not carry origin binding. They produce time-limited secrets that generate session tokens indistinguishable from tokens produced by fully legitimate authentications.

PCI-DSS 4.0 Requirement 8.4, NIST SP 800-63B AAL2, and ISO 27001 Annex A.9.4 all measure the presence of a second authentication factor. That measurement does not overlap with the question of whether the session trust model accounts for the distance between authentication event and session use. An environment can satisfy every relevant requirement — MFA required, MFA enforced, MFA logged — and remain fully exposed to AiTM-based token relay, because the controls were designed against the credential stuffing model and were not revised when the dominant attack surface shifted to session portability. What the controls measure and what the threat now requires are different questions.