Conferences News

- Previous Post >>

Life After MFA: Still Essential, But Not Enough

NOTE: In this series of posts, we revisit recent presentations delivered at MU.SCL and provide additional context around the slide decks shared here.
While a written post cannot fully reproduce the depth, examples and discussion of a live session, it should help you better understand the topic, the key messages, and the practical points behind the slides.


Earlier this month, at our latest Mauritius Cyber Security Club event, MU.SCL S03E06 "Catch Me If You Can", the first (and only) talk of the evening, "Life After MFA", was built around a question that sounds almost contradictory:
If Multi-Factor Authentication is one of the most effective security controls available, why does a growing share of account takeovers happen on accounts that already have it?

The answer is not that MFA has failed, and the wrong conclusion to draw from the headlines would be to treat it as obsolete.
The more useful answer is that MFA protects one moment, the login, and attackers have become very good at working with the moments around it.

MFA still works, which is precisely the point

Microsoft Research found in 2023 that MFA reduced the risk of account compromise by 99.22%, and by 98.56% even where credentials had already leaked, while the Microsoft Digital Defense Report 2025 states that more than 97% of identity attacks are password attacks, exactly the attacks MFA is built to stop.

And yet, in Proofpoint's analysis of more than 50 million cloud accounts between November 2024 and November 2025, 67% of organisations suffered at least one successful account takeover, and 59% had MFA enabled on the compromised accounts.

Both sets of figures come from each vendor's own telemetry, and they are not contradictory: MFA removed the cheapest attack, so attackers moved to the ones it was never designed to stop.

The presentation opened with a good illustration of this, Uber in September 2022: the contractor's password had already been stolen by malware, the attacker sent repeated push requests which, in Uber's own words, "initially blocked access. Eventually, however, the contractor accepted one".
MFA was the last control left standing, and it relied on a person saying no every single time.

What MFA actually proves

MFA is evaluated at a single point in time: the login.
Before it, there is enrolment and recovery: who can register a factor, and who can reset it?
After it, there is a session cookie or a set of tokens, and every subsequent request simply presents that token without any further MFA.
Whoever holds the session is the user, until it expires or is revoked.

From there, the presentation organised the attacks into four routes past MFA, each closed by a different set of controls:
  • AROUND: use an account, application or protocol where MFA is not enforced.
  • THROUGH: get the real user to complete MFA for the attacker's session.
  • AFTER: steal the session cookie or token a legitimate login produced.
  • RESET: change the factors or the recovery process so that the attacker becomes the account owner.

Around: the MFA that was never there

Many "MFA bypass" headlines are in fact coverage gaps: at Change Healthcare in 2024, the CEO testified that the Citrix portal used with stolen credentials "did not have multi-factor authentication"; in the Snowflake customer campaign, Mandiant found that the impacted accounts did not have MFA enabled, with at least 79.7% of them having credentials previously exposed through infostealers; and at Microsoft, Midnight Blizzard started with a password spray against a legacy, non-production test tenant account.

None of those required anything clever against MFA, only something outside the policy: legacy protocols that cannot prompt for MFA, VPN or Citrix portals not behind the identity provider, service, test and break-glass accounts excluded and then forgotten, Conditional Access exceptions that quietly became permanent, or passwords sitting in infostealer logs.
Measure MFA coverage per sign-in path, not per user.

Through: the prompt is real, the request is not

This route covers five different mechanics with the same outcome:
  • Push fatigue, as with Uber: just a password and persistence. Number matching stops blind approvals, but not a caller who reads the number to the victim.
  • Code relay: at Retool in 2023, an SMS lure, a fake portal and a call using, according to Retool, a deepfaked employee voice obtained MFA codes; the attacker then enrolled their own device in the employee's Okta account and, because Google Authenticator was syncing codes to the cloud, "control of the Okta account led to control of the Google account, which led to control of all OTPs".
  • Adversary-in-the-Middle (AiTM): a proxy relays the whole login, the MFA step becomes just another relayed page, and the session cookie reaches the proxy first. When the Tycoon 2FA kit was disrupted in March 2026, Proofpoint cited Microsoft's findings that it had been used to access almost 100,000 organisations, and CrowdStrike observed it recovering within the same day.
  • Device-code phishing, documented by Microsoft with Storm-2372 and EvilTokens, and consent abuse such as ConsentFix: in both cases the victim signs in on a genuine Microsoft page, and the attacker receives the tokens or the authorisation code. ConsentFix works even with a passkey, because the user really did authenticate to Microsoft.
