Earlier this year we wrote about the password habits we recommend to every client team. This is the companion piece, about the direction that is making many of those habits unnecessary. Passkeys, the passwordless login standard built into every modern phone, laptop and browser, crossed into the mainstream in 2026. Roughly half of the hundred largest websites now offer them, billions are in active use, and most people have already used one without knowing the name. This article explains what passkeys are, why they matter more for the people who edit your website than for the people who visit it, and how we approach editor logins today.
What a passkey is
A passkey is a pair of cryptographic keys. One half stays on your device, protected by the fingerprint, face or PIN you already use to unlock it. The other half is stored by the website. When you log in, the site sends a challenge, your device signs it with the private half, and the site checks the signature with the public half. Nothing secret ever travels over the network, and nothing stored on the website can be used to log in from anywhere else.
The consequences are what make passkeys interesting. There is no password to forget, reuse or type into a fake login page. A passkey is bound to the website it was created for, so a convincing lookalike site gets nothing. A leaked database of public keys is useless to an attacker. And logging in takes one touch instead of a password and a code from a second app.
Why editors first
For most business websites, visitors do not log in at all, or only occasionally to a customer area. Editors and administrators log in every day, and their accounts can change content, configuration and other people's access. Those accounts are where account-based risk concentrates, and where the convenience of a passkey is felt most. A content team that logs in dozens of times a week gains a small pleasure each time, and the organization gains an account that cannot be phished. That is the rare security improvement people ask for rather than tolerate.
The same logic applies to two-factor authentication, which we already require for every account that can change a site. Passkeys are, in effect, two factors in one gesture: something you have, the device, and something you are or know, the biometric or PIN that unlocks it. For teams that find authenticator apps a chore, a passkey is the upgrade that makes strong authentication feel effortless.
How Drupal supports it
Passkeys are built on the WebAuthn standard, and Drupal supports it through contributed modules that integrate with the platform's login and two-factor systems. A user registers a passkey from their account page, the way they would enroll an authenticator app, and from then on can log in with it. Recovery paths, such as a second passkey on another device or a fallback to the existing two-factor method, are configured by policy so nobody is locked out by a lost phone.
We roll passkeys out to editorial teams in stages. First, alongside existing logins, so people can enroll at their own pace. Then as the recommended method, with the account page nudging anyone who has not enrolled. Finally, where a team is ready, as the required method for administrative roles, with passwords retained only for recovery. Each stage is a configuration change, reviewed and exported like any other, and it can be paused at any point.
What about visitors
For sites with a customer area, member section or portal, passkeys are becoming an expected option rather than a novelty. People have them for their bank, their email and their shopping accounts, and they are starting to look for the same button elsewhere. The implementation is the same as for editors; the difference is in the design. Visitors need a clear explanation at enrollment, a visible fallback, and a login screen that offers the passkey first without hiding the alternatives. We treat this as a user experience project as much as a security one, and we measure how many people enroll and how many succeed on the first attempt.
What stays the same
Passkeys change how people prove who they are. They do not change what happens after. Roles and permissions still decide what an account can do. Former staff still lose access on their last day. Login attempts are still limited and logged. Administrative sessions still expire. The account habits we recommended earlier this year remain the habits we recommend; the password itself simply stops being the weakest link in most of them.
Nor do passkeys replace the other layers. A site with perfect authentication and an outdated module is still a site with an outdated module. Authentication is one part of a deeper set of protections, and it works best when the rest are in place too.
Where to start
If your editorial team logs in with passwords and an authenticator app, passkeys are a natural next step and an easy one to trial. Enroll two or three people, live with it for a month, and see whether anyone wants to go back. In our experience nobody does. For sites we maintain, we are offering this as part of the regular maintenance conversation, and if you would like to try it sooner, let us know. It is a small change that removes a large category of worry.