Rolling out Passkeys: Consumer and enterprise-ish scenarios

If you haven’t looked into FIDO2 yet, you really ought to. Username/passwords is essentially no security in today’s day and age. MFA adds some security but is phishable. Not all MFAs are equal. And FIDO2 as a standard gives you the convenience and security, a rare but good combination in the security/identity world.

I had written earlier about Passkeys in enterprise scenarios.

When Passkeys were first baked into iOS16, it felt a bit not ready for enterprise scenarios. And as indicated in that blogpost, with iOS17, Apple has rolled out some very thought through improvements that make Passkeys a great solution for enterprise. I can’t wait really.

You will still synch key material through iCloud, which you can disable by disabling keychain synch — effectively making it a good solution for a single device scenario if synching through iCloud gives you heartache. Android still doesn’t have all the controls as of today, but at least for iOS you can offer enterprise level control and the convenience of touch ID and face ID with pretty decent security level.

Now naturally there are still concerns, like you being forced by an authority to divulge your password vs. your biometric. So I still advise using Passkey as a second factor. But this brings me to the main focus here, which is things you need to think of, when rolling out Passkeys to consumer scenarios </drumroll>.

Here are important things to consider, and please do add to this list if you feel I missed anything.

Not all consumer scenarios are equal

The word “consumer” can mean many varying degrees of concern. A banking consumer is very different from a HOA member. This is a critical factor to consider how you design your passkey infra. The driving factors behind passkey may be entirely different here. While in the first scenario your driver is security, the second scenario is convenience. Its nice not to have to remember a password right?

Recommendation: Your Passkey architecture is not a one-size-fits-all. Different apps will need to treat the problem differently.

This leads me to the second point.

Your passkey is as secure as the consumer’s iCloud

Historically, there have been breaches that were essentially the customer’s iCloud account being compromised. And by extension your google account. Google and Apple have an unenviable task. They need to offer security while not adding friction for your most non-technical user. This is not an easy task. While FaceID is simply amazing when it comes to scanning your face and creating a unique thumbprint of the user that is more unique than even a thumbprint, reality is, your passkey is just as secure as the customer’s iCloud account.

So if you are an app for whom security is paramount, say a banking app, and you rely on the customer’s passkey as the only authentication factor, a breach of the passkey is a breach of the customer’s banking account. Not good.

Recommendation: Use Passkey as a second factor for sensitive scenarios.

You the admin will get no notification of breach

And this brings me to my next point. In corporate infrastructure, you can build detections and protections that in most (not all) scenarios help you detect breach. This may be as simple as the user raising their hand, or some SIEM flagging a problem. You have step up OAuth scenarios, or risk based conditional access policies that kick in. All these protections are nice, but they have something in common.

The commonality is, you getting a timely notification of a need for better treatment from a security perspective.

This is not possible in consumer passkey scenarios. If someone’s iCloud account gets compromised, you have no way of knowing. Apple will not send you a notification. Same applies for Google. This IMO is a shortcoming of passkeys which gives me pause using passkeys as the only factor in authentication.

A phrase I have heard in reference to passkeys is “Password replacement”. I like that phrase. It is a replacement for one of the factors. You decide which one. In enterprise scenarios where you control the story end to end, it could be your only factor in most scenarios. In consumer, perhaps not.

Recommendation: Same as above, use Passkey as a second factor for sensitive scenarios.

You should maintain a fallback identity.

I do like passkeys but nothing spells vendor lock in better than Passkey. At least your iCloud keychain can be manually copy pasted one by one if you decide to move from iOS to Android or vice versa, what do you do with passkeys? These two clouds do not talk to each other.

The answer, you have to setup your passkey again. Basically a re-registration process, and deprovisioning of the older passkey.

But how do you do that, if you didn’t maintain the ability for the user to prove their identity in a mechanism other than passkey? The answer, you can’t.

In enterprise scenarios, this means a phone call, or a ticket to the IT department. But in consumer scenarios such high touch treatment means the cost is multiplied across the number of users.

The answer, is to maintain a non-passkey identity that is hardened, inconvenient, and sure less secure than passkey, but used as a fallback mechanism when a passkey can absolutely not be used. The benefit being, in 99.9% of login transactions, you remain unphishable when using a passkey. And you get the convenience of biometrics protection. But where that is not possible (such as account reset, account recovery, or where you are in unfriendly territories), you have the option of not using passkey.

Recommendation: Maintain a non-passkey identity

Passkeys can be airdropped and shared or synch to insecure devices

Well, like I said, your passkey is just as secure as your iCloud. And if Apple allows “1111” as your passcode that you can keep for the next 10 years, your passkey is not too secure is it? Similarly, enterprise scenarios allow passkeys airdropping to be disabled. But not so for consumer scenarios. Could someone be socially engineered into sharing their passkey? Sure!

Now this won’t happen over the internet, so this attack won’t scale. But just something to be mindful of, that this is something your app (RP) cannot dictate, that “I shall not accept an airdropped key”.

Closing thoughts

So what are your thoughts on this? Are you rolling out passkeys to consumer scenarios? What other considerations do you have in mind?