Passkeys: Myths, Facts, and the Path to Successful Adoption [Intermediate]

So, hello and welcome from my side. I maybe give another few seconds to wait for the exchange of people, but I'm happy that so many of you are still here and not leaving.

So, I'm going to talk about Passkeys for the next couple of minutes. There have been several talks about Passkeys in this conference. There will be more Passkey talks, and I can assure you, not all of us are telling you the same thing, and that's also the motivation and the reason for this talk, as you will see.

So, what I will show you, if I can handle that in the next couple of minutes, just a very, very short introduction to Passkeys, so we're all on the same page. Then, a short motivation for my talk. I don't know. Uh-huh.

Then, actually, the main part, I'm going to use four statements and check them, whether they're facts or they're myths. So, and by the way of doing that, I will dig deeper into some contexts and hope to shed some light on some questions around Passkeys that you may have in mind, which I had in mind when preparing for this talk.

Then, after that, a short conclusion, personal conclusion, and I put together a short checklist for a successful adoption of Passkeys. So, when we talk about Passkeys, I'm sure probably every one of you has used Passkeys. Who has not used Passkeys?

Please, raise your hand in the last couple of months. Who doesn't know what Passkeys are?

So, all of them, all of you know what it is, so I can actually skip this. So, it's just to link it to your personal experience. It can be Windows Hello, it can be on a Mac here, it can be on a mobile, but it can also be hardware.

So, when I talk about Passkeys, I mean all these types of FIDO2 authenticators put together, but I will mainly talk about the situation when we are in a browser, when we are using a browser, on a laptop, on a mobile, on an iPad, using Passkeys, and not if we're on an app, because that's not really interesting. The interesting questions arise if we are on a browser.

So, what are Passkeys? So, it's actually very simple. We could say that it's passwordless authentication using public key crypto in a standardized way, but it's not really at all that simple. There are many concepts in FIDO and in Passkeys. There's lots of protocols, there's WebAuth, there's CTAP, there used to be UAF, U2F, and so on. I don't go into these details. There are hardware tokens, there are software tokens, there are device-bound, there are syncable or synced Passkeys, and there's the idea of discoverable or resident and non-resident Passkeys, maybe you've heard of that.

There's usage presence, user verification, and so on and so forth. So, I don't want to go into these details, but that is actually the reason in my experience that we have lots of unstructured discussion when we talk about the security or the usability or the universality of Passkeys.

So, that's my experience in my job. I'm a product manager at Airlock. We do CIM. We also support Passkeys, but not only.

So, I have a hopefully pretty objective view on this and I'm not trying to sell you Passkeys. So, that motivated me for these talks because FIDO and Passkeys, it's really a complex topic with a lot of aspects, which led to lots of complicated discussions with customers or with partners or with other vendors. FIDO has been around for a long time.

Passkeys, I guess, if I did my research right, since like four years. Actually, from my point of view, there's a lot of good reasons to use Passkeys. First of all, security. It's not only phishing resistance. There's a lot of other security advantages. The UX has gotten really, really good. If you do Passkeys well in a browser with the latest stuff and then you can really get a really good UX. It hasn't been always like that, but I think we reached a point where it's really good. It makes itself.

So, you can reduce costs. We have customers that chose the way to Passkeys just because of reducing costs, not because of security. That's a fact. They cost less than managing passwords. They're broadly supported today. I wouldn't have said that two years ago, but today I think it's really good. And Passkeys, they still evolve. They're still getting better. Things are added. We are still learning. I judge this as a very positive thing.

So, I ask myself, why is the adoption not faster? Now, you must know that in our CI world, the customers we have, they are typically highly regulated. They're not the easy ones to go to Passkey, but still also in the rest of the world, I would expect Passkeys to be adopted much faster. That's the reason why I started to do some high-level research and find out where can we use Passkeys, where can we not use Passkeys.

So, things I heard when discussing with customers or other IT security professionals about Passkeys, mainly with customers that already have something, is like Passkeys do not provide strong customer authentication, or let's say I cannot use Passkeys in some situations. I have legacy applications that can't do Passkeys. The browser support is not well enough, or it's very uneven, and so on and so forth.

So, what I did to prepare this talk is I took four of these statements and I want to analyze them and check whether they're more facts or more myths. So, this keeps clicking itself, but number one, there has been this statement, synced Passkeys are insecure.

So, it's just an opinion, it's not right or wrong. Who thinks synced Passkeys are insecure? Please raise your hand.

So, it's a few. Who thinks they're secure? Maybe a few more. Thank you. I will tell you what my opinion is, and again, it's not simply black or white, so we have to look at it.

So, first of all, what are synced and what are device-bound Passkeys? We have to make this decision, this distinction, it's very important.

So, a device-bound Passkey is a Passkey that is, or a Fido key, that is somehow bound to a device, typically to hardware, like to a laptop, in a TPM on a laptop, to an iPad, to an iPhone. I'm not discussing the hardware tokens here, they're intrinsically device-bound, but that's the interesting stuff here.

