Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
Two-factor authentication still matters in 2026, but it does not stop every account takeover. It protects the login step by requiring a second factor in addition to a password. It does not stop an attacker who steals a valid session cookie, OAuth token, API key, or SSH key from an already authenticated device. That is the practical lesson security teams have been repeating for years, and it is the right frame for understanding the May token-theft reporting: enable strong 2FA anyway, then reduce the value of stolen credentials with short token lifetimes, limited scopes, and fast revocation.
This guide explains what 2FA does, where it falls short, which methods are strongest, and what to secure first.
TL;DR: 2FA helps at sign-in, but stolen tokens can bypass sign-in entirely, so strong authentication must be paired with token controls.
Reports in May 2026 renewed attention on a familiar security problem: attackers increasingly target developer endpoints, browser sessions, local credential stores, and long-lived tokens rather than trying to guess passwords at the login page. That distinction matters.
A password plus 2FA protects the authentication event. But once a user has already authenticated, many systems issue session cookies, refresh tokens, API tokens, or SSH credentials so the user does not have to re-authenticate on every request. If an attacker steals one of those artifacts from the device or browser, they may be able to act as the user until the credential expires or is revoked.
That does not make 2FA obsolete. It means 2FA solves one important problem, while token management solves another.
Think of 2FA as the checkpoint at the entrance. A session token is what the system gives you after you pass the checkpoint. If someone steals that token later, they may not need to pass the checkpoint again.
In practice, the risk depends on the system:
The weaker those controls are, the less protection 2FA provides after login.
TL;DR: 2FA combines something you know with something you have or are, so one stolen factor is not enough by itself.
A password is usually something you know. A second factor is usually something you have such as a phone, security key, or device-bound credential. In some systems it can also be something you are, such as a biometric unlock used to release a passkey stored on your device.
The goal is simple: if a password is phished, reused, guessed, or leaked in a breach, the attacker still cannot log in without the second factor.
That is why 2FA remains one of the highest-value security settings for email, code hosting, cloud accounts, and domain registrars.
TL;DR: Prefer hardware security keys or passkeys, use authenticator apps when needed, and treat SMS as a fallback rather than a first choice.
| Method | Strength | Phishing resistant? | Main risk |
|---|---|---|---|
| Hardware security key | Strongest | Yes | Loss without a backup key or recovery plan |
| Passkey | Strongest | Yes | Account recovery can be messy if sync and backup are not configured |
| Authenticator app (TOTP) | Good | No | Real-time phishing and prompt fatigue still work |
| SMS code | Weakest acceptable option | No | SIM-swap risk, carrier recovery abuse, and weaker account recovery paths |
Hardware keys and passkeys are generally the best options because they are built on the FIDO2/WebAuthn model. The credential exchange is tied to the legitimate site, which makes them far more resistant to phishing than one-time codes.
A hardware security key is a dedicated device such as a YubiKey or Google Titan key. A passkey is a FIDO credential stored on a phone, laptop, or password manager and often unlocked with biometrics or a device PIN.
Both are strong choices. The practical difference is convenience and recovery planning:
Authenticator apps generate time-based one-time passwords, usually six-digit codes that rotate every 30 seconds. This is commonly called TOTP.
TOTP is still much better than password-only login, but it is not phishing-resistant. If a fake site asks for the current code, a victim can still hand it over in real time. That is why many security teams now treat TOTP as a solid middle tier rather than the end state.
SMS is better than no second factor, but it is the weakest mainstream option. The biggest issue is not only telecom protocol weaknesses; it is also the broader account-recovery ecosystem around phone numbers. Attackers may abuse carrier support processes, social engineering, or number-porting workflows to take control of a victim's number.
For low-risk accounts, SMS may be acceptable if it is the only option. For email, cloud, code hosting, finance, and domain control, stronger methods are preferable.
TL;DR: Strong sign-in protection matters, but short-lived, scoped, revocable credentials limit the damage when a device or session is compromised.
The practical baseline in 2026 is not just "turn on 2FA." It is:
This matters because many modern attacks target the endpoint itself. If malware can read browser cookies, local credential caches, or developer secrets, the attacker may inherit access that was already approved.
That is why the right question is not "Does 2FA work?" The right question is "What happens after login, and how much damage can one stolen credential do?"
TL;DR: Start with the accounts that can reset, deploy, transfer, or impersonate everything else.
Prioritize these accounts first:
For each account:
TL;DR: An AI assistant can help build an account inventory, but verify the results manually and do not paste secrets into the prompt.
Use a prompt like this with your preferred assistant:
Review my project's deployment setup, dependencies, and operational tooling.
List the external services and accounts the project depends on, including:
code hosting, CI/CD, cloud hosting, DNS, domain registrar, email,
payment providers, analytics, CDN, support tools, identity providers,
and AI tools connected to code or documentation.
For each one, explain:
1. What an attacker could do with full account access
2. Whether the damage would be reversible, expensive, or permanent
3. Which authentication method the service supports, if known
4. How urgently the account should be upgraded to phishing-resistant MFA
Then rank the accounts from highest to lowest impact.Do not paste API keys, recovery codes, tokens, or internal configuration secrets into the prompt. Use the assistant to build a checklist, not to handle credentials.
No. It is highly effective against password-based attacks, including credential stuffing, password reuse, and many phishing attempts. It does not fully protect against stolen session cookies, malware on a trusted device, or long-lived API tokens that were issued after authentication.
They use the same general phishing-resistant standards family, but they are not identical. A hardware key is a dedicated physical authenticator. A passkey is usually stored on a phone, laptop, or password manager and unlocked locally. Both are strong; the better choice often comes down to risk level, convenience, and recovery planning.
Yes. TOTP is still a meaningful upgrade over password-only login and often the best option on services that do not yet support passkeys or security keys. It is just important not to confuse "better" with "phishing-resistant."
Because email is the recovery channel for many other services. If an attacker controls the inbox, they can often reset passwords elsewhere, approve device challenges, or intercept security notifications.
Treat it as an active compromise. Revoke sessions, rotate API keys and refresh tokens, review OAuth grants, inspect recent account activity, and investigate the endpoint where the theft likely occurred. If malware is suspected, credential rotation should happen after the device is cleaned or replaced.
The right takeaway from the May token-theft coverage is not that 2FA failed. It is that authentication has two phases: proving identity at sign-in and controlling what remains valid afterward. Strong 2FA still closes off a large class of common attacks. But durable security comes from pairing it with short-lived sessions, narrow token scopes, disciplined revocation, and careful endpoint hygiene. In 2026, that combination is the real baseline.
Discover more content: