Passing the Login Test Does Not Mean You Let In the Right Person

Multi-factor authentication is a genuine security win, but organisations that mistake 'logged in successfully' for 'identity confirmed' are handing attackers a very comfortable seat at the table.

ThreatVectr Newsdesk· 3 min read
Extreme close-up of a glowing laptop keyboard in a dark room, with faint green and amber light reflecting off the keys, shallow depth of field on the enter key,
Share

Key points

  • Multi-factor authentication, the system that asks for a second proof of identity beyond a password, does not by itself confirm who a person actually is.
  • Security teams that conflate three separate jobs, verifying identity, checking login credentials, and spotting suspicious behaviour, risk waving attackers straight through.
  • Stolen session tokens and SIM-swapping attacks (where a criminal tricks a phone carrier into moving your number to their device) can defeat MFA entirely without touching a password.
  • Organisations need continuous behaviour monitoring alongside login checks, not instead of them.

There is a comfortable lie that circulates in boardrooms after a company rolls out multi-factor authentication, often shortened to MFA. The lie goes: we have MFA, so we are safe from account takeovers. SecurityWeek flagged this gap recently, and it is worth unpacking for anyone who has ever been told MFA is the answer.

MFA is genuinely useful. Asking a user to confirm a login with a second step, a code from an app, a text message, a hardware key, makes life much harder for criminals who only stole a password. That is real protection.

But "harder" is not "impossible."

So what does MFA actually miss?

MFA checks that someone controls a device or a phone number. It does not check that the person holding that device is who they claim to be.

Criminals have found several ways around this. Session hijacking is one: after a legitimate user logs in, their browser receives a small digital file called a session token that proves they are authenticated. Steal that token, through a phishing page or malicious browser extension, and an attacker can walk into the account without ever entering a password or MFA code. The system sees a valid token and waves them through.

SIM-swapping is another route. A criminal calls a phone carrier, pretends to be the account holder, and convinces a customer-service agent to transfer the victim's phone number to a criminal-controlled SIM card. Any MFA text message now goes to the attacker.

Neither of these attacks "breaks" MFA in a technical sense. Both of them render it irrelevant.

What should organisations actually do?

Three things need to happen, and they are not the same thing: confirming who someone is before they get an account, checking their credentials when they log in, and watching what they do once they are inside.

Most companies invest heavily in the middle step and neglect the other two.

Identity verification, the upfront check that a new user is genuinely who they say they are, often amounts to little more than a working email address. And behaviour monitoring, flagging that a user who normally logs in from Manchester is suddenly downloading financial records from a Bulgarian IP address at 3 a.m., is expensive to build and easy to defer.

The result: a company can successfully authenticate an attacker and have every log file show a clean, legitimate login.

What should ordinary users watch for?

If you receive an MFA code you did not request, treat it as an emergency. Someone has your password and is trying to use it right now. Change the password immediately and alert whoever manages your account.

For anything financial or medical, check whether the service offers app-based authenticator codes rather than SMS text messages. App-based codes cannot be intercepted by SIM-swapping.

MFA is a lock worth having. Just remember that a determined burglar studies the door, not only the lock.

© 2026 Threat Vectr