Whereas, synced or syncable Passkeys, they can be exchanged between the devices, which has advantages and disadvantages. So, simplified, say simplified, like the private keys, they live somewhere in a cloud. It's not technically very correct, but you can think of it like this, and there's some kind of cloud sync mechanism, it could be the Apple iCloud, it could be Google Cloud, it can also be a password manager, like 1Password, Bitwarden, whatever.

So, that's the basic idea. And what are the properties of those two categories we have to distinguish?

So, device-bound Passkeys, you have to enroll each device, that's definitely a disadvantage, but then the security of it is very independent of the cloud sync. It's really bound to hardware, so typically, if it's done right, the key cannot leave the hardware, if it's done right. You need a recovery process, if I lose one of these devices, and I lose my phone, and I get a new one, I have to re-enroll it, and so on.

Whereas, the synced Passkeys, you have to enroll only one of them, and then the rest of them, they get the Passkey, if it's done right. So, the recovery process is kind of done by what I call the cloud sync provider, be it Apple, Google, whatever.

Sorry, again, that happened. Just probably here. It's probably my back that's doing this automatically.

So, private keys are synced via the cloud, and most important, the security of that, it really depends on how well the cloud sync provider does the sync. So, we don't have an influence on that, we're dependent on that. I think that's the most important.

So, it's not that easy to say whether they're insecure or secure. So, it's a trade-off from my point of view.

So, I would, on the good side for synced Passkeys, I would say we have the usability, good usability, we don't have the recovery processes, we still have the phishing protection, we have no static secrets, and all the other good things about Passkeys. We have all the fine grade control like user presence and user verification and so on. And on the bad side, we have this dependency on the cloud sync provider.

So, it's actually, you have to weigh pros and cons, you have to look at your use cases, probably the most important thing, and you have to look at how well the cloud sync is implemented, and this may also evolve as time goes by. And for me personally, what is very important is the good UX, because in the past also UX has won many times over the really hard security facts.

So, for me, it's a clear no, but of course it's not that easy, it's just a personal opinion. So, I think you can't say they're insecure, but probably they're not secure enough for some use cases. That brings me to the next fact check. Do Passkeys provide strong customer authentication? Whose opinion is that it's strong customer authentication and it's not strong customer authentication?

So, it's just very few. All of the rest, it's the same at both times.

So, let's look at a definition of strong customer authentication. I think the most common definition is that you have to have two properties of a different category.

So, I put one in the x-axis, here I put together adherence like biometrics and knowledge. For this type of comparison, I think it's okay to put them in one, and we have possession on the y-axis, and typically strong customer authentication is in this square, where you have both properties in an authentication scene.

So, it's not about two-factor authentication, it's about strong customer authentication, which is actually independent of whether it's one or if it's two steps. So, down here you would have the biometrics, fingerprint, face, passwords, pins, typically also email OTP, assuming that you can access your email account with a password only.

Here you would have all the hardware stuff, it's the obvious ones like the hardware keys, the hardware OTP generator, the older ones still in use, and I also put their SMS OTP, because I think receiving an SMS can under normal conditions be considered to possess the mobile phone or the SIM card. Of course, there are risks, as we all know, but I would put that there.

And on the top right side, where we talk about strong customer authentication, there I would place the apps, if they're done right, so binding it to the hardware of the app, combined with biometrics or a pin, like the push solutions or QR code scanning and so on, and of course also the two-factor authentication stuff like password and SMS. How about FIDO? It really keeps doing this on itself. How about FIDO keys?

So, the device-bound keys, where the key is really bound to a device, and if they use biometrics or a pin, I think it's easy to put them up there. But the big question is, how about synced pass keys? Where would you put them?

So, I thought about and discussed about and read about that for quite a time, and I put them here, down here, so it's not really a yes and a really no. Why did I do this? Because I argued before that synced pass keys, they are not device-bound, so we don't actually have the possession thing, but I didn't want to put them down there, because it's not only about the second channel we have here, for example, and we have also some risks here, like push fatigue or man-in-the-middle attacks, or various risks with the SMS.

It's a more multi-dimensional thing to say whether it's strong or it's not strong password authentication. That's what I want to say.

So, we have good UX, we have phishing protection, we also have that here, but we also have the recovery problem solved, if it's done well, and on the downside, we have, as we saw before, we have the security depending on the cloud sync. So, I think this is still the main issue here, this dependency on that one, and that brings me to my personal judgment, whether this is right or it's not right.

It's definitely device-bound pass keys for me, it's definitely strong customer authentication, it's not about the second channel only, it's a trade-off between many dimensions, and when looking at synced pass keys, definitely the most interesting ones, I think, from many perspectives. There can be strong customer authentication if the cloud sync is done right, but at the moment, sorry, that happened again, but at the moment, it's very hard to verify.

