I have been thinking about logins differently this year because passkeys are starting to move from a security conversation into a product conversation. Passwordless sign-in has been discussed for years, but it has often felt slightly out of reach for ordinary websites. The announcement from Apple, Google and Microsoft earlier this year made it feel more practical, and Chrome adding stable passkey support has made it harder to ignore.
The interesting part for me is not just security. It is the experience of signing in. Most users do not enjoy passwords. They reuse them, forget them, save them in browsers, reset them repeatedly and occasionally abandon a task because the login process becomes too much effort. If passkeys can reduce some of that friction, they could change how account-based websites feel day to day.
Why Passwords Create Operational Problems
Passwords look simple from a form design point of view. Email, password, submit. In practice, they create a lot of hidden work. Users need password reset flows, support teams deal with access issues and developers have to think about storage, brute force protection, two-factor authentication and all the small details around account security.
None of that disappears immediately with passkeys, and I would be careful about pretending the transition will be simple. Existing users still need familiar sign-in routes. Devices, browsers and operating systems need support. Businesses need to understand what happens when someone loses a device or needs to sign in from somewhere unexpected. The point is not that passwords vanish overnight. The point is that the default login experience may finally start to change.
The UX Part Matters
A login screen is often treated as a technical gateway, but it is part of the user experience. If someone cannot access their account easily, nothing else on the website matters. A well-designed dashboard, booking system or account area is useless if the sign-in process creates anxiety or confusion before the person gets there.
Passkeys are interesting because they align with behaviour people already understand on their devices. Unlocking with a fingerprint, face scan or device PIN is already normal for many users. The idea that a website login could use a similar flow is much easier to explain than a complicated password policy that asks for symbols, numbers and a phrase nobody will remember.
That does not mean the interface can be careless. The user still needs to understand what they are creating, where it will work and how they can recover access. Good copy and clear fallback routes will matter just as much as the underlying authentication standard.
Where I Would Start On A Client Project
In 2022, I would not remove passwords from a normal client project without a very careful plan. I would start by understanding the audience and the account behaviour. Are users signing in daily, weekly or only once every few months? Are they mostly on mobile devices? Do they already struggle with password resets? Those answers matter because authentication is not just a feature, it is part of how the business supports its customers.
For an internal tool or a modern application with a technically comfortable user base, passkeys may become interesting sooner. For a public consumer site, I would likely introduce them as an option rather than the only route. That gives early adopters a better experience without locking everyone else out of the process they already understand.
Retrospective Thoughts
The reason I find passkeys interesting is that they connect security and usability in a way passwords rarely do. A stronger login method that also feels easier for the user is worth paying attention to. That combination does not happen often.
I do think the next few years will involve a lot of education and mixed support. Websites will need fallback routes, clear messaging and careful account recovery decisions. Even so, 2022 feels like the year this stopped being a distant idea and started becoming something developers and product teams should understand properly.