Why MFA at login does not protect anything after login
An employee authenticates at nine in the morning with a hardware key. By eleven, a session cookie lifted from their browser is being replayed from another continent, and no authentication event occurs because none is required.
Does MFA protect anything after login?
No. MFA is an event at the session boundary; everything consequential happens inside the session, authorised by a token. Infostealers lift that token from the browser, so the attacker never authenticates and no authentication event ever fires.
- MFA is an event at the session boundary. Actions taken during the session inherit its authority without re-establishing it.
- Infostealer malware targets session material directly, which sidesteps authentication entirely rather than defeating it.
- Binding a fresh assertion to the specific action makes a stolen session insufficient for the operations that matter.
Part of Privileged identity and account recovery
The architectural gap
Authentication answers a question once, at the start. A session token then represents that answer for hours.
Everything of consequence — the payment release, the permission change, the data export — happens somewhere inside that window, authorised by the token rather than by the human. The strength of the original authentication does not reach that far.
| Time | Event | What authorises it |
|---|---|---|
| 09:00 | Login with hardware key | The human, with user verification |
| 09:00 | Session token issued | The successful authentication |
| 11:47 | Payment of 84,000 released | The token |
| 11:52 | Beneficiary bank details changed | The token |
How the token leaves the machine
Infostealer families are commodity malware with a narrow, well-optimised job: collect credentials and session material from a host and exfiltrate it. Browser cookie stores, token caches and credential managers are the primary targets.
The economics are why this matters. Stolen sessions are traded in bulk at low prices, which means a token is worth stealing even when the account is unremarkable. Volume compensates for value.
Note what is not happening: the attacker never authenticates. There is no failed login, no MFA prompt, no anomalous authentication event. The security control was never engaged.
Why the usual mitigations fall short
| Mitigation | Effect | Limit |
|---|---|---|
| Shorter session lifetimes | Narrows the window | Tokens are used within minutes of theft; also degrades usability sharply |
| Device binding / token binding | Real improvement | Binds to the device — and the malware is on the device |
| IP and geolocation checks | Catches lazy operators | Defeated by proxying through the victim's network or a residential relay |
| Behavioural anomaly detection | Catches some cases | Probabilistic; the attacker is using a real session doing plausible things |
| Continuous access evaluation | Useful | Revokes on signal; the signal usually arrives after the action |
Each of these is worth doing. None changes the underlying fact that the token, by design, carries authority the human is not present to exercise.
Re-establishing presence at the action
The fix is not a stronger session. It is refusing to let the session alone authorise the operations that matter.
def release_payment(request, payment):
# The session identifies the caller. It does not authorise this.
stmt = canonical({
"action": "payment.release",
"beneficiary": payment.beneficiary_name,
"account": mask(payment.account), # last four only
"amount": payment.amount,
"currency": payment.currency,
})
digest = sha256(stmt)
assertion = request.assertion
verify(assertion.signature, credential_for(request.user))
require(assertion.challenge == digest) # bound to THIS payment
require(assertion.user_verified) # biometric or PIN, now
require(now() - assertion.issued < 120) # fresh
execute(payment)An attacker holding the session can reach this endpoint. They cannot produce the assertion, because it requires the authenticator and a user-verification gesture on the real employee's device.
Choosing where to apply it
Not everywhere. Prompting on every request would be unusable and would train people to approve reflexively, which destroys the control's value.
- Money movement and changes to where money goes
- Permission and role changes, particularly self-elevation
- Bulk data export
- Credential enrolment and recovery
- Destructive operations on production systems
In most enterprise applications that is a list of ten to thirty endpoints. It is findable in a day by grepping for the operations that write irreversibly.
The endpoint-hygiene objection
Someone will point out that if the machine is compromised, the attacker could wait and hijack the assertion at the moment the user approves something.
That is true and it is a much harder attack: it requires presence on the device at the right moment, and it yields exactly one action rather than a session's worth. More importantly, the assertion is bound to a specific rendered effect, so the attacker gets the action the user meant to take, not one of their own choosing — unless they can also control what was displayed, which is a deeper compromise than cookie theft.
Raising the cost from "buy a stolen cookie for a few dollars" to "maintain interactive presence on a specific endpoint and defeat the rendering path" is a real change in the threat model, not a rhetorical one.
Why the usual mitigations fall short
| Mitigation | Limit |
|---|---|
| Shorter sessions | Stolen tokens are used within minutes; aggressive timeouts push users to workarounds |
| Device binding | Binds to the device — and the malware is on the device |
| Geolocation checks | Defeated by proxying through the victim's network |
| Behavioural detection | Probabilistic; the attacker is doing plausible things in a real session |
| Continuous access evaluation | Revokes on signal, and the signal usually arrives after the action |
Objections and honest limits
“If the endpoint is compromised, nothing helps.” The attacker must then be present at the moment of approval and gets one action, bound to what the user was shown. That is a far higher bar than replaying a purchased cookie.
“How many endpoints need this?” Ten to thirty in a typical enterprise application — money movement, permission changes, bulk export, credential enrolment, destructive operations. Findable in a day by grepping for irreversible writes.
Finding your step-up set
- Grep for irreversible writes. Money, permissions, bulk export, credential changes, destructive operations.
- Bind the assertion to the action. The challenge is a digest of the rendered effect.
- Require freshness and user verification. Under two minutes, biometric or PIN.
- Leave everything else alone. Prompting on every request trains reflexive approval.
Terms used here
- Infostealer
- Commodity malware harvesting credentials and session material, traded in bulk at low prices.
- Session token
- A bearer credential representing an earlier authentication, valid for hours.
- Step-up
- A fresh assertion required at a specific action rather than relying on the session.
Frequently asked questions
Is MFA still worth deploying? Yes. It closes credential stuffing and password phishing, which remain high-volume. It simply does not address theft of the session that MFA produced.
Won't shorter sessions fix this? Marginally. Stolen tokens are typically used within minutes, and aggressive timeouts push users toward workarounds that are worse.
How many endpoints need step-up? Usually ten to thirty in an enterprise application — money movement, permission changes, bulk export, credential enrolment, destructive operations.
What if the endpoint is fully compromised? The attacker must be present at the moment of approval and gets one action, bound to what the user was shown. That is a far higher bar than replaying a purchased cookie.
Where this fits in Manav
Manav requires a fresh assertion bound to the specific action, from a credential under the person's sole control. A stolen session reaches the endpoint and cannot produce it.