2.3 Multi-factor authentication (MFA)

Strengthening identity without adding fragility

Multi-factor authentication (MFA) adds a second check on top of your password. Knowing a password is only one way to prove you are you; a second factor asks for something else, usually a code from your phone or an approval in an app.

Done well, MFA blocks the most common account takeovers without making everyday log-ins painful or brittle.

MFA is not one thing. There are several methods, each with different strengths, costs and failure modes. Picking one is less about ideology and more about how you actually live:

• do you travel?
• is your phone signal reliable?
• can you keep a spare device?
• how much friction can you put up with?

What MFA actually stops

MFA is strongest against password theft and reuse. Normally, someone with your password from a breached website can log in anywhere you reused it. MFA breaks that chain: they still need the second factor. A stolen password alone is no longer enough.

It also helps against low-effort phishing. A fake log-in page might grab your password, but if the service then asks for a second factor, the attacker has to act quickly and in real time. That limits opportunistic abuse.

It does not stop targeted, live phishing where the attacker relays your code immediately. Newer methods such as security keys resist this far better, but even app-based codes raise the bar for most attackers.

What MFA also does not do is fix weak account recovery. If an attacker can reset your password through a compromised email inbox or a lax help desk, the second factor is irrelevant.

MFA is a layer, not a foundation. It works best with a strong, unique password and a well-protected recovery route.

SMS codes and SIM‑swap risk

SMS-based MFA texts you a code. It is everywhere because it works on almost any phone and needs no extra app. For many people it is the first step beyond password-only log-ins, and that alone is valuable.

The main weakness: your phone number can be taken over. In a SIM swap, a criminal gets your mobile provider to move your number to a new SIM card, by:

• social engineering;
• using leaked personal data to pass security checks;
• bribing staff.

Once your number moves, your SMS codes arrive on the attacker's phone. UK mobile operators have improved their procedures, but the risk still exists, especially for accounts tied to your name and number in public records.

This is not a reason to panic or turn MFA off. It is a reason to choose a stronger factor where you can. If SMS is your only option, reduce the exposure:

• set a network-level PIN with your provider;
• avoid publishing your mobile number unnecessarily;
• protect your main email account with a stronger method;
• got two numbers? Use a secondary one for low-risk accounts and a better-protected one for critical ones.

App‑based authenticators

Authenticator apps generate time-based codes on your device. They work offline and do not rely on the mobile network, so SIM-swap attacks no longer help an attacker and you can log in without signal.

Google Authenticator, Microsoft Authenticator, Aegis and 1Password can all do this. The routine is the same in each: open the app, read the six-digit code, type it in.

Two common misunderstandings:

• "The app must connect to the account each time." It does not. The code is generated locally from a secret set up once during enrolment.
• "The codes can only live on the phone." Many apps let you back up or sync your tokens, which helps if you lose the device. But that backup is a new point of risk: if you enable cloud sync, protect that account with strong MFA of its own.

For most people, app-based codes are the sweet spot: stronger than SMS, less fragile than a separate hardware key, and reasonably easy to use.

The weakness is device loss. Lose, break or wipe your phone and you may be locked out unless you kept recovery codes or added a second authenticator device. Practical fixes:

• add a second device you already own, such as a tablet kept at home;
• store recovery codes somewhere secure you can reach when travelling.

Push notification fatigue

Some services use push-based MFA: a log-in attempt sends a notification to your phone and you tap "Approve" or "Deny". Convenient, since there is no code to type, and it can be safer than SMS if it relies on app-level cryptography rather than your phone number.

The risk is behavioural, not technical: people approve prompts they did not start.

Push fatigue sets in when prompts keep coming, from a misconfigured app or an attacker who has your password and is spamming the second factor. In a busy moment you tap approve just to make it go away, especially if the app shows no details.

This has caused real breaches: staff bombarded with prompts late at night, finally approving one out of frustration.

The fix is part design, part habit. Good systems make you match a number, or show context such as location and device type. On your side:

• treat an unexpected prompt as a warning, not a nuisance;
• if you get one, change your password and check recent sign-ins, rather than just denying and moving on.

Not about fear; just avoiding a common, predictable failure.

Phishing-resistant MFA: keys and passkeys

All the methods above share one weakness, now the defining problem of MFA: they can be phished in real time.

Type a six-digit code into a convincing fake login page and whoever runs that page can relay it to the real service within seconds. The second factor gives no protection at all.

This is no longer rare or sophisticated. Ready-made phishing kits automate exactly this relay and are widely available. So app codes and SMS, while far better than nothing, no longer stop a determined attacker who has you on a fake page.

What does solve it is phishing-resistant MFA, built on the same standard as the passkeys in 2.2. Two practical forms:

• a physical security key, covered in detail in 2.4;
• a passkey stored on your device or in your password manager.

Why they work: authentication is cryptographically bound to the genuine website's address. On a look-alike domain the key simply refuses to respond, because it is not the site it registered with.

There is no code to read out, so nothing for an attacker to capture and relay. It swaps the human judgement phishing exploits ("does this page look right?") for a check the machine gets right every time.

Aim for phishing-resistant MFA on the accounts that matter most: your primary email, your password manager, your main financial and government logins. The order of preference:

• security key or passkey, where offered;
• app-based codes otherwise, since they still defeat the most common attacks;
• SMS only when nothing else is available.

And as with every method here, pair it with a well-protected recovery route. The strongest front door does not help if the back door is ajar, which is exactly what the next section covers.

Recovery codes as a weak point

Most services give you recovery codes when you enable MFA: single-use codes that bypass the second factor if you lose your device. They are necessary, but careless storage undoes the protection.

• A printed sheet taped to a monitor is easy to photograph.
• A file called "codes.txt" on a shared laptop is easy to copy.

In effect, recovery codes are a second password.

Store them like any other high-value secret: in a password manager, or printed and kept somewhere safe at home. Carrying them while travelling? Keep them apart from your phone and your main wallet, so a single loss does not hand over everything.

If you change a password after a suspected breach, regenerate your recovery codes too, because the old ones may already be compromised.

Many services also offer backup routes such as a backup phone number, an email link or security questions. These are often weaker than the main MFA and can be exploited, especially if the backup email is poorly protected.

Where you can, choose recovery methods you control tightly, and avoid security questions based on personal information. In the UK a surprising amount of personal data is available through public records or social media, so those questions are less secure than they look.

None of these trade-offs removes the value of MFA; they just define its limits. The aim is to add friction to the attacks that really happen, without making access so fragile you lock yourself out at the first mishap.