MFA Multi-Factor Authentication.

What counts as a factor, and why it matters

Multi-factor authentication asks for two or more proofs of identity drawn from different categories, so that compromising one does not hand an attacker the account. The three classic categories are knowledge (something you know, such as a password or PIN), possession (something you have, such as a phone, a security key or a smart card) and inherence (something you are, such as a fingerprint or face). The word that does the work here is different. Two passwords are not multi-factor, because they sit in the same category and fall to the same attacks. A password plus a code from a separate device is, because an attacker now needs to defeat two unrelated controls at once.

This is also where MFA and identity management meet. MFA strengthens only the authentication step, the moment a user proves who they are. It says nothing about what that user is then allowed to do, which is authorisation, nor about provisioning, deprovisioning or access reviews. Treat MFA as one hardened layer inside a broader IAM programme, not as a substitute for least privilege or for cleaning up orphaned accounts.

Not all MFA is equal

The single most important practitioner insight is that MFA exists on a spectrum of strength, and the difference is not cosmetic. SMS and email one-time codes are better than a password alone, but they are phishable: a convincing fake login page simply asks the victim to type the code, and a real-time attacker relays it. SIM swapping makes SMS worse still. Push-notification approvals add a tap, but they invite MFA fatigue, where an attacker who already has the password spams approval prompts until a tired user accepts one.

The strong forms are possession factors bound to the legitimate site: hardware security keys and passkeys built on FIDO2 and WebAuthn. Because the credential is cryptographically tied to the real domain, it does not release anything to a lookalike page. That property is what people mean by phishing-resistant MFA.

Regulatory and standards context

MFA has moved from a recommendation to an expectation across European cyber regulation. NIS 2 requires essential and important entities to adopt cyber-hygiene and access-control measures, with multi-factor or continuous authentication called out for the security of access. DORA imposes comparable expectations on the financial sector, where strong authentication protects critical functions and remote access. Both frameworks lean towards the strong end of the spectrum rather than treating any MFA as sufficient. The same direction of travel appears in NIST guidance, which favours phishing-resistant authenticators for high-value access, and in baseline frameworks such as ISO/IEC 27001 and the CIS Controls, which treat MFA as a core access-control safeguard.

What practitioners actually do is sequence the rollout by risk. They protect privileged and administrative accounts first, then remote and internet-facing access, then the general user population, and they pick phishing-resistant methods wherever the impact of compromise is high. They plan recovery and enrolment carefully, since lost factors are a real operational cost, and they monitor for fatigue and bypass patterns. Done well, MFA quietly removes the value of a stolen password. Done as a checkbox, it gives a false sense of safety while the phishable channel stays open.