Multi-Factor Authentication and Passkeys: A DEWA89 Guide

What Counts as a Second Factor

Multi-factor authentication means proving identity with more than one kind of evidence, so that a stolen password is not enough on its own. Authentication evidence falls into three categories:

• Something you know - a password, a PIN, the answer to a security question.
• Something you have - a phone running an authenticator app, a USB security key, a SIM that receives text messages.
• Something you are - a fingerprint, a face, another biometric.

Real MFA combines categories. A password plus a code from your phone is two factors: an attacker needs both your knowledge and your device. A password plus a security question is not, because both are things you know, and both can be extracted in a single convincing phone call. An account whose only extra step is a security answer should be treated as password-only, whatever the vendor's marketing says.

Biometrics sit in an odd position. When you unlock a passkey with your face or fingerprint, the biometric never travels to the website. It unlocks key material inside the device's secure hardware, so a breach at the site cannot leak your fingerprint. What the site receives is a signature made by your device. The strength of that arrangement then depends on the fallback: if the phone drops to a four-digit passcode after a few failed scans, then a shoulder-surfed passcode plus a stolen phone defeats it. Use six digits or more, and shorten the auto-lock timeout.

The Common Second Factors, Ranked Honestly

Every option here beats having no second factor. But the gaps between them are not matters of taste - each one fails to a specific, well-documented attack.

SIM swap, the attack that makes SMS fragile

A SIM swap does not attack you. It attacks your mobile operator. Staff are tricked or bribed into moving your number to a SIM the attacker controls, or a port-out request is filed with a rival carrier. From that moment every text message addressed to your number - including password reset codes - arrives in their hand. Nothing on your phone is compromised, which is why it is so disorienting when it happens.

NIST permits codes sent over the public telephone network but flags the risk explicitly, and CISA names SMS the weakest available option. If your operator offers a port-out PIN, a transfer lock or an account passphrase, set it today - it is the single highest-value call you can make that does not involve a settings screen.

TOTP: why app codes are better, but not sufficient

TOTP means time-based one-time password: the six digits that roll over every thirty seconds. At setup, a QR code hands your app a shared secret. The app and the server each derive the same code from that secret and the current time, which is why the codes match without any network traffic between them.

Nothing crosses the telephone network, so SIM swaps are irrelevant, and it works offline. The limitation is structural: the output is a short string a human reads and types. Anything a human can read, a human can be persuaded to read aloud to the wrong person - or type into a page that is quietly relaying it.

Push bombing, and why number matching fixed most of it

Push approval sends a prompt you tap to accept. That convenience was exploited at scale: attackers who already had a password fired prompts repeatedly, often at two in the morning, until the victim tapped Approve to make it stop. Number matching closed that specific hole by displaying a two-digit number on the login screen that you must type into the app. A blind tap no longer completes anything, and an attacker who cannot see your screen cannot supply the number. It does not stop an attacker who is simultaneously on the phone with you, which is why the technique is described as good rather than resistant.

Why Passkeys Resist the Attack Everything Else Loses To

The attack that beats every code-based method is adversary-in-the-middle phishing: a live proxy that forwards your password to the real site, relays the real challenge to you, takes your code and finishes the login as you. Codes, push numbers and security answers all pass through it. Ready-made kits are rented by subscription, so this is not an exotic technique.

One key pair per site, and the private half never moves

When you register a passkey, your device - the authenticator - generates a fresh key pair used for that site alone. The public key goes to the site. The private key stays in secure hardware: a secure element, a TPM, or the chip inside a USB key. It is never transmitted, not to the site and not to you. A breach at the service leaks a public key, which is public by design, and there is no shared secret for you to retype into the wrong page.

The credential is bound to the site's origin

Each passkey is stored against the site's domain - technically its relying party ID. At sign-in, the browser, not the page, determines which domain you are really connected to, and offers only passkeys registered for that exact domain. On a lookalike domain there is no matching credential, so the fake page has nothing to elicit. The prompt you expect simply never appears, which is itself a warning worth heeding.

Even a signature somehow coaxed out would be useless. What the authenticator signs includes the origin that the browser observed, meaning the real scheme and hostname. The genuine site checks that the signed origin is its own. A signature produced on a copycat domain carries the copycat's origin and is rejected. The attacker cannot edit it, because altering signed data invalidates the signature, and they do not hold the private key needed to make a new one.

