Can 2FA be bypassed? The five routes, ranked

Yes. Not by breaking the six digits — nothing on this page involves guessing a code — but by going around them. Every route below ends the same way: somebody is holding a signed-in session they never had to pass your authenticator to get.

You already use an app rather than texted codes, which puts you ahead of most people and closes a real category of attack. So the useful question is narrower than "can 2FA be bypassed". It is: which bypasses did that choice actually close, and which did it leave untouched? Three of the five below are untouched by it, and two of those three are the ones most likely to happen to you.

What follows is ranked by how often each route reaches an ordinary individual, rather than an enterprise with a help desk. That ordering is a judgement, not a measurement — nobody publishes per-route takeover counts for consumer accounts — and the reasoning for each position is stated in its section so you can disagree with it. Each section ends with the specific thing to go and check on your own accounts, because that is the only part of this page that changes anything.

The short answer, before the detail

• An authenticator app does close SIM swapping and SS7 interception of your login codes, and it closes everything that only ever had your password.
• It does not stop a real-time phishing proxy. A TOTP code is a number you type into whatever page is in front of you, and the page can simply pass it on.
• It does not stop a stolen session cookie, which skips the login screen — and therefore the second factor — completely.
• It does not stop anybody who takes the recovery route instead of the login route.
• And your sheet of backup codes is, by design and by documentation, a sanctioned way around the app.

If you want the one-line version: an authenticator app is a good answer to a stolen password and a poor answer to a stolen session.

1. The recovery chain, and the password reset behind it

Why this is first. Every account you own has a documented route back in that does not involve your authenticator. It has to — people drop phones in rivers. That route is the one an attacker takes, because it is the one that was deliberately built to work when the second factor does not.

Google's own description of what recovery details are for is unambiguous. A recovery email address is there "To help you get into your account if you forget your password or can't sign in for another reason", and a recovery phone number is there "To send you a code to get into your account if you're ever locked out" (Google). Where no second step is available at all, Google falls back to questions about the account, and tells you the price of that: "it can take 3-5 business days for Google to make sure it's you" (Google).

None of that is a flaw. It is the reason your account is only as strong as the weakest route into it — and for most individuals the weakest route is an email address, often an old one, protected by a password and nothing else.

It takes three shapes worth telling apart:

• The address at the root. Your primary email resets the password on everything that recovers through it. Whoever holds that mailbox does not need to defeat your authenticator on thirty services; they need to defeat it on one, or on none, if the mailbox itself has no second factor.
• The reset that never asks. On plenty of smaller services, clicking the link in a reset email is treated as proof of identity and lands you in a signed-in session without the second step being requested at all. That is a design decision on their side, invisible from yours, and the only way to find out is to try it on an account you own.
• The human in the middle. CISA and the FBI describe this one directly in their joint advisory on Scattered Spider: after gathering a target's personal details, the actors "use social engineering techniques to convince IT help desk personnel to reset passwords and/or MFA tokens to perform account takeovers" (CISA AA23-320A). That is written about companies, but consumer support lines run the same play, with your date of birth and the last four digits of a card as the test.

The standards are clear about what should happen instead, which is a useful way to judge a service you are relying on. NIST requires that binding a new authenticator to an account "requires authentication at either the maximum AAL currently available in the subscriber account or the maximum AAL at which the new authenticator will be used, whichever is lower", and that the provider "notify the subscriber via a mechanism independent of the transaction binding the new authenticator" (NIST SP 800-63B-4 §4.1.2). OWASP puts the same thing in plainer words about changing an MFA factor: "Because attackers can exploit this process to take over accounts, it must be strictly secured", and the countermeasure is to "Require reauthentication with an existing enrolled factor before allowing changes" (OWASP).

Go and check this on your own accounts.

1. Open the security page of your primary email and read the recovery email address and recovery phone number. Do you still control that address? Does it still belong to you? An address at a former employer or a long-dead provider is a live key in somebody else's hand.
2. Check that the recovery mailbox itself has a second factor. It almost never does, because nobody thinks of it as an account.
3. On your two or three most important accounts, find the "email address" setting and ask whether changing it would require re-authentication. If an attacker can quietly move the recovery address, every other control is downstream of that.
4. Do not respond to this by deleting every recovery route. That is how you lock yourself out, and it converts a security problem into a permanent one. Replace weak routes with strong ones instead: a current address you control, with 2FA on it.

2. A stolen session cookie

Why second. It is the route most people have never heard of, it needs nothing from you once the cookie is taken, and — unlike every other route here — it produces no prompt, no code request and usually no notification, because from the service's point of view nobody logged in.

Chrome's own engineers state the mechanism in one sentence: "Cookie theft like this happens after login, so it bypasses two-factor authentication and any other login-time reputation checks" (Chromium team). Microsoft says the same from the attacker's side: "Once the attacker obtains the session cookie, they can inject it into their browser to skip the authentication process, even if the target's MFA is enabled" (Microsoft).

