Multi-factor authentication, or MFA, requires at least two independent factors: something a person knows, possesses or is. A password and a PIN are still only knowledge factors. A password plus a hardware security key combines two categories and therefore provides genuine MFA.
Two-factor authentication is the common case with exactly two factors. MFA is the broader term. It sharply reduces attacks based on stolen passwords, but implementation and factor choice still matter.
Which authentication factors exist?
| Factor | Examples | Typical risk |
|---|---|---|
| Knowledge | Password, PIN | Phishing, reuse and guessing |
| Possession | Hardware key, smartphone, smartcard | Loss, theft or poorly protected replacement |
| Biometric | Fingerprint, facial recognition | False matches and compromise of traits that cannot be changed |
Two proofs from the same category do not constitute genuine MFA. A password and a security question, for example, are both knowledge factors. On modern devices, biometric traits often unlock a cryptographic key stored locally; the service does not necessarily receive the fingerprint itself.
How does MFA prevent attacks?
In credential stuffing or after a password leak, an attacker only has part of the required evidence. This substantially reduces the success of automated login attempts. MFA does not, however, protect every action after authentication. Malware on an authenticated device, stolen session cookies or a manipulated recovery process can circumvent the second factor. MFA is therefore one defensive layer, not a substitute for secure applications.
Which MFA methods are suitable?
- Passkeys and FIDO2 keys:
They cryptographically bind authentication to the genuine service and resist ordinary phishing. - Authenticator app:
Time-based codes are widely supported but can be relayed through a real-time phishing site. - Push approval:
It should include number matching, contextual information and protection against repeated prompts. - SMS code:
It is better than a password alone, but remains exposed to SIM swapping and mobile-network risks.
The appropriate method depends on risk. Phishing-resistant methods are preferable for administrative accounts, source code, cloud consoles and particularly sensitive data. An authenticator app may be a practical intermediate step for less critical access. A weaker method should not remain available as an unnoticed alternative login.
How can MFA be bypassed?
Attackers may overwhelm users with push requests, intercept codes in real time or steal existing sessions. Implementation flaws add further paths: a login flow without MFA, an insufficiently protected API endpoint or a way to skip the second step. A penetration test should therefore examine recovery, factor changes, alternative protocols and session management in addition to the visible default login.
What matters during rollout and recovery?
- Protect privileged and particularly exposed accounts first.
- Register more than one factor without creating a permanently weak fallback.
- Log and notify users about new factors, resets and unusual sign-ins.
- Strictly limit, monitor and regularly test emergency accounts.
- Monitor acceptance and failure rates so users do not resort to insecure workarounds.
Account recovery must be at least as strong as the normal login. Backup codes, support processes and factor replacement are common bypass paths and need logging, verification and notification. Otherwise, a strong hardware key only protects the account until the first call to an unprepared support desk.
Thank you for your feedback! We will review it and optimize this content.