That is the important part: the protection does not depend on you noticing a misspelled address. It holds even when you are tired, rushed or reading on a small screen. Spotting the fake page still matters - see recognising phishing - but with a passkey, failing to spot it is no longer fatal.

Synced Passkeys Versus Device-Bound Credentials

The two are equally resistant to phishing, because both rely on the same origin binding. What differs is how a credential can be lost, or reached.

Synced is the right default for most people, because the realistic threat is a phone left in a taxi rather than an attacker breaking the encryption of a keychain. The catch is that syncing moves part of your security onto the account doing the syncing, so that account deserves a passkey of its own and a strong, unique passphrase.

Where compromise would be severe - a work account with access to customer data, an account that can move money, or an account belonging to someone who is publicly visible - a key you physically hold is stronger, because there is no online account that can be phished to reach it. NIST's higher assurance levels expect exactly that kind of hardware authenticator for exactly this reason.

Enrolling Properly, and in the Right Order

Most MFA disasters are not break-ins. They are lock-outs, or a strong front door standing beside an unlocked window.

1. Add a second factor, then immediately add a backup. Two passkeys on two devices, or a passkey plus a security key, or a key plus an authenticator app. A single factor plus a lost phone is a week in a support queue. If you buy security keys, buy two and enrol both the same day.
2. Keep recovery codes offline. Print the one-time list and store it with your documents. Putting it in the same password manager that holds the password collapses two factors into one container, which is particularly poor for your mailbox.
3. Close the weak fallback. If a text message can still reset everything, your new key has not raised the floor. Remove SMS and security-question fallbacks wherever the service allows it. Some do not, and that is worth knowing rather than assuming.
4. Read the recovery path now. Find out today what happens when you lose the device, rather than discovering it then. The steps for a compromised account are on account recovery.

The order that matters

Sort accounts by what each one can unlock, not by how much you like them.

1. Primary email. It can reset nearly everything else, so it gets the strongest method it supports, today.
2. Your password manager and platform account (Apple, Google, Microsoft). These hold or gate the rest; see passwords and password managers.
3. Your mobile operator account, plus a port-out PIN. This is the step people skip, and it is the hinge of every SIM-swap fraud.
4. Banking and payment accounts, where losses are immediate and sometimes irreversible.
5. Social, messaging and work accounts, which are used to deceive the people who trust you.

Where to look: a Google Account has it under Security, then How you sign in to Google; Apple devices under Settings, your name, then Sign-In & Security; a Microsoft account under Security, then Advanced security options. Each screen lists current passkeys, security keys, authenticator apps and the fallbacks still enabled.

What MFA Does Not Solve

After you authenticate, the site hands your browser a session cookie: proof that this browser already signed in, so you are not challenged on every page load. That cookie is a credential in its own right. Malware that copies the browser's cookie store, or a proxy that keeps the session it just completed for you, lets an attacker load that token into their own browser and be inside your account without ever meeting your MFA.

This is now one of the most common routes into accounts that had multi-factor authentication switched on the whole time. The partial defences are worth knowing:

• Sign out on shared or borrowed machines rather than just closing the tab.
• Periodically use the account's sign-out-everywhere option, which invalidates tokens on all devices.
• On any suspected compromise, revoke sessions as well as changing the password, or the intruder stays logged in through the change.

MFA also protects the login, not the computer. An information-stealing malware or a remote-access tool reads what you read, captures codes as you type them and acts inside sessions you opened. A security key cannot help there, because the attacker is not logging in - they are riding a session you authenticated.

Nor does MFA cover consent phishing, where you legitimately grant a third-party app access to your mail or files. You approve it yourself, it receives its own token, and from then on it needs no login at all. Review connected apps in your security settings and remove anything you do not actively use; that list is often years old and full of experiments.

The honest costs

Passkey support is still uneven across services, security keys cost money and must be carried, and removing SMS fallbacks genuinely makes a lost device harder to recover from - which is precisely why the backup factor and the printed codes are not optional extras. Set against that: the attacks emptying accounts at scale today are password reuse and phishing, and a passkey ends both of them.

Questions readers ask about this page

Back to top ↑