Multi-factor authentication

Knowledge: a password, a PIN, an answer to a question. Weak on its own because it can be guessed, reused, or disclosed.

Possession: a phone receiving a code, an authenticator application generating one, a hardware security key.

Inherence: a fingerprint or a face. On a phone this normally unlocks a key held on the device rather than being transmitted, which is a meaningful difference.

Two factors from the same category are not multi-factor. A password and a security question are both knowledge.

Codes sent by SMS are vulnerable to interception and to number porting, and are the weakest widely deployed second factor. They remain far better than no second factor at all.

Time-based codes from an authenticator application avoid the telephone network but are still phishable: an attacker relaying a login in real time simply asks for the code and uses it immediately.

Push approvals are phishable in the same way, and additionally vulnerable to fatigue — a user approving a repeated prompt to make it stop.

Hardware security keys using the WebAuthn standard are resistant, because the key signs a challenge bound to the origin and will not respond to a different one. A relayed login fails at the protocol level.

Passkeys apply the same mechanism with the key stored in a device or password manager, which is what makes phishing resistance available without distributing hardware.

The registrar account controlling the domain. Losing it means losing the domain, the site and the mail, and no server configuration mitigates it.

DNS and hosting control panels, for the same reason.

Email accounts, because email is the reset channel for everything else.

Administrative access to the site itself, and any account with the ability to change what visitors receive.

Recovery paths need the same attention: an account with strong MFA and a weak recovery question is protected by the weaker of the two.

A login page may advertise support — a second step, a security key option, a passkey prompt — which indicates availability rather than enforcement.

Whether it is required, and for whom, is not visible externally. An option nobody enables protects nobody.

Documentation and account settings are where the answer actually is, and reviewing them is an internal exercise.

For an organisation, enforcement policy matters more than availability: the administrator accounts that most need it are the ones most likely to have opted out.