Multi-Factor Authentication (MFA): What You Need to Know

Multi-Factor Authentication (MFA) requires two or more verification factors before granting access, instead of relying on a password alone. The factors fall into three categories:

Something you know: password, PIN, or security question — the easiest factor to compromise via phishing or social engineering.
Something you have: a smartphone, hardware token, or access card — can’t be stolen remotely the way a password can.
Something you are: biometrics — fingerprint, facial recognition, retina scan, voice. Unique per person, hard to forge.

Combining factors means a stolen password alone doesn’t get an attacker in.

In this post: Why it matters · What MFA doesn’t stop anymore · Not all second factors resist the same attacks · Number matching: the practical fix if passkeys aren’t there yet · When would you actually use this? · Best practices · References · Related reading

Why it matters

Neutralizes stolen credentials: even a successful phishing attack only gets an attacker the password — they still need the second factor.
Required by name in several regulations: HIPAA mandates it for healthcare data access, PCI-DSS requires it for payment processors, GDPR encourages it for personal data with real fines for non-compliance.
Necessary for remote/cloud access: once employees connect from arbitrary networks and devices, location and device trust stop being reliable signals on their own.

What MFA doesn’t stop anymore

Worth being honest about, since “we have MFA” gets treated as a solved problem more often than it should. Two attack patterns specifically target MFA itself, not the password behind it:

MFA fatigue / push bombing: an attacker with a stolen password floods the victim with push approval requests until one gets approved out of frustration or habit — no technical bypass, just exploiting the prompt itself. This is what enabled real breaches at Uber and Cisco.
Adversary-in-the-middle (AiTM) phishing: a proxy phishing kit sits between the victim and the real login page, relaying the legitimate MFA challenge through in real time and capturing the resulting session token once the user completes it. The user never notices anything’s wrong — they logged into what looked like the real thing and MFA succeeded normally. This category has grown sharply enough that several commercial phishing kits now build it in by default.

Neither of these defeats “have a second factor” as a concept — they defeat push-notification and one-time-code MFA specifically, by attacking the human approval step or the session token instead of the credential. Phishing-resistant MFA — FIDO2 security keys, Windows Hello, or passkeys built on the WebAuthn standard — closes both gaps, because the authentication is cryptographically bound to the actual domain being logged into. A proxy site can relay a push notification; it can’t fake the cryptographic handshake a hardware key performs against the real site’s certificate. If your MFA rollout is still push-notification-only, that’s the realistic next step, not a “nice to have.”

Not all second factors resist the same attacks

Worth laying out plainly, since “MFA” gets treated as one uniform thing when the specific method matters a lot against the attack patterns above:

SMS / voice call codes: vulnerable to SIM-swapping (already flagged below) and to AiTM relay — the code itself is just a shared secret typed into whatever page is presenting the prompt, real or fake.
Push notifications: resistant to SIM-swapping, but this is the exact factor MFA fatigue/push-bombing targets, and a proxy phishing kit can relay a legitimate push challenge in real time just as easily as a code.
TOTP authenticator apps (time-based one-time codes): not tied to a phone number, so SIM-swapping doesn’t touch it — but still just a code a relay attack can capture and replay within its short validity window.
FIDO2 security keys, passkeys, Windows Hello (phishing-resistant / WebAuthn-based): the only category actually immune to AiTM relay, because the cryptographic challenge-response is bound to the real site’s domain during the handshake itself — a proxy sitting in front of a fake login page can’t complete that handshake on the real site’s behalf, no matter how convincing the fake page looks to the user.

The practical read: SMS is the weakest option across the board, push and TOTP are meaningfully better than nothing but still beatable by a sufficiently real-time attack, and phishing-resistant methods are the only tier where “MFA” actually closes the AiTM gap described above rather than just raising the attacker’s effort.

Even a successful phishing attack only gets an attacker the password — they still need the second factor.

Number matching: the practical fix if passkeys aren’t there yet

Worth knowing this exists as the realistic middle step for an organization not ready for a full phishing-resistant rollout: Microsoft enforced number matching in Microsoft Authenticator push notifications by default starting in 2023 — instead of a single “Approve” tap, the user has to read a number shown on the sign-in screen and type the matching number into the app. This directly targets the push-bombing pattern described above, since blindly tapping “Approve” repeatedly no longer completes a sign-in; the user has to actually look at and transcribe a number they’d have no way to know unless they were the one initiating the real login. CISA’s own guidance recommends number matching specifically as the fallback for organizations that can’t move to phishing-resistant MFA immediately — worth confirming it’s actually turned on, since it doesn’t fully close the AiTM relay gap covered above (a real-time proxy can still relay the number itself) but it does eliminate blind-approval push bombing specifically.

When would you actually use this?

You’re securing customer-facing logins (online banking, healthcare portals) where fraud liability actually falls on you if credentials get reused from a breach elsewhere.
You’re rolling out remote access and can’t rely on “they’re on the corporate network” as a trust signal anymore.
An auditor is asking specifically whether MFA is enforced for a regulated data category — HIPAA/PCI-DSS/GDPR all name it directly, so “we have strong passwords” won’t satisfy the finding.
You’re on Microsoft 365/Entra ID specifically and need the actual implementation steps — see Multi-Factor Authentication (MFA) Options for Microsoft for the PowerShell and licensing side of this.

Best practices

Start with privileged accounts — admins and anyone with access to critical systems, before a full rollout.
Use adaptive authentication where possible — only prompt for the extra factor in risky scenarios (unknown location/device), not every single login.
Avoid SMS as the only second factor — it’s vulnerable to SIM swapping. TOTP apps or biometrics are stronger.
Review policies periodically, not just at initial rollout — session timeouts and re-authentication requirements should get revisited as threats evolve.

References

Multi-Factor Authentication (MFA) Options for Microsoft — the Microsoft-specific implementation details for the concept covered here.
Utilizing Identity Secure Score in M365 Admin Center — MFA coverage is one of the biggest levers on this score.

Hope that clears things up. Feel free to drop a comment if you need more detail.