Setting up MFA and why it matters

Multi-factor authentication, usually called MFA, requires more than one type of evidence before a user can sign in. It matters because passwords are often guessed, reused, phished or stolen from other services, and a second factor limits the damage when that happens.

What MFA adds

A password is something the user knows. MFA adds another factor, such as something the user has or something the user is.

Common factors include authenticator apps, security keys, platform passkeys, smart cards and biometrics. Some systems also use SMS, email codes or phone calls, but these are weaker than phishing resistant methods.

MFA does not make accounts impossible to compromise. It raises the cost for attackers and reduces the damage from stolen passwords.

Prefer phishing resistant MFA

Phishing resistant MFA is designed so a fake site cannot capture a reusable code and replay it to the real site.

Passkeys, FIDO2 security keys and other WebAuthn based authenticators are strong choices because authentication is bound to the legitimate origin. The credential is scoped to the relying party derived from the web origin, so the authenticator will not complete the same sign in for a lookalike phishing site.

Where phishing resistant MFA is available, use it for administrators, developers, finance users and anyone with access to sensitive data.

Use authenticator apps when stronger options are not available

Time based one time password apps are usually better than relying on a password alone. They work offline and avoid some weaknesses of SMS.

They are still phishable because a user can type a current code into a fake login page. They also need careful recovery planning because losing the device can lock out the account.

Use them when passkeys or security keys are not available, but do not treat them as the strongest option.

Treat SMS and email codes as fallback methods

SMS and email codes are common because they are easy to deploy, but they have weaknesses. Phones can be lost, numbers can be transferred through SIM swaps or porting, messages can be intercepted, and email accounts are often already the recovery path for many services.

Use SMS or email codes only when better factors are unavailable or as a carefully controlled recovery option.

For high risk accounts, avoid letting a weaker fallback bypass a stronger primary factor.

Set MFA up safely

Start with the most important accounts: email, password manager, source control, cloud provider, domain registrar, payment systems, identity provider and production administration.

Register at least two strong authenticators where the service allows it. For example, use a platform passkey plus a hardware security key, or two hardware security keys stored separately.

Save recovery codes in a password manager or another protected location. Do not store them in the same inbox or device that they are meant to recover.

Remove old devices and factors when they are replaced. Review MFA methods after role changes, device loss or suspected compromise.

Protect account recovery

MFA is only as strong as the recovery process. If support can disable MFA after weak checks, attackers will target recovery instead of the login screen.

Use recovery methods that match the risk of the account. Administrative accounts need stronger recovery than low risk consumer accounts.

Log and alert on MFA resets, new factor enrolment, recovery code use and factor removal.

Make MFA usable

Security controls fail when users cannot use them reliably. Choose methods that fit the users, devices and environment.

Support backup factors. Provide clear enrolment steps. Test recovery before an incident. Avoid excessive prompts that train users to approve without thinking.

For workforce systems, combine MFA with single sign-on and device management where appropriate. That reduces repeated prompts while keeping access controlled.

Conclusion

MFA reduces the risk from stolen passwords, but method choice matters. Prefer phishing resistant passkeys or security keys, use authenticator apps when stronger options are unavailable, keep weak fallbacks under control, and protect recovery with the same care as sign in.