Text Code, Authenticator App or Passkey? What the Rules Now Treat as the Weakest Link

The second factor most people chose, whenever they first chose one, was a text message to a cell phone, because it was the option the bank offered and it required nothing to be installed. That choice is still allowed almost everywhere, and it still defeats the plain password-stuffing attack that drains accounts in bulk. What changed is that the written standards stopped treating every second factor as interchangeable, and started naming some of them as tolerated rather than recommended. The ranking is public, it is specific, and it has filtered down into insurance questionnaires, payment rules and employer policy over the last few years.

The document that does the ranking, and what it actually ranks

The National Institute of Standards and Technology is responsible for the federal digital identity guidelines, the series that federal agencies and their contractors work to and that a great many private companies copy because it is the nearest thing to a neutral reference. Its authentication volume sorts login methods into assurance levels rather than into good and bad, which is why summaries of it so often go wrong. The useful move it made was to create a category for authenticators that are permitted but considered to carry extra risk, to require that a user be told about that risk, and to require that a stronger alternative be offered alongside.

That category is where codes sent over the phone network landed. Nothing was banned, nothing was switched off overnight, and no agency sent anybody a letter. The guidance simply stopped describing a texted code as equivalent to a device-held secret, and asked the parties relying on it to plan for the day they migrate away. Read in that light, the shift is less a verdict on text messages than a statement about what a standards body will still certify as adequate when something better is cheap, widely supported and already in most pockets.

Text codes, and the attack that moved them down the list

The weakness in a texted code is not the code. It is the assumption that the number belongs to the person it belonged to yesterday. Port-out fraud and SIM swap both work by persuading a carrier, or a retail employee, to move a number to an attacker's device, after which every reset link and every one-time code follows it. Carriers have tightened port authorization under federal pressure, adding account PINs and freeze options, and those controls work when they are turned on. Most are opt-in, and a household that has never visited that settings page has not turned them on.

Anyone quoting you a single number for how often this happens is guessing. The reported counts come from complaint databases that undercount by design, since victims often file with a carrier, a bank and a police department and never with the agency doing the tallying, and the figures that circulate range widely depending on which of those sources was used. The honest version is that it is rare per account and routine in aggregate, concentrated on targets with crypto holdings or visible wealth. The practical version is simpler: a texted code is a real improvement over a password alone, and it is the weakest of the options still worth having.

Authenticator apps and push prompts: better, with one known seam

A time-based code generated in an app removes the carrier from the picture entirely, which is most of the gain. The seam that remains is that the setup process hands the same seed to your phone and to the company's server, so a breach on their side can expose the material that generates your codes, and a convincing fake login page can collect a live code and replay it within its window. Push approvals close the typing problem and open a behavioral one, the prompt storm at two in the morning that a tired person eventually taps to make it stop.

Vendors answered that with number matching, which puts a two-digit figure on the login screen that has to be entered into the phone, converting a reflex into a deliberate act. It helps, and it is now the default in most major enterprise platforms rather than an option an administrator has to find. Judged against the standards, an app-based code or a matched push sits comfortably at the middle assurance level, suits almost every consumer account, and costs nothing beyond the few minutes it takes to scan a square and write down the recovery codes somewhere that is not the phone.

Passkeys and hardware keys, where the protection is structural

A passkey is a key pair rather than a secret you can read aloud, and the part that matters is that it is bound to the site's domain at the moment it is created. A lookalike page cannot ask for it, because the browser will not offer a credential registered to the real domain to a different one. That is a different kind of defense from a longer code or a shorter window: it does not depend on the user noticing anything. Hardware keys on a USB or tap interface work the same way with the private key sealed in a chip that will not export it.

The comparison between the two comes down to synchronization. A synced passkey lives in a platform or password manager account and follows you to a new phone, which solves the loss problem and makes that account the thing an attacker now wants. A device-bound key does not sync, survives any cloud compromise, and leaves you needing a second key in a drawer. Either way the recovery path becomes the real measure of the account, and the account worth hardening first is the email address every other reset link is sent to.

Where these rules reach an ordinary account

Compliance pressure is what moves the market, and it has been moving. The payment card industry's current standard raised the minimum length for accounts handling card data into the low teens, up from the eight characters that most legacy systems inherited from constraints nobody has had to live with since the nineties, and it pushed multifactor authentication onto far more administrative access than before. Cyber insurance applications now ask which factor you use and price the answer. Employers have quietly replaced the ninety-day reset with length rules and screening against known breached password lists.

The direction across all of them is the same, and it is worth stating plainly because the old habits were so thoroughly taught: length and uniqueness now carry the weight that complexity and rotation used to carry, and the second factor is expected to be something a convincing fake page cannot ask for. Both changes made the user's job easier rather than harder, which is unusual in security and partly explains why adoption moved as fast as it did once the big platforms shipped passkey support in their default browsers and phones.

If you are picking one upgrade this month, change the second factor on the email account that receives everybody else's password resets, and leave the texted codes in place on the accounts you have not gotten to yet. Nothing about the current guidance asks you to rip out what works. It asks you to put the strongest available method on the account that unlocks the rest, and to know, when you keep a weaker one, exactly which assumption you are relying on.