Summary
Multi-Factor Authentication (MFA) requires a user to present more than one independent proof of identity. The common combination is "something you know" (password) plus "something you have" (hardware key, authenticator app) or "something you are" (biometric).
What is MFA?
In a password-only login, a stolen password is enough to take over an account. MFA breaks that by demanding a second, independent factor at the moment of authentication. Common second factors are TOTP codes from an authenticator app, push notifications, FIDO2/WebAuthn hardware keys, SMS codes (now widely deprecated due to SIM-swap attacks), and biometric checks built into the device.
MFA is typically enforced at the identity provider so that every application protected by SSO inherits the same MFA policy. Modern setups push toward phishing-resistant factors — primarily FIDO2/passkeys — because TOTP and SMS factors can still be replayed by adversary-in-the-middle phishing kits. Risk-based MFA prompts only when the IdP detects an unusual location, device, or behaviour, which keeps the daily user experience smooth.
For infrastructure access, MFA at the IdP layer protects mesh VPN logins, Kubernetes dashboards, cloud consoles, and any application bound to SSO. Regulatory frameworks like NIS2 and DORA increasingly treat MFA on privileged access as a baseline requirement.
Why is MFA relevant?
- Phishing resistance: Stops password-only credential theft from becoming account takeover
- Compliance baseline: Required or expected by NIS2, DORA, ISO 27001, and most cyber-insurance policies
- Centralised control: Enforced at the IdP for every SSO-protected application
- Zero Trust building block: Strong identity proof is a prerequisite for per-request policy checks
Related Terms
- Single Sign-On: SSO is the layer at which MFA is typically enforced
- Identity Provider: Service responsible for executing MFA flows
- Zero Trust: Model that depends on strong, MFA-backed identities
- Keycloak: Open-source IdP that supports a wide range of MFA factors