MFA (Multi-Factor Authentication)

How MFA works

The first factor goes first, usually a password. Only once that clears does the system ask for a second: a one-time code, a push notification to an enrolled phone, a tap on a FIDO2 key, or a fingerprint. Authentication only finishes once both come back clean. The security gain here is multiplicative, not additive: an attacker now needs two unrelated things, usually on two separate devices, inside one short login window. That is a much harder bar to clear than guessing a password.

Types of MFA

Not every second factor deserves the same trust. SMS codes sit at the bottom, interceptable and flagged by NIST for years now. Authenticator-app TOTP codes are the common middle ground. Push notifications with number matching close most of the gap plain push approval left wide open. FIDO2 and passkeys sit at the top, built specifically to resist phishing rather than just add friction. Adaptive MFA skips the theater when risk is low: a known device on a known network can pass quietly, while a login from a new country or an impossible-travel pattern triggers a harder check. Passwordless MFA goes further still and drops the password altogether, pairing a possessed device with a biometric.

MFA fatigue attacks and number matching

MFA fatigue, also called push bombing, is what happens when an attacker who already has a valid password just keeps firing push approvals until someone taps "yes" out of habit or exhaustion. Several high-profile 2022 breaches came down to exactly that. Number matching shuts the door: the user has to type a code shown on the login screen, so blind approval is no longer possible. Cap how many pushes can fire in a row, and move privileged accounts to phishing-resistant factors entirely, and the rest of the gap closes too.

MFA for remote desktop access

This is where MFA does its most important work. RDP endpoints sit under constant, automated password attacks, and without MFA a single leaked or guessed credential is all it takes. A deployment only counts if MFA runs before the session starts, not after the Windows desktop has already loaded, and it needs to cover every way in: direct RDP, RD Gateway, RD Web. Native RDP was never built with MFA, so it gets added at the broker, the gateway, or the identity layer instead. For the full walkthrough, RD Gateway and on-premises scenarios included, see MFA for RDP and Remote Desktop Services →

MFA for on-premises Windows and Active Directory

Cloud apps get MFA for free from whatever identity provider sits in front of them. On-premises AD logons, RDS farms, and older servers do not. Someone has to bring MFA to them, through a broker, a gateway integration, or an agent, and that exact gap (cloud locked down tight, the RDS farm wide open behind it) shows up in ransomware post-mortems more than almost anything else.