This is not a theoretical consumer risk. Google's Threat Analysis Group documented a long campaign against individual YouTube creators, in which cookie-stealing malware arrived as a fake sponsorship deal — an antivirus trial, a VPN, a photo editor, a game. TAG describes cookie theft as "a session hijacking technique that enables access to user accounts with session cookies stored in the browser", counted "1,011 domains created" for the delivery, and noted that hijacked channels were sold on for anything "from $3 USD to $4,000 USD"; Google restored around 4,000 accounts (Google TAG).

Cookies reach an attacker two ways. Information-stealing malware scrapes them off the machine — which is why a cracked application, a game mod, a "codec" or an installer from a search ad is a 2FA problem and not just a malware problem. Or a phishing proxy catches one in flight, which is route 3.

Go and check this on your own accounts.

1. Open your account's active-session list and end everything you do not recognise. On Google this is Security, then "Your devices" and "Where you're signed in"; most large services have an equivalent page, and on a lot of them you will find a browser you stopped using two laptops ago.
2. Change the password afterwards. Signing out of a list is often the weaker action; on most services it is the password change that invalidates issued sessions.
3. Review third-party app access separately. Signing out of devices does not revoke an OAuth grant, and a connected app with mailbox scope is its own standing key.
4. Think honestly about what you have installed in the last few months from somewhere that was not the vendor. That, not your authenticator, is where this route starts.

3. A real-time phishing proxy

Why third. It is less common than the two routes above for an individual, because it needs you to click something and act inside the life of one code. It is above the two below because the tooling is now commodity: an attacker does not build this, they run it.

Microsoft's description of the mechanism is worth reading slowly: "The attacker deploys a webserver that proxies HTTP packets from the user that visits the phishing site to the target server the attacker wishes to impersonate and the other way around." You are not looking at a copy of the login page. You are looking at the real page, fetched for you by somebody standing in the middle. You type the password, you read the six digits off your phone, you type those too, and everything you send is forwarded on in real time. What comes back is a valid session cookie, and the attacker keeps it. Microsoft tracked one such campaign that "attempted to target more than 10,000 organizations since September 2021".

Then the sentence that matters most on this page: "This is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user's behalf, regardless of the sign-in method the latter uses."

CISA's ranking of MFA methods from strongest to weakest puts app-based one-time passwords exactly where that leaves them — above SMS, and marked "Vulnerable to phishing attacks". Its description of the phishing technique names your app specifically: "The user submits their username, password, as well as the 6-digit code from their mobile phone's authenticator app" (CISA).

One thing does stop this, and it is the reason that fact sheet exists. CISA calls FIDO/WebAuthn and PKI-based authentication "phishing-resistant MFA", "the gold standard for MFA", and marks it "Resistant to phishing". The difference is not that a key is harder to steal. It is that a key signs a challenge tied to the real site's origin, and the proxy's domain is not that origin, so there is nothing for it to relay. Authenticator app vs security key and passkeys vs authenticator apps go through what that costs you in practice.

Go and check this on your own accounts.

1. Make it a habit that you never reach a login page from a link — in an email, a message, a search ad or a sponsorship offer. Type the domain or use your own bookmark. A proxy can forge everything on the page; it cannot forge the address you typed.
2. Let your password manager be the detector. It fills on an exact domain match and stays silent on a lookalike, and that silence is the signal. If you find yourself copying a password across because autofill "isn't working", stop.
3. Decide which one or two accounts would be catastrophic — primary email, password manager, domain registrar, bank, cloud console — and put a security key on those. For that short list, an authenticator app is the wrong tool, and no authenticator app, including ours, is the right one.

4. A SIM swap on a recovery number

Why fourth. You moved your login codes off SMS, which is the right call. The trap is that the phone number almost certainly stayed behind in the recovery slot, where it still does the same job.

A SIM swap is "a form of social engineering in which cyber threat actors convince cellular carriers to transfer control of the user's phone number to a threat actor-controlled SIM card", as CISA puts it. The FBI's Internet Crime Complaint Center gave a sense of the trend in a 2022 public service announcement: 1,611 SIM swapping complaints in 2021 with adjusted losses above $68 million, against 320 complaints and about $12 million across the whole of 2018 to 2020. Those are complaints to one agency in one country — a floor, not a total.

The reason this still concerns you after switching to an app is route 1. Your carrier does not control your accounts; your recovery phone number does, because a recovery number exists, in Google's own words, "To send you a code to get into your account if you're ever locked out". Taking the number is a way of taking the recovery channel, and the recovery channel does not care which authenticator you use. Authenticator app vs SMS is the longer version of what SIM swapping does and does not reach.

Regulators have moved on the carrier side: US wireless providers must now adopt secure methods of authenticating a customer before redirecting a number, and must "immediately notify customers whenever a SIM change or port-out request is made" (FCC). That notification is only useful if it reaches you somewhere other than the line being stolen.

Go and check this on your own accounts.

