Passkeys for WordPress Login: Can You Use Them Yet?
You have probably been offered a passkey by now. Google, Apple, Amazon and your bank have all put up a prompt asking whether you want to sign in with your face or your fingerprint instead of typing a password.
So the natural question is whether you can do the same on your own WordPress site. The short answer: yes, but only with a plugin, and the plugin market for this is still young. Whether you should is a different question, and the answer depends on who logs into your site.
Here is the plain-English version of what a passkey is, what your real options are on WordPress today, and how to decide.
What a passkey actually is
A password is a secret you know. You type it in, the site checks it against what it has stored, and if they match you are in.
A passkey is a secret your device holds. When you create one, your phone or laptop generates a pair of matched keys. One stays locked on your device and never leaves it. The other is handed to the website.
When you log in, the site sends a puzzle that only the key on your device can solve. Your device asks you to confirm with your fingerprint, your face, or your screen lock PIN, solves the puzzle, and sends back the answer. The site checks the answer with the key it holds.
The important part: your fingerprint never goes to the website. It only unlocks the key sitting on your own phone. The website never receives anything that could be reused to log in as you somewhere else.
Why that matters more than it sounds
Three attacks stop working, and they happen to be the three that account for most hacked WordPress sites.
Password guessing stops working. Bots hammering your login page with common passwords have nothing to guess. There is no password to get right.
Reused password leaks stop mattering. If you used the same password on your WordPress site as on some forum that got breached in 2019, attackers will eventually try it. A passkey cannot be reused anywhere, because it is unique to your site and it was never a typed word in the first place.
Phishing stops working. This is the big one. A passkey is tied to the exact web address it was created for. If someone emails you a link to a fake login page at a lookalike domain, your device will simply not offer the passkey, because the address does not match. You cannot be tricked into handing it over, because there is nothing to hand over and your device is checking the address for you.
That last protection is something no amount of care can give you with a password. People who know better still get phished on a tired Tuesday afternoon. The passkey does not get tired.
This is not the same as two-factor
Worth being precise, because the two get muddled constantly.
Two-factor authentication adds a step to your password. You type your password, then you type a six digit code from an app. Two things, one after the other. If you have already set up two-factor authentication on WordPress, that is what you are running.
A passkey replaces the password. There is no password step and no code to type. The single action of unlocking your device does both jobs at once: it proves you have the device, and the fingerprint or PIN proves you are you.
So a passkey is not a third factor to bolt on. It is a different route to the same door. In practice most WordPress setups today run both side by side, with passkeys as a faster option and the password plus two-factor route still available as a fallback.
Side by side, the three approaches compare like this:
| Password only | Password + 2FA | Passkey | |
|---|---|---|---|
| Steps to log in | 1 | 2 | 1 |
| Something to remember | Yes | Yes | No |
| Survives a password leak | No | Yes | Yes |
| Stops guessing bots | No | Mostly | Yes |
| Stops phishing | No | No | Yes |
| Works on a borrowed computer | Yes | Yes | Awkward |
| Built into WordPress | Yes | Plugin | Plugin |
Note the phishing row. Two-factor helps far less there than people assume, because a convincing fake login page can ask for the six digit code too, and plenty of people type it in. The passkey is the only one of the three that closes that door.
Do you still need a password manager?
Yes, and this trips people up, so it is worth settling early.
Passkeys only work on sites that have implemented them. That is a growing list of large services and a very short list of everything else. Your hosting control panel, your domain registrar, your accountant’s portal and most of the small tools you use every week still want a password, and those accounts are exactly the ones an attacker would like.
Modern password managers store both. The same app holds your passwords for sites that need them and your passkeys for sites that support them, and it syncs both across your devices. For a lot of people that is the tidiest arrangement, because it keeps everything in one place rather than split between Apple, Google and a browser depending on where each item happened to be created.
So the honest framing is not that passkeys replace your password manager. They reduce how often you reach for it, and they remove the risk on the specific accounts that support them. The password manager stays, because the rest of the internet has not caught up.
Does WordPress support passkeys?
Not on its own. There is no passkey option in a default WordPress install, no setting in your profile, and nothing to switch on. If you want passkeys you install a plugin.
This is worth stating plainly because a lot of writing on this topic implies otherwise. WordPress core handles logins with a username and password, and every passkey capability comes from third party code.
Your actual options
Two shapes of solution, and the choice between them matters more than the choice within them.
Dedicated passkey plugins
These do one job. The most established is Secure Passkeys, at over 1,000 active installations. It supports fingerprint and face login plus hardware security keys, lets each user register more than one passkey, and works with the standard WordPress login form as well as WooCommerce, MemberPress, Easy Digital Downloads and Ultimate Member. It needs WordPress 6.0 or newer and PHP 7.4 or newer, which almost any current site will meet.
Two older options exist as well. WP-WebAuthn has around 2,000 installations, and WebAuthn Provider for Two Factor has around 1,000 and works as an add-on to the official Two Factor plugin rather than as a standalone login method.
Look at those numbers honestly. A thousand installs is a small plugin. For comparison, the caching and SEO plugins on your site probably have a million or more. That does not make these plugins bad, and it is normal for a young category, but it does mean fewer people have hit the bugs before you.
A security plugin you may already have
The larger security plugins have been adding passkey support as one feature among many. If you already run one, check its login settings before installing anything new.
This is the better route for most beginners, for a reason that has nothing to do with the passkey feature itself. It is one less plugin, one less thing to keep updated, one less vendor to trust with your login flow, and it is code maintained by a team with a large user base and a support queue. If your existing security plugin can do this, use it.
What setup looks like
The flow is much the same across plugins.
- Install and activate the plugin.
- Go to your own user profile. There will be a new section for passkeys or security keys.
- Click to add one. Your browser takes over and asks how you want to store it: this device, your phone, or a hardware key.
- Confirm with your fingerprint, face or device PIN.
- Give it a name you will recognise later, such as “work laptop”.
- Log out and log back in to confirm it works.
That last step is not optional. Test it in a private browsing window while still logged in somewhere else, so that if something is misconfigured you are not locked out of your own site with no way back in.
Then add a second passkey on a different device. If your only passkey lives on your phone and your phone goes in a river, a second one on your laptop is the difference between an inconvenience and a support ticket.
One requirement people miss
Passkeys need HTTPS. Your site has to be on https:// with a valid certificate, because browsers refuse to create or use a passkey on an insecure connection.
Nearly every host provides a free certificate now, so this is usually already true. If your site still shows “Not secure” in the address bar, fix that first. It is worth doing regardless of passkeys.
The other thing to know: a passkey is tied to your exact domain. If you later move the site to a different domain, existing passkeys stop working and everyone re-registers. Not a disaster, but worth knowing before a migration rather than during one.
What it looks like on each device
The experience differs a little depending on what you are holding, which matters if you are going to walk someone else through it.
iPhone, iPad and Mac
Passkeys live in iCloud Keychain and sync across everything signed into the same Apple account. Create one on your Mac and it appears on your iPhone. You confirm with Face ID or Touch ID. On a Mac without Touch ID you confirm with your login password, which feels like a step backwards but is doing something different underneath.
Android and Chrome
Passkeys go into Google Password Manager and sync to anywhere you are signed into that Google account. Confirmation is your fingerprint or screen lock. Chrome on a desktop can also use a passkey stored on your phone by showing a QR code, which you scan with the phone to approve the login. That flow surprises people the first time, so mention it in advance if you are supporting someone.
Windows
Windows Hello handles it with your face, fingerprint or PIN. Historically these stayed on the one machine rather than syncing, so on Windows especially it is worth registering a second passkey elsewhere.
Hardware security keys
A small USB or NFC device you plug in or tap. Nothing syncs and nothing is stored in anyone’s cloud, which makes it the strongest option and the least forgiving. Lose it without a backup and you are relying on your fallback login. People who look after high value accounts usually own two and keep the second somewhere safe.
You do not need to pick a lane. A plugin that supports multiple passkeys per user lets you register a phone, a laptop and a hardware key against the same account, and any of them will get you in.
“What if I lose my phone?”
This is the question everyone asks, and it deserves a straight answer rather than reassurance.
Most passkeys are not actually stuck on one device. They sync through whatever account you already use: iCloud Keychain on Apple devices, Google Password Manager on Android and Chrome, or a password manager if you use one. Get a new phone, sign into your account, and your passkeys come back with your photos and contacts.
Two exceptions. A physical security key, the USB kind, does not sync anywhere by design, which is the point of it. And a passkey created as device-bound stays on that device.
Either way the practical protection is the same, and it is the one thing to actually do:
- Register passkeys on at least two devices.
- Keep password login enabled for your admin account, with a long unique password stored in a password manager.
- Know how to reach your site’s files or database through your host, since that is the last resort for regaining admin access.
Resist the urge to turn off password login entirely the moment passkeys work. That switch is the one that locks people out. Leave the old route open for a few months until you are confident.
When something does not work
Four things go wrong regularly, and all four have dull explanations.
The button does nothing. Almost always HTTPS. Check the address bar shows a padlock and not a warning. On a local development site, browsers make an exception for localhost but not for a custom local domain, which catches developers out more than site owners.
The passkey is not offered at login. Usually the address does not match where it was registered. A passkey made on www.yoursite.com will not appear on yoursite.com, because as far as the browser is concerned those are different places. Pick one, make sure your site redirects to it consistently, and register there.
It works in one browser but not another. Passkeys are stored by the platform or the browser’s password manager, so one saved in Chrome under a Google account will not show up in Firefox on the same machine. This is expected. Register in whichever browser you actually use, or use a password manager that works across all of them.
A caching plugin gets in the way. Login pages should never be cached. If your login behaves oddly right after enabling passkeys, exclude the login page from caching and clear the cache before assuming the passkey plugin is at fault.
If you get properly stuck, deactivating the plugin restores normal password login. That is the reason to keep the password route alive while you are still testing.
What about your customers?
If you run a shop or a membership site, the question is not only about your own admin login. Some plugins extend passkeys to customer accounts on WooCommerce, MemberPress, Easy Digital Downloads and similar.
Tempting, and worth being careful about. Your customers did not ask for this, will not have read anything about it, and a login problem at checkout costs you a sale rather than five minutes.
A sensible order if you want to get there:
- Run it on your own admin account for a month.
- Extend it to staff or editors, who will tell you when it breaks.
- Offer it to customers as an option they can opt into, never as a replacement.
- Keep normal login working exactly as it does today, permanently.
Most plugins let you restrict the feature by user role, which is what makes that staged rollout possible. Use it. Turning passkeys on for administrators and editors only, and leaving customers untouched, is a reasonable permanent setting rather than a temporary step.
Who should do this now
Passkeys make clear sense in three situations.
You are the only person who logs in. One person, one or two devices, no support burden. Almost all upside, and you can undo it in a minute.
You have been targeted before. If your site has been hacked or you are getting a steady stream of login attempts, phishing resistance is worth real money to you.
You manage sites for clients. Your own admin accounts across many sites are a high value target, and you are technical enough to recover from a mistake.
Who should wait
Three situations where waiting is the better call, and none of them are about the technology being bad.
You have a lot of non-technical users. A membership site or a shop with hundreds of customers means hundreds of people who may not understand what the fingerprint prompt is asking. The support load lands on you.
Your users are on shared or old computers. A passkey assumes a personal device. In a library, an internet cafe or a shared office machine, that assumption does not hold.
You are already stretched. Adding a plugin that sits in the login path is not a small change. If you are not going to test it properly, do not add it. A strong password plus two-factor is a good place to sit, and it is not a failure to stay there.
If you decide to wait
Do these instead. They cost nothing and cover most of the same risk.
Use a unique password for your WordPress admin account, generated by a password manager and used nowhere else. This alone removes the reused password problem.
Turn on two-factor authentication for every account with an administrator role. Not just yours.
Review who actually has an administrator account. Most sites carry at least one from a developer or agency who finished the job a year ago. Remove or downgrade them.
Keep everything updated. An unpatched plugin is a far more common way in than a guessed password, and it is the thing that quietly matters most. If you are not sure whether your site has already been compromised, our guide on how to fix a hacked WordPress site walks through the signs and the cleanup.
The honest summary
Passkeys are a genuine improvement. The phishing resistance in particular solves a problem that user education has never solved and probably never will.
WordPress support is real but early. It requires a plugin, the dedicated plugins are small, and the safer route for most people is a passkey feature inside a security plugin they already run and already trust.
If you run your site alone, try it this week. Register two passkeys, keep password login on as a fallback, and enjoy logging in with your thumb.
One last thing worth saying plainly: a passkey on your admin account does nothing for an out of date plugin, a weak hosting password, or an old administrator account belonging to someone who left. Login security is one door among several, and it is rarely the one that gets used. Fix the boring things first and treat passkeys as an upgrade rather than a shield.
If you have a crowd of users who are not comfortable with technology, wait. This will land in core or in the plugins you already run eventually, with better recovery flows and better documentation than exists today. Nothing is lost by letting other people find the rough edges first.
Quick checklist
- Confirm your site is on HTTPS with a valid certificate.
- Check whether your existing security plugin already offers passkeys before installing a new one.
- Test the login in a private window before you trust it.
- Register passkeys on two devices, not one.
- Leave password login enabled as a fallback for at least a few months.
- Keep two-factor on your administrator accounts either way.
- Remember that changing domains invalidates every existing passkey.
- Do not roll this out to customers until you have run it on your own account for a while.
