SMS Login Is Fading: How to Move to Passkeys the Right Way

SMS-based login codes are being phased out because they can be intercepted, phished, or redirected through a SIM swap, and attackers have gotten good at exploiting exactly that. The fix isn't "add more MFA." It's moving to passkeys, which remove the shared secret an attacker can steal in the first place. You don't need a big-bang migration to start; you can begin a phased passkey rollout this week.

Why SMS-based MFA is losing trust

SMS one-time codes were a real improvement over passwords alone, and they're still better than nothing. But the threat model has caught up with them. Three well-known weaknesses drive the shift away from SMS:

• SIM swapping. An attacker convinces (or bribes, or social-engineers) a mobile carrier to port a victim's number to a new SIM. Every SMS code now lands in the attacker's phone.

• Real-time phishing kits. Modern phishing pages don't just steal a password. They relay the SMS code you type in, live, straight to the attacker's session. The code being "one-time" doesn't help if it's stolen the moment it's used.

• No cryptographic binding. An SMS code is just a string of digits. It doesn't know or care which website you typed it into, which is exactly why it can be phished.

This is also why guidance from bodies like NIST has, for years, steered organizations away from SMS as the primary authentication factor and toward stronger, phishing-resistant options. Passkeys (built on the FIDO2/WebAuthn standard) are the practical answer: the credential is a cryptographic key pair tied to the specific website or app, so there's no code to steal, redirect, or trick someone into typing into the wrong place.

The business "so what"

For a CISO or owner, the real cost of SMS-based MFA isn't the occasional SIM-swap headline. It's account takeover of email, finance, or admin accounts that quietly leads to fraud, data exposure, or a foothold for a bigger incident. Moving high-value accounts to passkeys is one of the more effective, low-friction security upgrades available right now.

What "phishing-resistant" actually means (and why passkeys qualify)

Phishing-resistant doesn't mean harder to phish. It means the login can't be phished at all, because there's nothing for the user to be tricked into revealing. With a passkey:

• The private key never leaves the user's device (phone, laptop, or security key).

• The browser or OS checks that the site requesting login is the real one before it will respond. A fake lookalike domain simply won't work.

• Login is a biometric tap or PIN unlock, not a code you copy and paste anywhere.

App-based authenticator codes (TOTP) are a step up from SMS but are still phishable the same way SMS is; a fake page can still relay the code. If you're choosing where to invest first, prioritize passkeys over simply swapping SMS for an authenticator app.

How to start a passkey rollout this week

You don't need every system passkey-ready on day one. Use this sequence to get moving without breaking anything:

• Step 1: Inventory your highest-value logins. Email/identity provider, cloud console, finance and payroll tools, code repositories, and any admin panels. These are your first targets, not your entire user base.

• Step 2: Turn on passkeys as an option, not a mandate. Most major identity providers, cloud platforms, and password managers already support passkeys. Enable it alongside existing MFA rather than removing SMS immediately.

• Step 3: Migrate admins and finance first. These are the accounts attackers target hardest. If your identity provider supports it, make passkeys mandatory for privileged roles before rolling out company-wide.

• Step 4: Keep one fallback, not three. A common mistake is leaving SMS, authenticator apps, and passkeys all active as equal options, which just hands an attacker the weakest one to target. Keep a single, phishing-resistant fallback (a hardware security key, for example) for account recovery, and retire SMS as an active MFA method once each user has enrolled a passkey.

• Step 5: Set a decision rule for the rest of the org. A simple threshold: any account with admin rights, financial access, or access to customer data moves to passkeys within your next patch/access-review cycle; everyone else moves on your normal rollout timeline.

What if not everything supports passkeys yet?

This is the honest objection, and it's a fair one. Not every legacy app, VPN client, or older device supports passkeys today. When that's the case:

• Don't wait for 100% coverage before starting. Roll out passkeys everywhere they're supported now, and leave app-based MFA (not SMS) as the interim method for systems that lag.

• Flag unsupported critical systems as a specific to-do for your IT or vendor roadmap, rather than a reason to delay the whole initiative.

• If you don't have in-house resource to manage a phased identity rollout alongside everything else on your plate, that's a reasonable gap to bring in outside help for. This is exactly the kind of prioritization work a virtual CISO or managed security partner can own end-to-end, rather than it sitting on a to-do list indefinitely.

Start with a clear-eyed view of where you stand

The fastest way to know which accounts are most exposed to SMS-based attacks, and where to start your passkey rollout first, is an outside look at your current setup. Sheer Safe offers a free security review to help you see exactly that, with no pressure and no sales pitch attached.