For the last decade, the advice has been consistent and correct: turn on multi-factor authentication. A stolen password should not be enough on its own. Someone should also need a code, an approval or a trusted device.
That advice is still right. If you have not enabled MFA, it remains one of the most valuable security improvements you can make. The government's Cyber Security Breaches Survey 2025/2026 found that only 47% of UK businesses had any two-factor authentication requirement for their networks or applications, up from 40% the previous year.
But MFA is not the finish line. Some sign-in methods can be phished, active sessions can be stolen, and weak recovery routes can undo a strong login. Businesses that enabled MFA and stopped thinking about identity still have work to do.
Think of the session as a hotel key
At a hotel desk you prove who you are once, then receive a key. From that point the key opens the room; you do not show your identity documents every time.
Online services work in a similar way. After you enter a password and complete MFA, the service gives the browser or application a session credential. It is presented on later requests, which is why you are not asked to sign in whenever you open a message or document.
That session credential is the room key. If an attacker steals a valid one, the service may treat the attacker as a user who has already completed authentication.
How adversary-in-the-middle phishing works
One technique is called adversary-in-the-middle, or AiTM, phishing.
You follow a link to a convincing sign-in page controlled by an attacker. The attacker's server proxies the authentication traffic to the real service in real time. You enter your password and approve the genuine MFA challenge presented through that flow. The attacker captures the resulting session cookie or token and replays it in another browser.
Microsoft has documented AiTM campaigns in which stolen session cookies were used to access mailboxes and attempt payment fraud even though MFA was enabled.
Nothing in that sequence means MFA was pointless. The attacker had to build a live phishing flow and persuade a person to use it. But a code or approval prompt that can be relayed is not phishing-resistant.
Detection helps, but it is not prevention
Token theft is not necessarily invisible. Identity and security products can flag unusual locations, devices, browsers, token behaviour and known AiTM infrastructure. Microsoft Defender XDR and Entra ID Protection, for example, publish detections for suspicious cookie use and attacker-in-the-middle activity.
Those detections still need the right licence and configuration, and somebody must review and respond to the alert. Attackers may also use residential proxies or familiar infrastructure to make activity look less unusual.
Monitoring is valuable, but it is stronger when combined with a sign-in method that does not hand a phishable secret to the site in the first place.
What MFA still stops
MFA is not obsolete. It sharply reduces the value of a stolen password and blocks a very large amount of automated account abuse.
Microsoft's Digital Defense Report 2025 says 97% of the identity attacks in its telemetry were password-spray attacks. A password-only account is exposed to that routine, high-volume guessing and credential reuse.
AiTM is one of the more targeted techniques that remains after ordinary password attacks are made harder. It is a reason to improve MFA, not a reason to turn it off.
Why passkeys are stronger against phishing
A passkey uses public-key cryptography. The service holds a public key, while the corresponding private-key material is protected by your device, security key or credential manager. Signing in normally requires you to unlock that authenticator with a PIN, fingerprint, face check or another local method.
The important property is that the credential is bound to the genuine website or application. A phishing proxy on another domain cannot ask your authenticator to sign in to the real service. There is no password or one-time code for the person to type into the fake site.
That makes passkeys resistant to credential phishing and the AiTM flow described above. It does not make every authenticated session impossible to steal. Malware on an unlocked device, a compromised browser, malicious account recovery or flaws elsewhere in the service can still create risk. Some passkeys also synchronise securely through a credential manager, so recovery and protection of that manager matter.
The NCSC recommends passkeys where available
The NCSC now recommends passkeys wherever a service supports them and two-step verification where it does not, a change announced at CYBERUK 2026.
The NCSC's technical assessment found passkeys at least as secure as, and generally more secure than, pairing the strongest password with two-step verification. Its practical passkey guidance also stresses recovery, device access and the need to use trustworthy credential managers.
The recommendation is not “remove MFA”. A passkey used with local user verification can itself combine possession of the authenticator with a PIN or biometric check. Where passkeys are unavailable, the strongest practical MFA a service offers remains the right next step.
What to do now
If you do not have MFA, start there. Protect business email and your central identity account first, followed by password managers, administrator accounts, banking, payroll, cloud storage, customer systems and public-facing accounts.
Use passkeys or FIDO2 security keys where they are supported. Prioritise accounts that can move money, reset other accounts or administer important systems.
Do not wait for a perfect method. If passkeys or FIDO2 are unavailable, enable another MFA method rather than leaving the account password-only. Approval prompts, app-generated codes, SMS and email codes can all be phished, so treat them as fallbacks and use the strongest practical option the service supports.
Plan recovery before enforcement. Record who owns each critical account, add an appropriate separately held credential where the service permits it, store backup codes securely and test the official recovery route. Do not keep the only recovery copy on the same device as the primary credential.
Review active sessions after suspected compromise. Changing a password may not revoke every existing session. Use the provider's official controls to sign out sessions, remove unfamiliar authentication methods and check forwarding, recovery and application-consent settings.
If you suspect an account is already compromised, follow the first-hour cyber attack checklist while you revoke sessions and record what happened.
Ask what session protection actually covers. Device-bound sessions can reduce the value of a stolen token, but support differs by platform and application. Microsoft's current Token Protection documentation, for example, shows generally available native-application support on Windows, iOS/iPadOS and macOS, with browser support limited to selected Azure Resource Manager web apps in preview. Check the live documentation for the way your team actually works.
Turn on useful sign-in alerts. New devices, unfamiliar locations, impossible travel and risky sign-ins can be valuable signals. Define who receives the alert and what they should do next.
The honest summary
MFA still blocks many attempts to turn guessed, reused or leaked passwords into account access. Keep it enabled and finish rolling it out.
What changed is the attacker. Once a password alone stopped being enough, criminals increasingly looked at phishable MFA flows, recovery routes and the sessions issued after a successful login.
The practical progression is simple: password-only accounts first move to MFA; important accounts then move to phishing-resistant passkeys or FIDO2 where possible; recovery, session controls and monitoring are reviewed alongside them.
MFA is the start of stronger identity security. It is no longer the point where the work ends.