1. On each important account, look at the recovery phone number as a separate setting from the 2FA method. Having switched 2FA to an app does not remove the number, and most people have never looked at the two fields side by side.
2. Where you have an authenticator plus a current set of backup codes, consider removing the phone number from recovery entirely. Where that leaves you with no way back, keep it and treat the number as a credential.
3. Turn on whatever your carrier calls a number lock, port-out PIN or SIM protection, in the account settings rather than on the phone itself.
4. Make sure carrier security notifications go to an email address, not only to the line. A warning delivered to the SIM somebody just stole is not a warning.

5. A backup code sheet somebody else can read

Why last. It is the lowest-frequency route, because it needs access to a specific object or file rather than a scalable trick. It is also the most certain one when it happens: there is no prompt to miss and no window to beat.

NIST classifies these as look-up secrets, and the rule is the simple one — "A secret from a look-up secret authenticator SHALL be used successfully only once" (NIST SP 800-63B-4). A code is not a second copy of your authenticator. It is a replacement for it, issued by the service, honoured by the service. Your password plus one unused line from that sheet is a complete login in which your authenticator is never consulted.

This is why where it lives matters more than how long it is, and it is the point all three of the pages currently ranking for this question skip. Where to store your 2FA backup codes is the whole argument; the short form is that the sheet must not sit anywhere that already holds the password for the same account. The good news is that the fix is free and does not need the old sheet: GitHub, for one, documents that generating new recovery codes "will invalidate any codes you previously generated" (GitHub docs).

Go and check this on your own accounts.

1. For each account with 2FA, answer one question: where is the code sheet, and how many copies exist? "Somewhere" counts as a no.
2. Any copy that is in the same password manager entry as the password, in a sent email to yourself, in a screenshot in your camera roll, or in a text file on a laptop that has since been sold — regenerate that set today.
3. After regenerating, destroy or replace every copy you distributed. An old sheet in a drawer at a relative's house is waste paper; an old sheet you forgot to replace at the other location is a live credential.

What is not on this list, and why

A code that stops being accepted. It reads like evidence of an attack and it almost never is. A drifted clock, a retired entry from an enrolment you forgot about, or a service with a tighter acceptance window than its neighbours all produce exactly the same symptom, and none of them involves anybody else. 2FA code not working: causes and fixes, in order works through them; the thing actually worth checking once you are back in is the account's list of registered second factors, not the code.

Two things you will find on most pages answering this question, left out deliberately.

Guessing the code. The arithmetic is in the standard. For HOTP, the chance of a successful guess is Sec = sv/10^Digit, where v is the number of attempts allowed — and the same document says "We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation" (RFC 4226). One in a million per attempt, against a verifier that is counting. Where this does succeed it is a bug in one service's rate limiting, not a property of 2FA, and nothing you do on your phone changes it.

Public Wi-Fi. The common advice to avoid café networks when signing in is filler on this topic. Your connection to the login page is encrypted end to end, so the network cannot read your code out of it. The thing that actually takes your code is the page you were sent to, and it works exactly as well on your home broadband. Fixing the network fixes nothing; fixing how you arrive at login pages fixes a lot.

Where KeyNesta fits, and where it does not

KeyNesta is a TOTP and HOTP authenticator, and on this page the limits are the more useful half.

It ships no passkeys and no security keys. The features page names that among what is not built, and this is the one page on this site where that matters most. For the one or two accounts where a real-time phishing proxy would be a disaster, the honest recommendation is the one CISA makes: a hardware security key or a passkey, which no authenticator app can substitute for. Buying one is not a criticism of your authenticator. It is the correct answer to route 3, and we would rather say so than imply otherwise.

It cannot help with a stolen session cookie. Nothing in an authenticator is consulted during that attack. The defence is on the device and in the account's session list, not in the code generator.

It cannot protect the recovery chain. The route an attacker takes through a recovery email, a reset link or a support agent never reaches the app at all.

What it does close is the category it is for. Codes are computed locally from the secret and the device clock, so there is no account to breach, no code in transit to intercept, and nothing reported anywhere; the app works with the network off entirely. SIM swapping and SS7 do not apply to a code that was never sent to you. And because entries live in spaces and groups with real search across issuer, account and tags, the practical failure of "I have 2FA on some things, I think" gets easier to audit — which is most of what the checklists above are asking you to do.

Sync is end-to-end encrypted and zero-knowledge, which is its own trade: the server holds ciphertext and no key that opens it, so a forgotten passphrase is not a support ticket. What zero-knowledge costs you is the long version, 2FA backup and sync is how you avoid needing it, and the web app at app.keynesta.com needs no sign-up if you want to look first.

Takeaway

2FA can be bypassed, and almost never by attacking the code. It is bypassed by walking around it: through the recovery chain that was built to work when your phone does not, through a session cookie taken after you logged in, through a proxy that relays your six digits in real time, through a phone number you left in a recovery slot, or through a sheet of codes filed next to the password.

An authenticator app closes a genuine and large category — everything that only ever had your password, and everything that depended on reading a text message. It does not close the three routes that most often take individual accounts. So spend tonight on the list rather than on the app: read your recovery email and phone on your primary mailbox, sign out of sessions you do not recognise and change that password, find your backup codes, and put a security key on the one or two accounts you could not afford to lose. None of that takes an hour, and it moves far more than switching authenticators ever will.