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. Someone signs up to a forum with the same password as their email, the forum gets breached, and within hours automated scripts try those exact credentials against Gmail, Outlook, and banking sites. Second, breaches reached industrial scale, producing vast troves of stolen username-and-password pairs that criminals test automatically against other services. This "credential stuffing" works precisely because reuse is so common — the attacker needs no skill, only the leaked lists.

Single-factor authentication has a structural flaw: the one factor it relies on — a secret — can be guessed, stolen, reused, or phished. A convincing fake login page captures it exactly as readily as the real one.

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. Note the requirement that the factors be different — password plus security question still counts as single-factor, since both are things an attacker can learn. 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.

That offline design brought real trade-offs. A token whose clock drifted, or whose counter got pressed in a pocket while unread, could generate codes the server rejected. Enterprises solved this with a resync procedure — the user entered two or three consecutive codes so the server could locate the token's actual clock offset or counter position. Lost tokens were another headache: each one carried a unique seed that could not be cloned, so a replacement had to be manufactured, pre-loaded and shipped, often taking days.

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. A consumer site signing up millions of users could not absorb that logistics burden, so most people's accounts stayed protected by passwords alone until a cheaper factor — the mobile phone — changed the equation.

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. This usually starts with a phone call to the carrier, not a hack of your account — which is why a strong carrier PIN or a port-freeze request matters if you must keep SMS enabled.
• Interception: codes travel over the mobile network and can be captured through certain telecom attacks. Ordinary users cannot prevent this directly; only moving away from SMS can.
• Carrier dependency: no signal, no roaming, no code — and often no way into your account. Travellers and people in basements or rural areas hit this constantly, so keep a backup method configured before you need it.

Common mistakes compounded these risks. Many people treated the code as a formality and read it out to a caller claiming to be their bank — real support staff never ask for it. Others reused one phone number for everything, so a single SIM swap unlocked email, banking and social media at once.

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.

The trade-offs users still live with

• Device loss. The shared secret lives on one phone. Wipe it, drop it in a lake, and the codes are gone. Save the backup/recovery codes a site shows at enrolment — that's the reason they exist. Some apps offer encrypted cloud backup; enable it only if you trust the account protecting it.
• Clock drift. TOTP depends on the phone's clock. A device minutes off time generates codes the server rejects. Fix: sync the clock, or re-scan the QR code.
• Secret reuse. Storing the same secret on two apps is fine; storing it in a screenshot or notes app is not. The QR code is the password to your second factor.

Practical habit: enrol a backup method — a second TOTP app or printed recovery codes — before you need it, not after the phone disappears.

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.

Using one is deliberately simple. You register the key with each account once, then tap it (or touch its sensor) when the browser prompts you during sign-in. Most keys require a physical touch even when connected, which prevents a remote attacker from silently triggering a login while the key sits plugged in. Many models also include a fingerprint reader to stop whoever finds a lost key from using it.

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. A phishing site can mimic the login form perfectly, but the browser tells the key the true domain, and the key refuses to sign.

Practical caveats remain. Register at least two keys per account — keys are lost, dropped in rivers, and left in laptops at airport security. Store the backup somewhere separate from your primary device. And check that every service you care about supports the protocol before standardizing on keys, because coverage for some account types still lags behind.

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. When you sign in, the site sends a challenge; your device signs it with the private key, and the site checks the signature against the stored public key. The secret never leaves your hardware.

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. Check that sync is actually enabled before you rely on it; a passkey created on a single non-synced device is as fragile as a hardware token you left at home.
• 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. A lookalike domain fails the binding check, and the browser simply has no matching key to offer.

Two practical notes. First, passkeys and recovery codes coexist: keep your backup methods current, because the strongest credential still needs a way back in after a lost phone. Second, adoption is uneven — many services still treat passkeys as an optional second factor rather than a full password replacement, so expect a transition period where you maintain both.

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. That is why "mother's maiden name" and similar questions should never gate access to an account with 2FA enabled.

Coexistence, Not Replacement

Hardware tokens, authenticator apps, SMS codes, and passkeys will coexist for years. Services, budgets, and users all move at different speeds. Your bank may still send codes by SMS while your password manager already supports passkeys — use the strongest option each service offers rather than waiting for uniformity.

Practical Takeaway

Turn on 2FA everywhere it is offered. Prefer a passkey, security key, or authenticator app over SMS. Store backup codes offline — a printed copy in a drawer beats a screenshot in your camera roll, which syncs to the cloud. Enroll a second device or factor where possible, so a lost phone is an inconvenience, not a lockout. Then review your recovery settings: remove stale backup emails, replace weak security questions, and confirm that support-based resets still require proving your identity. That is where most accounts actually fall.