WordPress Passkey Login: Set Up Passwordless Admin Access

Password-only login on wp-admin is the single weakest point on most WordPress sites we support — it's the thing brute-force bots hammer 24/7 and the thing a phishing email is usually trying to steal. Passkeys fix that by swapping "something you type" for "something you already have unlocked" — your laptop's fingerprint reader, Windows Hello, or your phone's Face ID. Here's how to actually turn it on for a WordPress site, what breaks along the way, and how to avoid locking yourself out.

What a passkey actually replaces

A passkey is built on WebAuthn, the same browser standard behind hardware security keys like YubiKeys. Instead of a password that can be guessed, reused, or phished, your device generates a cryptographic key pair: the private half never leaves your device (or its secure enclave), and the public half sits in your WordPress database. Logging in means your device proves it holds the private key — usually with a fingerprint, face scan, or device PIN — and WordPress never sees anything that could be stolen from a database dump or a fake login page.

That last part matters more than the convenience. A leaked password can be reused elsewhere or replayed on your site. A leaked public key is useless on its own.

Before you start

Three things need to be true, or the setup will fail partway through:

• Your site must be on HTTPS. WebAuthn simply won't run over plain HTTP — this isn't a WordPress restriction, it's baked into the browser API. If AutoSSL isn't active yet, sort that out first.
• WordPress 6.4 or newer, PHP 7.4+. Older installs are missing APIs the passkey plugins rely on for credential storage.
• A device with a platform authenticator. Windows Hello, Touch ID/Face ID on Mac and iOS, or Android's fingerprint unlock all work. A device with no biometric or PIN lock can still use a physical security key instead.

Setting it up

WordPress doesn't ship passkey support natively, so you're adding it through a plugin. Two solid free options as of 2026:

• WP 2FA — already common for TOTP-based two-factor, and its "Security Key / WebAuthn" method doubles as passkey support.
• Passkeys for WordPress style plugins built specifically around the WebAuthn API — lighter weight if you don't need TOTP at all.

The setup flow is nearly identical either way:

1. Install and activate the plugin from Plugins > Add New.
2. Log in with your existing password first — you need an active session to register a new credential.
3. Go to the plugin's settings (usually under Users > Your Profile or a dedicated menu item) and choose Add Passkey / Register Security Key.
4. Your browser prompts for a device authenticator — fingerprint, face scan, or PIN. Confirm it, and the public key gets stored against your WordPress user.
5. Log out completely and log back in to confirm the passkey prompt appears and actually works before you rely on it.

Give the passkey a recognizable name if the plugin asks — "MacBook Touch ID" or "Work Laptop Windows Hello" — because most plugins let you register more than one, and you'll want to tell them apart when one gets revoked later.

Rolling it out to every admin, not just you

Securing your own login and leaving every other editor and admin on a plain password defeats most of the point. In WP 2FA, the Policies tab lets you require a second factor (including WebAuthn) by role, with a grace period so nobody gets locked out mid-shift. Set the grace period to a day or two, not a week — the longer it sits, the more likely someone ignores the reminder entirely.

What goes wrong (and the fix)

Symptom: the "register passkey" button does nothing, or errors silently

Cause: almost always a mixed-content issue — the site is technically on HTTPS, but some assets or the admin AJAX call are still loading over HTTP, and the browser blocks the WebAuthn call as a security precaution.

Fix: open your browser console (F12) on the registration page and look for a mixed-content warning. Update WP_HOME and WP_SITEURL in wp-config.php to the full https:// URL, then run a search-replace for any hardcoded http:// references left in the database from before SSL was installed:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid

Symptom: passkey works on one browser but not another on the same device

Cause: passkeys are usually tied to the platform's credential manager (iCloud Keychain, Windows Hello, Google Password Manager), not the browser itself, and not every browser talks to every platform manager the same way.

Fix: register a separate passkey from each browser you actually use for admin work, or standardize on one browser for wp-admin. This isn't a bug to chase — it's how the underlying platform APIs are designed.

Symptom: locked out after losing the device the passkey was on

Cause: the private key lived only on that device's secure hardware — there's no server-side copy to recover, by design.

Fix: this is exactly why you keep a password-based fallback admin account or recovery codes generated at setup. If you skipped that step, you'll need database-level access: connect via phpMyAdmin or SSH and remove the plugin's stored credential row for your user (check the plugin's documentation for the exact table/meta key — WP 2FA stores it under user meta prefixed wp_2fa_), which drops you back to password-only login so you can get back in and re-register.

Symptom: "this browser doesn't support passkeys" on an old but still-used device

Cause: WebAuthn platform authenticator support needs a reasonably current OS and browser — think the last 3-4 years, not ancient hardware.

Fix: fall back to a physical FIDO2 security key on that device instead of a platform authenticator — most passkey plugins accept both, and a USB key doesn't care what OS version you're running.

Passkeys vs. TOTP 2FA: do you need both?

TOTP codes can still be phished by a convincing fake login page — the visitor types the code into the attacker's site instead of yours. A passkey can't be phished this way at all, because the cryptographic exchange is bound to the actual domain; it simply won't respond to a look-alike site. If you're securing an agency's shared admin logins or anything handling customer payment data, passkeys are worth the small setup cost over TOTP alone.

Prevention checklist

• Register at least two passkeys per admin (primary device + backup), or keep recovery codes somewhere outside the site itself.
• Confirm HTTPS is fully clean — no mixed content — before rolling this out account-wide.
• Keep one emergency password-only admin account with a long, unique, password-manager-generated password, used only for recovery.
• Document which plugin stores the credentials, so a future you (or a teammate) isn't guessing at 2 a.m. during a lockout.