A mouthful of a title but in this blog, I’ll try to answer this question based on my own understanding and experiences deploying WebAuthn.
Firstly, if you don’t know what Web Authentication is (commonly referred to as WebAuthn), it might be worth having a quick read of my previous blog post as the WebAuthn standard is the foundational building block for passkeys.
So, if passkeys are based off of the WebAuthn standard, what makes them special? A couple of things actually…
- Up until now, WebAuthn platform credentials were device bound. If you generate a WebAuthn credential on your phone, by design that credential will never leave the device (this isn’t a bad thing by the way; actually, it’s probably preferable to have the option in a secure enterprise setting which I’ll come on to later).
Passkeys change things up by synchronising these credentials with your cloud account (Apple ID, Microsoft account, Google account) therefore reducing the likelihood of being locked out of accounts due to a lost, stolen or damaged authenticator. - Another feature that helps enable passkeys across the ecosystem is the FIDO Cross Device Authentication flow that allows you to use a passkey on one device to sign in on another. For example, using a passkey on your Google Pixel to sign in to a website on Windows.
WebAuthn in the enterprise
When WebAuthn is deployed in the enterprise, typically it’s via the use of roaming authenticators (commonly Yubikeys), platform authenticators (TouchID/FaceID/Windows Hello) or a combination of both.
In my previous role, I deployed two Yubikeys to each member of staff; one for daily use and the other which would serve as a backup but also crucially, it provided a way to bootstrap access from the user’s iPhone/Android.
In my current role, I decided not to go down the path of roaming authenticators but instead rely on platform authenticators. They’re less costly (comes free with the laptop!) and provide a slightly better user experiencecccjgjgkhcbbirdrfdnlnghhfgrtnnlgedjlftrbdeut
To summarise, we get the following security benefits:
✅ Strong resistance to phishing attacks
✅ Strong guarantees that the user authenticating is the same person who set-up the keys. i.e., it is designed to be incredibly difficult, if not impossible to extract the credentials out of the authenticator. Therefore it is fair to say that when Mr. Wick logs in to an application, we have an extremely high confidence that it is indeed Mr. Wick.
Passkeys in the enterprise
The ability to bootstrap user authentication from another device is a killer feature and should help drive adoption. Widely used Identity Providers currently have no way of supporting platform authenticators on more than one device without falling back to weaker authentication (at the expense of a worse security and user experience).
As an Okta user my self – passkeys are a game changer. I no longer need to go through the painful process of adding users to temporary exception groups simply because they want to sign in to an application from their mobile device. Instead, I can include the bootstrap process of setting up WebAuthn on both laptop and phone in the onboarding guide.
Saying that, Apple has set a precedent that I fear Google and Microsoft will follow.
The Apple implementation of passkeys has removed the ability for WebAuthn credentials to be device bound. You have no choice but to synchronise them to your Apple ID account. The same Apple ID that is a common phishing target for criminals and the same Apple ID that cannot be protected with phish resistant MFA (actually SMS is always available as a fallback)
To summarise, this is where I stand on the matter:
✅ Passkeys could be used to bootstrap other devices so that staff can set-up strong user authentication on multiple devices. This is awesome and should help drive adoption because it should no longer be necessary to purchase hardware security keys
❌ We’ve gone from device bound, strong-guarantees-its-the-same-user credentials to your credentials must be synchronised to this user’s personal iCloud account which can be phished
Summary
We seem to be missing an opportunity to have the best of both worlds for consumer and enterprise adoption.
By all means, drive hard the adoption for consumers and synchronise their credentials to their cloud accounts. I have no doubt that both user experience and security will increase.
However, the threat models faced by enterprises aren’t necessarily the same as those that consumers face and therefore I think it would be a mistake to replace an existing strong process with a weaker one in the name of security and adoption; especially when there is little to no technical or UX reason to not give customers the choice.
For the avoidance of doubt, I think organisations coming from weak, phishable MFA will benefit from passkeys; regardless of if they are synchronised or not. Nonetheless, I believe that if your organisation (like the last two I have worked for) is already immersed in the WebAuthn world then this could be a step backwards for you.