How has multi-factor authentication evolved from tokens to passkeys?

Multi-factor authentication grew from one-time codes on hardware tokens to SMS, authenticator apps, push approvals and finally cryptographic authenticators such as passkeys. Each step cut friction or closed a hole the last one left open. The current direction is phishing-resistant authentication, where a fake login page cannot capture a usable credential.

What counts as multi-factor?

NIST's glossary, drawing on CNSSI 4009, defines multi-factor authentication as using two or more different factors: something you know, something you have, something you are. CISA's public guidance uses the same three and adds that a second factor stops an attacker who has only stolen the password.

The word different matters. A password plus a security question is two things you know, which is one factor twice.

What came first?

The early second factor was a hardware token that showed a code changing every 30 or 60 seconds. It worked, and it was expensive to ship and replace. Banks and large employers used it; most websites did not.

Next came codes sent by SMS. They needed no hardware, so adoption spread quickly. The weakness was the channel. A code on a phone number can be diverted or read by someone other than the owner, and a person can be tricked into typing it into a lookalike site.

NIST SP 800-63B, the US federal digital identity guideline, reflects this. It places restrictions on the public switched telephone network as an authenticator channel and sets out separate assurance levels for different authenticator types. It also says authentication at the highest level, AAL3, requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance. Read the current text before you cite a rule, because the 800-63 suite has been revised.

What did authenticator apps and push change?

Time-based one-time passwords generated on a phone removed the carrier from the picture. The secret lives on the device, so the code cannot be redirected.

Push approvals made it easier still: tap approve. They also created a new attack. An attacker with a valid password can trigger a stream of prompts until a tired user accepts one. Number matching, where the user types a number shown on the login screen, was added to reduce blind approvals.

None of these stop real-time phishing. If a user enters a password and a code on a convincing fake site, the attacker can replay both at once on the real one.

What makes passkeys different?

A passkey is a cryptographic credential tied to the site that created it. The private key stays on the device, and the browser only releases a signature to the genuine origin. A fake domain gets nothing worth replaying.

That property is what the standards call phishing resistance. It also removes the shared secret from the server, so a breach of the service does not leak reusable passwords. Passkeys are built on the FIDO Alliance and W3C WebAuthn specifications. We could not fetch the FIDO site for this review, so check its current pages for details on synced and device-bound credentials.

CISA's page on multi-factor authentication lists some options and tells people to enable it wherever it is offered. For organisations, the stronger step is to rank factors by what an attacker can do to them.

A constructed ranking

Take a company with 400 staff using passwords plus SMS everywhere. A realistic upgrade path looks like this:

1. Administrators and finance staff first: move to passkeys or security keys.
2. Everyone else: authenticator app with number matching, replacing SMS.
3. Keep SMS only as a recovery path with extra checks, and then retire it.
4. Add rate limits and alerts on repeated push prompts.

The order follows the damage a stolen account can do, not the org chart.

How to check or apply this

1. List every login path: workforce, customer, API, admin consoles, VPN, and the helpdesk reset process.
2. Mark which factor each path uses and whether it can be phished in real time.
3. Move privileged accounts to phishing-resistant authenticators first.
4. Replace SMS and voice codes where an alternative exists.
5. Turn on number matching or similar controls for push approvals.
6. Review account recovery. Attackers go around strong factors by using weak resets.
7. Re-check against the current NIST SP 800-63B text before you set policy.

Quick check

Sources

• NIST CSRC glossary, multi-factor authentication
• NIST SP 800-63B, Digital Identity Guidelines: Authentication
• CISA, More than a Password

Last reviewed: 18 October 2026.