That leads to probably the most important point for practitioners: phishing-resistant MFA stops push fatigue, code relay and AiTM, but not device-code phishing or consent abuse, which have to be closed by blocking the flow and controlling consent.

After: steal the session, skip the login

If the login produces a token that works without further MFA, stealing the token is often easier than attacking the login.
The SpyCloud 2026 Identity Exposure Report counts 13.2 million malware infections in 2025, exposing 8.6 billion cookies, and notes that 40% of those infections occurred on endpoints protected by EDR or antivirus tools.
The Okta support breach of 2023 showed the same problem from another angle: HAR files uploaded by customers for troubleshooting contained session tokens, and the live administrator sessions of five customers were hijacked without any MFA challenge.
A session token is a password that has already passed MFA.

Reset: become the account owner

Why defeat MFA when you can ask somebody to change it for you?
The M&S chairman told the UK Parliament's Business and Trade Sub-Committee in July 2025 that the attack was a "sophisticated impersonation attack" involving a third party, with the reported route being a password reset obtained by impersonating an employee, and the joint Scattered Spider advisory describes the same playbook: getting the help desk to reset passwords and move MFA to an attacker device, then registering their own MFA tokens.

That last point applies to every route: once inside, attackers add their own way back, whether a new MFA method, a rogue device registered in the tenant, an OAuth consent grant or mailbox rules.
None of those is removed by a password reset, and phishing-resistant MFA does not help either, because they produce a perfectly valid sign-in for the attacker.

Not all MFA is equal, and Mauritius

NIST SP 800-63B-4 defines phishing-resistant authentication as output bound to the site's name or to the session, so an impostor cannot reuse it: passkeys, FIDO2 keys, Windows Hello for Business and certificates qualify, while codes and push approvals do not. A code works wherever it is typed; with a passkey, the browser, not the user, tells the authenticator which site is asking.
The direction the industry is going is clear: NIST requires AAL3 to be phishing-resistant, CISA, the FBI and NCSC-UK recommend it for all services where possible, and Microsoft is retiring Microsoft-provided SMS and voice authentication in Entra ID from 1 February 2027 for most users.

In Mauritius, the Bank of Mauritius Guideline on Cyber and Technology Risk Management already requires MFA for administrator accounts on critical systems, internet access to customer data and all remote access, but it defines MFA as two or more factors without specifying phishing resistance.
An SMS code therefore meets the definition: compliant is not the same as phishing-resistant, and for many local organisations on Microsoft 365, the Entra retirement dates may force that conversation before any regulation does.

Getting out: one set of controls per route

The second half of the presentation mapped controls back to each route:
  • AROUND, make coverage provable: block legacy authentication, put remote access behind the identity provider, retire test tenants and dormant accounts, and give every policy exclusion an owner and an expiry date.
  • THROUGH, phishing-resistant and enforced: start with administrators and break-glass accounts, then high-risk roles, then everyone; remove the weaker fallbacks; block the device-code flow in Conditional Access (Conditions > Authentication flows), in report-only mode first; and restrict user consent.
  • AFTER, make stolen sessions worthless: bind tokens to the device where supported (Entra Token Protection, Chrome Device Bound Session Credentials), use Continuous Access Evaluation, and require compliant devices for sensitive applications.
  • RESET, recovery as strong as the login: verify callers through an independent channel, never reset MFA on the caller's word alone, apply the same rules to outsourced help desks, and alert on every new MFA method and device registration.
And assume one gets through: when it happens, eviction is not a password reset but a sequence, Contain, Invalidate, Remove, Repair, Verify, in which the methods, devices, grants and rules the attacker added are explicitly removed.

Protect the moments around it

Five things to remember from the talk:
  • MFA still works: keep it everywhere.
  • Prove the coverage: many "bypasses" are accounts, applications or protocols outside the policy.
  • Make it phishing-resistant, starting with administrators.
  • Protect what MFA doesn't: sessions, recovery, device-code and consent flows need their own controls.
  • Plan the eviction: a password reset leaves the attacker's way back in place.
MFA protects one moment. Protect the moments around it too.

- Previous Post >>