Security Keys and Passkeys: Why SMS 2FA Is Failing Modern Authentication
Updated: 22 hours ago
For some of the world's largest enterprises, the challenge is beyond understanding the security limitations of SMS-based two-factor authentication. It is overcoming the fear that stronger authentication will introduce friction into the customer experience. Yet as phishing, SIM-swapping, and identity-based attacks continue to threaten digital trust, security keys and passkeys offer a more phishing-resistant path forward.
The question for business leaders, besides whether stronger authentication creates friction is: How much risk are we willing to accept to avoid it?
A password plus a text message once felt like a strong defense. It is no longer enough for high-value accounts, executive access, finance systems, customer data, or privileged administration. Attackers have learned how to steal passwords at scale, intercept verification codes, trick employees into approving sign-ins, and exploit account recovery processes that still rely on mobile numbers.
Modern authentication needs to be harder to phish, harder to replay, and easier for legitimate users to adopt. That is where security keys and passkeys change the conversation. They strengthen identity controls without forcing people to memorize more complex passwords or wait for one-time codes that can be stolen.
SMS 2FA creates risk that modern attackers know how to exploit
SMS two-factor authentication is better than using a password alone. For many consumers, it helped normalize the idea that a password should not be the only gate. The problem is that SMS was never designed to be a secure identity channel.
Text messages depend on the phone network, mobile account controls, and the assumption that the person holding the phone number is the right person. Attackers can challenge that assumption in several ways.
Common SMS 2FA risks include:
SIM swapping
An attacker convinces a mobile carrier to transfer a victim’s number to another SIM or device. Once that happens, verification texts go to the attacker.
Phishing proxy attacks
A fake sign-in page captures the username, password, and SMS code in real time, then uses them before the code expires.
Social engineering of help desks and carriers
Attackers target account recovery workflows because recovery is often weaker than sign-in.
Message interception and malware
Compromised devices, malicious apps, and weak mobile account protections can expose codes.
Poor coverage and delivery problems
SMS can fail when employees travel, change numbers, lose devices, or work in areas with limited service.
For corporate risk management, the central issue is not that SMS always fails. The issue is that SMS creates a reusable, human-readable secret during sign-in. If a person can read and type a code, a phishing site can ask for it, steal it, and use it.
That weakness matters most for executives, finance teams, IT administrators, legal staff, HR systems, and anyone with access to sensitive data or approval authority. Those accounts need authentication that resists phishing by design.
Security keys and passkeys raise the bar for identity protection
Security keys and passkeys are built around public key cryptography. The private key stays on the user’s device or hardware key. The service receives only a public key. During sign-in, the service asks the authenticator to prove possession of the private key.
That proof is tied to the legitimate website or application. A fake site cannot easily trick the authenticator into signing in to the real one because the domain does not match. This is the core security advantage.
Security keys are usually physical devices, such as USB, NFC, or Bluetooth authenticators. Passkeys are a newer sign-in method based on the same broad standards, commonly stored on a phone, computer, hardware key, or password manager. Passkeys may sync across a user’s trusted devices or remain bound to one device, depending on how they are created and managed.
The practical benefits are significant:
Traditional passwords and SMS | Security keys and passkeys |
Users type secrets into web pages | Users prove possession without revealing the private key |
Codes can be phished in real time | Sign-ins are bound to the legitimate site or app |
Password reuse creates broad exposure | Each site or app has a separate cryptographic credential |
Mobile numbers become identity anchors | Devices and authenticators become the proof |
Help desk resets can become attack paths | Recovery can require stronger checks and backup authenticators |
This is why many security programs now prioritize phishing-resistant authentication for sensitive roles. It directly supports stronger authentication, identity and access controls because it improves assurance at the point where users prove who they are.
The gain is not just technical. It reduces friction in important ways. A passkey sign-in can be faster than a password. A hardware key can be simple for privileged users who need a clear, physical control. Both reduce dependence on memorized secrets and fragile phone-number recovery.
For leaders, the business case usually falls into four areas:
Fewer successful phishing attacks
Lower risk from stolen credentials
Better protection for privileged access
A clearer path toward passwordless sign-in for critical systems
A practical rollout plan starts with risk, not technology
The right implementation plan should fit the organization’s risk profile. A small business, a household, and a regulated enterprise will not follow the same path. One approach is to start with the accounts that can cause the most damage if compromised.
Personal accounts should start with the highest impact services
For individuals and families, the first priority is protecting accounts that control money, identity, communication, and recovery.
Start with:
Primary personal email
Financial accounts that support passkeys or security keys
Password manager account
Cloud storage accounts
Mobile carrier account
Social and messaging accounts used for recovery or public presence
A simple personal setup can work well:
Create passkeys where supported for major accounts.
Add at least one hardware security key for the email account and password manager.
Register a backup security key and store it somewhere safe.
Remove SMS and/or email as default second factors if stronger options are available.
Review biometric authentication recovery options and backup codes.
Use a password manager for accounts that still require passwords.
This does not need to happen in one weekend. Start with the email account. If an attacker controls email, they can often reset other accounts.
Business rollouts should protect privileged and exposed users first
For businesses, the rollout should begin with clear tiers. Start where account takeover would create the greatest operational, legal, or financial harm.
High-priority groups include:
Executives and executive assistants
IT administrators and security staff
Finance and payroll teams
HR and legal teams
Developers with production or source code access
Users with access to customer or regulated data
Employees frequently targeted by phishing
A workable enterprise plan usually includes these steps:
Inventory critical applications
Identify identity providers, email platforms, VPN or zero trust access tools, cloud consoles, financial systems, code repositories, HR platforms, and administrative portals.
Confirm support for FIDO2, WebAuthn, or passkeys
Most modern identity platforms support phishing-resistant authentication in some form. Some legacy applications may require federation through a central identity provider.
Set authentication policies by risk
Require phishing-resistant methods for administrators and sensitive roles. Allow lower-assurance methods only where business risk supports them.
Issue at least two authenticators for critical users
A single key creates a single point of failure. Provide a primary and backup key, or a managed passkey plus a hardware backup.
Create secure recovery procedures
Require verified identity checks, manager approval for sensitive roles, audit logs, and a waiting period for high-risk resets when appropriate.
Pilot before broad deployment
Test with a cross-section of users and devices. Include travel scenarios, shared workstations, mobile access, and users with accessibility needs.
Measure adoption and exceptions
Track who has enrolled, which methods they use, where SMS remains enabled, and which systems still need migration.
Security keys and passkeys work best when they are part of a broader identity governance program. Access should still follow least privilege. Admin rights should be separate from daily user accounts. Session duration, device posture, and conditional access should match the sensitivity of the resource.
Password managers still matter because passwords are not disappearing overnight
Passkeys reduce the need for passwords, but they do not eliminate them across every system. Legacy applications, industry portals, vendor accounts, network devices, and niche software may continue to require passwords for years.
A password manager remains one of the most practical controls for this transition.
A strong password manager helps by:
Storing passkeys for ease of use
Generating long, unique passwords for every account
Preventing password reuse across business and personal services
Identifying weak, reused, or exposed passwords
Storing recovery codes and secure notes when policy allows
Supporting shared vaults for teams without sending passwords through chat or email
Helping users notice fake sites because autofill works best on the correct domain
For businesses, managed password managers also give security teams better policy control. They can require strong primary authentication, enforce vault sharing rules, remove access when employees leave, and monitor risky password behavior without needing to know the passwords themselves.
The password manager itself needs strong protection. Use a long primary password or approved enterprise single sign-on, require phishing-resistant MFA where available, and make sure recovery settings match the sensitivity of stored credentials.
For executive and administrator vaults, use extra care. Restrict shared items. Review emergency access. Separate personal and business credentials. A compromised vault can become a map to the organization.
The transition has challenges, but they are manageable
Authentication changes affect habits, support workflows, procurement, device management, and incident response. The technical control may be mature, but the rollout still needs careful planning.
Users may fear lockout
Lockout is the most common concern. It is also solvable.
Use backup authenticators, documented recovery steps, clear user education, and staged enforcement. For critical roles, issue two physical keys and require enrollment before enforcement begins. For passkeys, explain where the passkey is stored and what happens when a device is replaced.
Not every system supports passkeys yet
Some applications will not support modern authentication directly. Use a central identity provider where possible, place legacy systems behind stronger access controls, and plan replacements for applications that cannot meet security needs.
Where SMS cannot be removed right away, reduce reliance on it. Restrict SMS to lower-risk accounts, add monitoring, shorten the transition window, and strengthen recovery checks.
Device ecosystems can be confusing
Passkeys may sync through platform accounts or be stored in password managers or hardware authenticators. That flexibility is useful, but it can confuse users.
Set standards. Decide which passkey types are approved for business use. Clarify whether synced passkeys, device-bound passkeys, or hardware security keys are required for specific roles. Document the difference in plain language.
Procurement and logistics can slow adoption
Hardware keys require purchasing, distribution, inventory, and replacement plans. Large programs should define approved key models and connector types, such as USB-C and NFC. Keep spare keys available for onboarding, travel issues, and lost devices.
The cost of hardware keys is usually easier to justify when compared with the cost of account takeover, wire fraud, data exposure, and incident response.
Help desk processes can become the weak link
If the help desk can bypass strong authentication after a short phone call, attackers will target that process. Train support teams to treat reset requests as security events. Use identity proofing steps that match risk. Log every reset. Require escalation for executives, administrators, and finance roles.
The strongest sign-in method can be weakened by a weak recovery process. Authentication and recovery should be designed together.
What good looks like after adoption
A mature program does not only rely on controls. It layers stronger sign-in with access management, monitoring, and response.
A strong end state includes:
Phishing-resistant authentication for executives, administrators, and high-risk functions
Passkeys available for common business applications
Hardware security keys required for privileged access
SMS and/or email authentication methods disabled if stronger choices are supported
Password managers deployed for passkeys and remaining password-based accounts
Clear recovery workflows with audit trails
Regular reviews of access, exceptions, and inactive accounts
User training that explains the reason behind the change
This approach aligns with the direction of modern security guidance, including risk-based access control, least privilege, and stronger assurance for sensitive systems. It also gives the business a clear migration path. Passwords become fewer, weaker factors like SMS lose importance, and access decisions become easier to trust.
The most effective next step is simple: identify the accounts where takeover would cause the greatest damage, then require phishing-resistant authentication for those accounts first. Start with email, identity administration, finance, and executive access. Add password managers for the accounts that still need passwords. Build recovery with the same care as sign-in.
Passwords and SMS codes made sense when attackers were less organized and systems were less connected. That period has passed. Modern authentication should prove identity without handing attackers a code they can steal. Security keys and passkeys make that possible, and the organizations that adopt them now will be better prepared for the threats that already exist.
*See NIST SP 800-63 Digital Identity Guidelines. NIST offers detailed requirements for authentication types under SP 800 63B.
Comments