The History of 2FA: From Hardware Tokens to Passkeys

Why Passwords Alone Stopped Being Enough

For decades, a username and password were all that stood between an attacker and your account. That was workable when accounts lived on a single office server. It stopped being workable when nearly everything — banking, email, work, shopping — moved online.

Two problems compounded. First, people reuse passwords: one breach at a minor site hands attackers credentials that may also open an email inbox or a bank account. Second, breaches reached industrial scale, producing vast troves of stolen username-and-password pairs that criminals test automatically against other services.

Single-factor authentication has a structural flaw: the one factor it relies on — a secret — can be guessed, stolen, reused, or phished.

Security researchers describe authentication in terms of three factor types:

• Something you know — a password or PIN
• Something you have — a phone, hardware token, or security key
• Something you are — a fingerprint or face

Combining two different factors raises the bar sharply: a stolen password alone no longer opens the door. Attackers must also steal a device or a biometric. That simple idea drives everything that follows.

The Hardware Token Era (1980s–2000s)

The first widely used second factors were small hardware tokens: key fobs or card-sized devices with a tiny screen showing a numeric code. Banks issued them to corporate customers, and enterprises handed them to employees for VPN and network logins. RSA's SecurID, introduced in the 1980s, became the best-known example.

How the codes worked offline

Tokens needed no connectivity. In time-based designs, the token and the server shared a secret seed and a clock; every minute or half-minute, both derived the same code from that seed plus the current time. Event-based designs replaced the clock with a counter: pressing the button incremented it, and both sides computed the code from the new count. Because token and server followed identical rules, they stayed in sync without ever communicating.

Why ordinary users never saw them

Each fob had to be manufactured, shipped, enrolled and eventually replaced when its battery died or it was lost. That per-user cost, plus inventory and helpdesk overhead, confined hardware tokens to banks and large enterprises.

SMS Codes Take 2FA Mainstream

By the mid-2000s, mobile phones were everywhere. Banks realised they could text a one-time code to confirm a login or transfer, and suddenly the second factor reached millions of people overnight. No dongle to buy, no software to install — the phone already in your pocket became the second factor.

Web services followed. Email providers, social networks and shopping sites added "send a code to your phone" as an option, and 2FA stopped being a corporate security tool and became something ordinary users could switch on in a few taps.

SMS had real trade-offs, though:

• SIM swapping: an attacker who tricks or bribes a carrier into moving your number to a new SIM receives your codes.
• Interception: codes travel over the mobile network and can be captured through certain telecom attacks.
• Carrier dependency: no signal, no roaming, no code — and often no way into your account.

SMS made 2FA mainstream, but it also exposed a flaw: the second factor belonged to your carrier, not to you.

Authenticator Apps and Push Approvals

Smartphones put a hardware token in everyone's pocket. TOTP apps such as Google Authenticator and Authy generate 30-second codes offline from a shared secret. Because generation is local, codes work in airplane mode and never travel over the network — no carrier dependence, no interception of the code itself.

Easier enrolment

Early setup meant typing long base32 keys by hand. QR-code enrolment replaced that: scan, done. Secrets transferred in seconds, cutting misprints and support requests.

Push approvals

Push approval replaced typing entirely: a notification arrives, one tap signs you in. It was faster, harder to get wrong, and worked even when users couldn't see the login screen. Number matching — typing a code from the screen into the prompt — later added a guard against accidental approvals.

The convenience cut both ways. Attackers learned to send approval requests repeatedly until a tired user tapped accept — push fatigue. Number matching and clearer prompts reduce that risk but don't remove it. And like passwords and SMS codes, TOTP codes can simply be phished when users are tricked into reading them out.

Security Keys and the Shift to Public-Key Authentication

By the early 2010s, a group called the FIDO Alliance set out to remove the core weakness of every method before it: the shared secret. Passwords, SMS codes, and even TOTP seeds exist on both the server and the user's side, so anyone who steals the server's copy can log in. FIDO replaced this model with public-key cryptography. The private key never leaves your device; the server stores only a public key and issues challenges that only your private key can answer. No secret ever crosses the network.

Hardware security keys

Security keys are small physical devices that connect over USB, NFC, or Bluetooth. Their defining property is phishing resistance: the key verifies the website's origin before signing anything, so a fake login page at a lookalike domain receives no valid signature.

Why origin binding matters

Because each signature is bound to the exact origin, a credential captured from one site cannot be replayed on another — or on the same site through a spoofed domain. There is simply nothing reusable to steal.

Passkeys: The Current Chapter

Passkeys are the newest chapter in this story, built on the FIDO2 framework and its WebAuthn protocol, which lets websites verify logins directly in the browser. A passkey replaces the shared secret of a password with a cryptographic key pair: the private key stays on your device or in your synced account, while the website stores only the public half.

What changes for everyday logins

• Nothing to type. Signing in means confirming with a fingerprint, face, or device PIN. No codes to receive, retype, or intercept.
• Synced across devices. Apple, Google, and Microsoft sync passkeys through their account services, so losing one device doesn't lock you out.
• No secrets on the server. Because sites keep only public keys, a database breach reveals nothing an attacker can use to sign in.

Passkeys are also phishing-resistant by design: the browser cryptographically binds each credential to the legitimate website's address, so a convincing fake site cannot collect a credential that works anywhere else.

What the History Teaches

Every generation of 2FA traded the same three things differently. Hardware tokens were secure but costly and easy to lose. SMS codes were free and familiar but vulnerable to interception and SIM swapping. Authenticator apps improved security at little cost, while push approvals leaned toward convenience, sometimes at the expense of careful judgment. Passkeys finally align security with usability, though adoption takes time.

Recovery Is the Real Weak Point

Across every era, attackers rarely beat the factor itself. They reset it. Recovery flows built on backup emails, security questions, or a persuasive phone call to support have undone even the strongest authentication. A passkey protects little if recovery can bypass it.

Coexistence, Not Replacement

Hardware tokens, authenticator apps, SMS codes, and passkeys will coexist for years. Services, budgets, and users all move at different speeds.

Practical Takeaway

Turn on 2FA everywhere it is offered. Prefer a passkey, security key, or authenticator app over SMS. Store backup codes offline. Then review your recovery settings — that is where most accounts actually fall.