Two-factor authentication via SMS or TOTP has been the WordPress security baseline for years. Both have been catching up to attackers, and both have known weaknesses — SIM swaps for SMS, phishable codes for TOTP. Passkeys (WebAuthn) sidestep both classes of attack. For WordPress sites with editorial accounts that have real privilege, they're now the right answer.
The standard WordPress account security posture in 2024 looks roughly like: enforce strong passwords, require 2FA via TOTP, hope for the best. That’s been adequate for most sites for most of the last decade. The threat model has moved. Two-factor authentication via SMS and TOTP still raises the floor, an attacker with just a password can’t get in, but both have known weaknesses that real attackers are exploiting. Passkeys close the gap.
What’s wrong with SMS and TOTP.
Both forms of 2FA had a good run. Both are now patchable around:
- SMS 2FA is vulnerable to SIM swapping — an attacker convinces a mobile carrier to port the victim’s number to a new SIM, then receives the 2FA codes. This isn’t a theoretical attack; it’s executed at scale, particularly against high-value targets (crypto, finance, executives). For any account that an attacker would specifically target, SMS 2FA is no longer reliable.
- TOTP 2FA (Google Authenticator, Authy, 1Password’s built-in TOTP) is phishable. A modern phishing kit shows a fake WordPress login page, captures the username, password, AND the current TOTP code, then logs in to the real site within the 30-second validity window. The code did its job — it just got fed into the wrong site by a user who didn’t notice. This is now the dominant pattern for account compromise against accounts protected only by TOTP.
Neither attack is novel. Both are common enough that account-takeover statistics for accounts “protected” by SMS or TOTP are no better than they were five years ago.
What passkeys do differently.
A passkey is a cryptographic credential bound to a specific domain. When you create a passkey for example.com, the browser stores a private key that can only sign challenges from example.com. A phishing site at example-login.com can’t trigger the passkey, because the browser checks the domain. The user can’t accidentally hand over their credential by typing it into the wrong page, because there’s nothing to type.
This eliminates the two attacks above:
- SIM swap doesn’t help — the credential isn’t tied to a phone number; it’s tied to a device.
- Phishing doesn’t help — the browser refuses to authenticate against the wrong domain. The credential never leaves the device for the attacker to capture.
Passkeys also remove user friction. No code to type, no app to open, no SMS to wait for. Touch ID, Face ID, Windows Hello — the user proves they have the device, the browser does the cryptography, login completes. For editorial teams that log in to WordPress multiple times a day, this is meaningfully faster than the 2FA flow.
How to deploy passkeys on WordPress.
The state of WordPress passkey support as of mid-2024:
- Core has Application Passwords but not WebAuthn yet. There’s no built-in passkey support in WordPress core. Talk is happening in the project; nothing has shipped.
- Plugins exist. Several plugins implement WebAuthn for WordPress login: some standalone, some as part of broader security suites. The maturity varies. For production use, evaluate carefully: the plugin you choose handles your authentication, so plugin quality matters more here than for most categories.
- Some hosting providers offer passkey login for the host dashboard. That covers the path to your hosting account, not to the WordPress admin itself. Both matter; they’re separate.
What to require, and when.
A staged rollout that fits most WordPress operations:
- Today, for administrators: Require passkey OR strong-password + TOTP. Make passkey the recommended path. Some users will have devices that don’t support WebAuthn (rare in 2024); TOTP remains a fallback for them.
- Today, for editors: Same baseline as administrators. The risk profile is different but not by enough to relax the requirement — an editor who can publish content can also push malicious content.
- Phase out SMS 2FA entirely. If your site allows it as an option, remove it. Users who set up SMS as their second factor years ago should be moved to TOTP or passkey on their next login.
- For service accounts and automation, use Application Passwords or similar, scoped narrowly. These are different credentials than human-user passkeys and need their own management.
What this costs.
The biggest cost is user education. Passkeys are still new enough that some users will be confused on first encounter — “why isn’t there a code to enter?” A one-page guide and a five-minute walk-through during the initial rollout solves it. After that, every login is faster than it used to be.
The implementation cost on the WordPress side is modest: a vetted plugin, configuration of which roles are required to use passkeys, a fallback policy for the small number of users on devices that don’t support WebAuthn. For sites where account takeover would be a real incident — e-commerce, agencies handling client sites, anything with audience trust on the line — the gap between the cost of deployment and the cost of a compromise is wide. See security hardening for the rest of the modern baseline.