Knowledge factors (passwords, PINs, security questions) are the weakest link and must never be the only defence; possession factors (hardware tokens, authenticator apps, smart cards) and inherence factors (biometrics) raise the bar meaningfully.
What is multi-factor authentication
Multi-factor authentication (MFA) is a security control that requires users to present two or more independent verification factors before access is granted. Factors fall into several categories: something you know (password, PIN), something you have (hardware token, smartphone, smart card), something you are (fingerprint, facial recognition) and, in advanced deployments, contextual signals (location, managed device, session risk). The logic is straightforward: even if an attacker steals a password through phishing, a public breach or compromised credentials, the missing second factor blocks access. MFA is not a silver bullet, but it remains the cost-to-impact control with the best track record against identity-based attacks.
Why it matters
Passwords alone do not protect anything that matters. They are reused across services, exposed in large-scale breaches, guessed through predictable patterns and harvested by keyloggers or fake login pages. Industry reports (the Verizon DBIR, ENISA Threat Landscape, CISA advisories) agree on one point: the misuse of valid credentials is today the most common initial access vector in enterprise incidents, ahead even of exploiting technical vulnerabilities. MFA changes the equation by adding a factor the attacker typically does not have: a physical device, a hardware token, a biometric. Analyses published by major identity providers consistently put the reduction in account-compromise risk close to 99% when MFA is correctly enforced. The nuance matters: SMS-based MFA is exposed to SIM swap and SS7 interception; TOTP apps are considerably better; hardware tokens based on the FIDO2/WebAuthn standards resist even real-time phishing because they cryptographically validate the target domain. Incident casework repeatedly shows the same pattern: organisations without MFA suffer widespread compromise after a single password leaks, while organisations with well-deployed MFA detect and stop the same attack before it creates business impact. The difference rarely comes down to budget — it is the decision to enforce MFA on every account and to choose phishing-resistant factors for privileged access.
Key points
The choice of factor caps the protection level: SMS is the weakest (interceptable, exposed to SIM swap), TOTP apps are a reasonable baseline for most use cases, and FIDO2/WebAuthn hardware tokens resist proxy-assisted phishing because they cryptographically validate the domain.
Push-based MFA introduces its own risk: MFA fatigue, where an attacker triggers repeated prompts until a user approves one by mistake. Usual mitigations include number matching, per-minute rate limits, lockouts after N rejections, and combining MFA with Zero Trust conditional access.
Effective deployment requires universal coverage (not only administrators), integration with conditional access (location, session risk, device health) and a clear recovery plan: backup codes, documented reset procedures and auditable change logs to prevent help-desk abuse via social engineering.
User experience is part of the design, not a cosmetic detail: if MFA frustrates teams, people look for workarounds (shared tokens, service accounts without MFA, permanent exceptions). A phased rollout, short training and role-appropriate factors are critical for sustainable adoption.
MFA stopping a credential-stuffing attack
An attacker obtains a list of tens of thousands of username/password pairs from an old breach on an unrelated platform and automates login attempts against the corporate portal of a financial services firm, counting on employees reusing passwords. Within hours, several dozen credentials are accepted as valid by the corporate directory: if that were the only control, the attacker would already be inside, pivoting laterally towards email, source code repositories and financial systems.
The organisation, however, enforces MFA for every external login. Every correct password is followed by a second-factor challenge bound to the employee's device. The attacker owns none of those devices, and every session is aborted. The unusual volume of attempts triggers SOC alerts; analysts block the offending IP range, trigger hardening for the affected accounts, rotate passwords and open a formal incident response case. A post-incident investigation reconstructs the timeline, confirms that no effective access occurred and documents the incident for compliance and cyber-insurance purposes. Without MFA, the same attack would have become a major breach. With MFA enforced and well-tuned, it stays a managed event.
Common mistakes
- Relying solely on SMS-based MFA. It is exposed to SIM swap, fraudulent number porting and, on legacy mobile networks, SS7 interception. For privileged access and business-critical systems, require TOTP apps or FIDO2 hardware tokens.
- Granting MFA exceptions to sensitive roles for the sake of convenience. Domain admins, finance leads and DevOps engineers with production access are precisely the preferred targets; no permanent exception should survive a risk review.
- Neglecting the recovery plan. If an employee loses the phone, the token or changes device without backup codes, the help desk will end up bypassing the control under pressure. A documented procedure, out-of-band verification and full traceability are essential so that the reset process does not itself become an attack vector.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
Is MFA effective against sophisticated phishing?
It depends on the factor. Real-time phishing proxies can forward TOTP codes or push approvals to the legitimate server and capture the resulting session token, which makes SMS, TOTP and basic push all vulnerable. Hardware tokens based on FIDO2/WebAuthn do resist these attacks because they cryptographically bind the credential to the real service domain and refuse to sign authentications against look-alike sites. For critical roles, the practical recommendation is FIDO2, combined with targeted awareness training on how these attacks look and conditional access policies that block anomalous origins.
How do we deploy MFA without breaking productivity?
Phased rollout and careful factor selection. Phase 1: remote access (VPN, virtual desktops) and privileged accounts, where the benefit is highest and the user count is manageable. Phase 2: critical SaaS applications and corporate email. Phase 3: extend to the rest of the workforce with authenticator apps or hardware keys. Combining MFA with conditional access reduces friction: managed devices and trusted networks can skip the daily challenge while new or anomalous logins always require it. Short training, clear documentation and a prepared help desk make the difference between smooth adoption and lasting internal resistance.
What is the strongest type of MFA?
A practical ranking from strongest to weakest: 1) FIDO2/WebAuthn hardware keys with user verification, phishing-resistant by design; 2) TOTP apps on a managed device, robust against most mass attacks; 3) push-based MFA with number matching, acceptable when combined with rate limits and fatigue detection; 4) SMS, only as a last resort and never for privileged access. For organisations with regulatory requirements (NIS2, DORA, PCI DSS) the recommended baseline is FIDO2 for critical roles and TOTP or hardened push for the rest.
What happens if an employee loses their second factor?
That is why a recovery plan is part of the design, not a reaction. When MFA is enrolled, each user generates single-use backup codes stored in the corporate password manager or a physically secured location. If the token or phone is lost, the user spends one code to authenticate and regenerates the set. When no codes are available, the reset is executed by IT after out-of-band verification (video call with ID document or manager confirmation), never through simple email verification. Reset attempts are audited and reviewed: help-desk impersonation is a classic vector, and a weak reset procedure nullifies the entire MFA investment.