So, at the moment, it's very hard to verify if it was Google or it was Apple, it was somebody else, or it was some really badly written program. That's actually a pity, that's why I say I made it easy for myself. It really depends on how you use them, so that's my message here. It's not that easy to say it's secure, it's insecure, it really depends, you have to look at it closely. I hope that changes over time, and in two years time, we can say, well, isn't this was improved?

So, it's a yes. Let's see.

So, next, third one. I often hear this, because we have a lot of banks as customers, and lots of them, they say we cannot use pass keys for several reasons. By the way, there's a talk afterwards, which I hope I have the time to see, where a bank is going to talk about how they use pass keys. I don't know in what way they do, but maybe it's very interesting.

So, I find four reasons, usually, why they say it's not possible. Compliance, security, they already solved the secure authentication, or the strong customer authentication problem, why do anything, and missing transaction approval, or missing transaction confirmation.

So, let's look at those very quickly. So, we actually, security, we covered before. I think it's the discussion about whether it's device bound, not device bound, whether you consider it strong customer authentication or not, but what I would point out is, I talked to many banks for customers, and they really have the phishing problem. It's really an imminent problem. It's really causing a lot of money loss. It's a very current topic, and FIDO takes that away, and I think it's the only authentication scheme within a browser that can really solve this seriously.

In the app, we don't have this problem. Then, what we also hear also from analysts is, well, banks, they hesitate because they have a solution for some customer authentication in place. Why should they do anything?

And here, again, I think it's the phishing problem. We have, from our customers, we have some banks, not half of them, but some, they are really looking very closely at FIDO, even of the regulation problems that we have. They will be investing money in that.

So, I expect that FIDO will, and Poskis, will become part of the banking universe in the next couple of years. So, missing transaction confirmation, I think that's not true. We can do it. We implemented it. It's just not in the way that you have strictly technical, it's really doing stuff on its own. It's not strictly what you see is what is signed, but other methods have to do.

So, technically, the user cannot really be sure that what he sees is really what is signed. So, that's an issue. It might be an issue with regulation, but that's not really clear. It's being discussed, but it's definitely not true that FIDO cannot do transaction approval. If you doubt that, if you have doubts, I'm very happy to discuss this and learn something, then come to our booth.

Then, compliance. Compliance, I think that's the biggest issue for device-bound Poskis. I think it's okay for synced. I think at the moment it's not okay for several reasons, but I expect that it will become a lot clearer with PST3 and also the payment service regulation. I hope it will be a lot clearer with that and that we are gaining on this and Poski will finally become usable for banks also under regulations. We have also lots of banks that are not under PST2 and for them it's a lot easier to go the way to Poskis because of the regulations.

Then, the last ones I have here. No, sorry, I'm running out of time, I see.

So, here for me it's also clearly it depends. It depends on how you use it, whether it's device-bound or not device-bound Poskis. The fourth one, I think I skip it because I don't have the time for it. I would skip it and go to the conclusion. If you're interested in that, just come to our booth. I will go through it.

So, sorry for that one. So, my key learnings for when preparing for this talk is really Poskis offer great UX, great security. You can save costs, so you should actually use it. It's still evolving, which I think is a good thing, so we have to keep up with that. We have to differentiate between device-bound and synced Poskis. It's a very important distinction you have to make and understand. If you're highly regulated, then you really have to have a closer look and probably discuss it and probably wait a bit.

Poskis are complex, not in the UX, in the usage, but you have many bells and whistles and many concepts in Poskis you have to understand. So, you need a major IAM solution that doesn't really just have a tick. We can do Poskis, but it really has to be major in that. I mean mature. That's probably the right word. Sorry.

So, I tried to put together a very short and very high-level checklist if you're thinking about Poskis and not sure what you should do. So, first of all, look at the use cases and find out if Poskis fit your use cases or not. They do not fit in every case, but in many cases.

Then, check your compliance requirements. Very important, I think. Decide on whether you need device-bound and synced. If you need device-bound, whether you can do it with the UX that you want or with the cost savings that you want, that's not too easy then. Plan migration well.

So, don't expect to customers to just switch over to Poskis. Customers and users, they are not used to that. They don't understand it. You have to really inform and train them well. Allow the coexistence with other factors, at least for some time. Maybe you need an alternative factor. That was the fourth thing that I checked, that I skipped. There are situations where you cannot use Poskis, but if you really depend on that your users can authenticate in any situation, then you probably need an alternative second factor.

Then, definitely talk to the experts. You can do this here. You can do this afterwards. There are a lot of experts here. Come to our booth if you want to talk about that because the topic is really not yet that easy. There's lots of opinions. There's a lot of malinformation around Poskis and Fido.

So, let's talk together. Last but not least, is your CIM fit for Poskis and does it also grow as Poskis evolve? That was it. I hope you got some information and this helps you when going to Poskis or adopting Poskis. I would be happy to discuss with you. We have our booth on level B, just next to the Kuppinger Cola booth.

So, you have to pass through our area. We do the access control for a Kuppinger booth. Thank you.