Multi-factor authentication (MFA)

Two-factor authentication (2FA) requires two different forms of identification to be presented before entering a system, instead of depending on the password by itself. It is the most common case of multi-factor authentication (MFA), which is the same mechanism when two or more factors are required.

The premise is that an attacker is unlikely to obtain evidence of two different kinds at once. Stealing a password is easy and stealing a password plus physical possession of a registered device is much harder, so requiring both raises the cost of account takeover far more than any password policy does.

The categories are what make it work. Something you know: a password, a PIN, a recovery code. Something you have: a hardware security key, a phone holding a device-bound private key, a smartcard. Something you are: a fingerprint or a face, which in practice unlocks a key on the device rather than travelling anywhere. Two items from the same category do not multiply the difficulty, which is why a password and a security question is single-factor authentication with extra steps.

The mechanisms differ enormously in what they resist, and this is where most of the confusion sits. An SMS code, an emailed code and a time-based code from an authenticator are all shared secrets in transit: the user reads them and types them somewhere, so anything that can persuade the user to type them somewhere else gets them. A push approval is a decision the user makes with no context beyond “approve or deny”. A WebAuthn credential is different in kind: the browser signs a challenge with a private key that never leaves the device, and it includes the origin of the site asking. A replica site cannot obtain a valid signature, because the signature is bound to the real origin. That single property is what makes it resistant rather than merely inconvenient.

The attack that decides most engagements is adversary in the middle. We stand a reverse proxy in front of the real login page. The victim reaches our page, sees the genuine site because we are relaying it, enters their password, and completes whatever second factor they use, on the real site, successfully. Then the real site issues a session, and we keep it. Nothing was cracked, nothing was bypassed in the cryptographic sense, and the second factor worked exactly as designed. We simply took what it produced. Codes and push approvals both fall to this without modification, and so does any factor that is not tied to the origin.

The second is fatigue. Where push approval is enabled, an attacker who already has the password sends requests until the user approves one, at night, to make it stop. Number matching helps and does not solve it, because a user who is being prompted repeatedly will eventually read the number and type it.

The third is the exception, and it is the one we find most often. A tenant enforces MFA and carries a list of accounts excluded for a reason that made sense once: a service account, a break-glass administrator, a conference room device, a supplier. Those exclusions are where we authenticate. Alongside them, legacy authentication protocols that predate modern policy accept a password and nothing else, and a single enabled legacy endpoint makes tenant-wide enforcement decorative.

The fourth is registration and recovery. If a user can enrol a new factor with only their password, an attacker with the password enrols their own. If a helpdesk can reset a factor after verifying details that appear on a public profile, the strongest factor in the estate is a phone call. On social engineering engagements the helpdesk path succeeds more consistently than the technical one.

The question is never “do we have MFA”. It is “which of these attacks does the factor we deployed actually stop”.

The row that matters is the phishing proxy column, because that is the attack in current use against organisations with MFA already deployed. Everything above the certificate row shares one property: a value or a decision the user hands over, which means it can be handed to the wrong site. Everything below is bound to the origin by the protocol, so a replica gets nothing usable.

Treating all MFA as equivalent in a policy document. “MFA required” without naming the acceptable factors permits the weakest one on the list.

Leaving legacy authentication enabled. One protocol that cannot carry a second factor makes the policy advisory. Disable it centrally and audit the exceptions monthly.

Excluding service accounts and forgetting them. They are accounts, they usually have more rights than people, and they are exactly what we look for.

Allowing self-service enrolment with only a password. Registration must be at least as strong as the thing being registered, otherwise the password is still the only real control.

Assuming MFA protects the session. It protects the moment of login. A stolen session token carries no factor with it, which is why session hijacking after a successful login is unaffected by any of this.

Move administrators and anyone with access to money or data to origin-bound factors first. Full estate migration takes time; the accounts that would end the engagement can move this quarter.

Close the alternatives. Disable legacy authentication, enumerate every exclusion with an owner and an expiry date, and treat break-glass accounts as a designed control with hardware factors and monitoring rather than as a gap. Use conditional access policies so that device state and location are part of the decision, and so that stepping up to a stronger factor is required for sensitive operations rather than only at sign-in.

Fix registration and recovery with the same seriousness as the primary factor. Enrolment from a trusted device or an in-person check, helpdesk verification that cannot be satisfied with public information, and an alert to the user whenever a factor is added.

For detection, the signals are specific and usually available: successful authentication from an address that is a known hosting provider, an impossible sequence of locations, multiple denied push prompts followed by an approval, and a new factor registered shortly after a password reset. That last pattern is the clearest single indicator of account takeover in most identity logs.

In a phishing or identity engagement we report per path rather than per tenant: which accounts, which factor, which protocol, and what we obtained. Where we relayed a login through a proxy we say so plainly, because the client needs to understand that their factor performed correctly and was still insufficient, which is a different conversation from a misconfiguration.

The evidence is the session we obtained and what we reached with it, along with the timestamps so the client can find the corresponding entries in their own logs. We do not record credentials or codes in the report body.

Severity is decided by what the account reached and by whether the same path works for a privileged account. Relaying an ordinary user’s session is a serious finding; the same technique working against a directory administrator is the report’s headline.

This is exactly what an exercise that ends at the session rather than at the click measures: not whether people click, which everyone knows they do, but what the attacker keeps afterwards.

Is SMS-based MFA still worth having? It is much better than a password alone and it is the weakest option available. If it is what you can deploy today, deploy it, and plan the move to origin-bound factors for privileged accounts rather than treating the tick as the end of the work.

Can MFA be bypassed? The word bypassed is misleading. A phishing proxy does not defeat the factor, it relays the session the factor produced. Codes, push approvals and one-time links are all vulnerable to this. WebAuthn credentials are not, because the signature is bound to the real site’s origin.

What is a passkey? A passkey is a WebAuthn credential, usually stored on a phone or in a platform keychain and unlocked with a biometric or PIN. It is origin-bound like a hardware key, and it removes the password entirely rather than adding a step to it.

Do we still need strong passwords with MFA? Yes, until the password is removed altogether. The password remains a full factor, it is what a credential stuffing attack tests, and in most estates there is at least one path where it is still accepted on its own.