Passwordless Customer Authentication: Reduce Friction and Increase Security

Hello, and welcome to the webinar. Today's topic is passwordless customer authentication, reducing friction, and how to increase security. I'm John Tolbert lead Analyst here at co Cole, and I'm joined today by J GU product marketing lead for CIM and beyond identity. Hi J so let's launch right in, we're controlling the logistics.

So, you know, everyone is muted centrally. There's no need to mute or unmute yourself. We are recording the webinar and both the recording and the slides will be available in a few days. We will do a couple of polls at the end of my section, and we'll discuss that at the beginning of the Q and a period.

And yes, there will be questions and answers, and there is a questions blank in the go-to webinar control panel, and feel free to type in your questions there at any time. And we will look at them at the end. So again, I'm John Tolbert, I'll start off talking about passwordless off multifactor authentication, risk based authentication and the business drivers, and then I'll turn it over to Jing and then we'll do Q and a. So first up, let's look at the threat landscape.

I'm sure most of you watch the cybersecurity news and, you know, the last few years it's been seemingly nonstop news about hacks data, breaches, ransomware, all sorts of things, you know, and, and passwords are unfortunately a big part of that, you know, a very, very large percentage of the time.

And that is because, you know, with user credentials, an attacker has much more capability of doing damage and, you know, they can, the, the fraudsters or malicious actors can use those credentials in a variety of nefarious ways, whether it be trying to steal personal information, corporate data, industrial espionage, or, you know, even cases where, you know, a lot of the ransomware operators are kind of behaving in some ways like a P T you know, advanced, persistent threat actors, where they gain access to, you know, the intended victim's network they get in and take information before they encrypt it.

Then, you know, when they're ready to do that, they detonate it. And then, you know, the ransomware encrypts everything, and they have to get in contact with them, or hopefully they've restored from backup.

You know, one of the, the big cases, like, you know, colonial pipeline that we heard about last year, you know, that that was started via a breached password. The attackers got in and did exactly that kind of recon the network, took some information and then set off the encryption, you know, and that's, that was obviously a big problem for them.

But I mean, even here, you know, temporarily this was a hit to the economy, a disrupted flights, fuel availability, you know, so breached passwords are a, a really, really big problem, you know, and then se solar winds also, you know, it was reported early on that, you know, an attacker was able to get access to some of the code through a fairly simple, easily guessable password. So passwords are problematic. There's really no way around that. So what do they do with these passwords?

What kinds of information are they after the bad guys, the fraudsters in this case, you know, you look at the targets, it's just about any industry.

I mean, commonly you think, yeah, finance banking industries like that, or maybe government agencies, you know, at the start of the pandemic, there were, you know, many, many cases of fraud against state unemployment insurance agencies, but, you know, social media, our, our targets, mobile network operators, airlines, and hotels, you know, even prior to the pandemic, anybody in the hospitality industry was seeing a lot of fraud, you know, attempts to take over user accounts, to get, you know, their frequent flyer miles or their, their other things available through the rewards program.

So, you know, that insurance companies, healthcare providers, you know, many individual data breaches have told more than a hundred million records each and some of the social media companies have had, you know, PII lost on in excess of a billion users. So let's talk about the two, you know, two of the biggest kinds of fraud and what their goals are for the fraudsters.

You know, so we have ATO fraud account takeover, and just like, it sounds, you know, try to get at least temporary access to a legitimate user's account. Why, well, you can use it for value transfers. Like I said, kind of anything that can be turned into money, frequent flyer, programs, rewards, whatever, anything that can be turned into currency is a target. And almost all industries are targeted.

Fraud is, has increased greatly over the last few years. And unfortunately there's no signs of that slowing down. You know, then we also have AO fraud account opening fraud here. The goal is to create fake accounts based on real people's data.

You know, the sources for that are things like employment records, school records, medical records, you know, years ago in the us, the social security number was unfortunately sort of a defacto index. You know, so a lot of records that really don't need that as an index have that anyway.

So, you know, but it's not just the social security number, it's physical address addresses, you know, phone numbers, although anything that you might be asked during registration time that can be used to build a fake account, that's what they do. Why do they do that?

Well, besides just taking over maybe a credit card for one or two fraudulent transactions, if you can open a fake account, then you know, that increases the likelihood that the fraudster, you know, can do much more, you know, major damage. They can get lines of credit, take out their own credit card, you know, and do money laundering.

You know, there have been, you know, a lot of work from home schemes, which are really, you know, trying to get people to become, you know, money mules and move money from illegitimate sources into legitimate sources, storage places. So, you know, account opening fraud has greater risk for both the, the victim as well as the financial institution that gets hit. So what do you do about these things?

Well, the best mitigations for ATO, you know, account takeover, multifactor authentication, and risk based authentication take away the password that certainly helps mitigate the risk, you know, significantly. And on the AO side, the account opening side identity proofing and ongoing know your customer operations.

So, you know, in the, you know, a few years back, it might be common to open a bank account by going into a branch, showing your ID driver's license passport, you know, showing maybe a utility bill to kind of link you to an address. And then periodically you'd have to, to continue to prove that now we have the capability of, you know, applications, you know, mobile based apps that can facilitate that remotely even. So you can use your phone to take a picture of, you know, a physical ID, match it with a selfie, maybe use the NFC capabilities in your phone to NFC enabled documents.

So these are ways that we can mitigate account opening fraud, even in the, in the pandemic age. So what is passwordless?

Well, we know when passwords are, and we also know that they're just a huge, huge risk password list means getting rid of moving passwords. So, you know, modern authentication systems can use things like various sensors in the smartphones. We'll talk about that with regard to behavioral biometrics in a minute, you know, attributes about your device itself, you know, the phone, the computer, what languages, what fonts, what browser version operating system version, all this information is available that can be used to provide context, user history.

That's important to know, especially on the finance side, you know, because if you make it a transfer, it it's great that your bank cares to know whether or not this is somebody you've transacted with before. You know, so building a baseline is, is a necessity. And then being able to ask the user in the event, something unusual occurs, you know, for passwordless occasionally pins are still used, but they're evaluated on the device. They're not transmitted on the wire. And I think that's the really important distinction here.

You know, you look at some of the earliest authentication schemes. You had user with username, password authenticating to a site that a password goes over the wire sometimes, you know, in days gone by in clear text sometimes kind of encrypted either way. It was a bad idea because there's a password database on the back end.

You know, then we had, you know, a traditional authentication scheme, which might have been augmented by SMS OTP, and that would be interpreted and evaluated by the cm system or the external authentication service of a site. And then, you know, they might take that, turn it into a Federation token and tell the site, okay, this user has authenticated.

But what we have today, preferably are, you know, modern passwordless methods where, you know, using a standard like Fido, which we'll talk about in a minute, can, you know, you do the authentication on the device that may be, you know, using biometrics, fingerprint, facial recognition, or some sort of gesture, you know, that phyto can create a, a site specific key. The authentication happens on the device. The confirmation of a successful authentication then gets turned into a, a token by the authentication service or cm system that then tells the relying party customer.

Yes, in fact, this customer, this end user has properly authenticated, and that can be integrated with additional context, information evaluated and a risk engine. So looking at the options that are out there today, not even showing passwords, cuz we really want to get rid of those. But you know, you've got mobile apps, we've all probably interacted with mobile apps. Those are in many cases made possible by the SDKs of authentication service providers.

We have those biometrics, the fingerprint, the, the facial recognition, some use USB keys or other kinds of proximity devices, behavioral biometrics, you know, this is kind of up and coming. This is looking at various factor on the phone or the computer looking at like how you interact with a, a phone, how you swipe or type, you know, location information. And let's say on a computer you're typing speed or how you use a mouse behavior. Biometrics can be used to build a baseline for normal user behavior and tied to a digital identity.

It's also great for knowing when a bot is trying to impersonate a user, then we've got SMS OTP, but you know, it's, it's problematic it, there are security concerns there and certainly not recommended. And it's not an ideal user experience. So a word about Fido Fido, I think, you know, bridges the gap between mobile and web, Fido's been around since about 2014, some of the original, the UAF U two F specifications, the UAF was about mobile, but there were, you know, a few issues with not being able to necessarily use it directly with, with websites.

It was great for, you know, mobile apps, but you know, a lot of that has been rectified with Fido two and the web often specification at w three C.

We see, you know, now there's support for windows 10, 11, hello, and Microsoft, Google is built it into Android seven plus Samsung also, you know, it, they have gone for pH biometric certification, which we'll talk about in just a second and all the major browsers support it, you know, and this is great because you just can register and authenticate using, you know, their own mobile devices and they can use things like Bluetooth and then just use the phone as a second factor itself. So this is an important piece of the overall MFA landscape, I think.

And in preparing for this, I looked, you know, and there are now about 900 different authenticators and servers that are certified against Fido U two F UAF and 2.0 standards. It also, they also offer a security certification, which maps somewhat to the identity and authentication assurance levels.

And, you know, they also offer this biometric certification so that end user companies can look at this and say, okay, now we know what the R F R that's the false acceptance rate, the false rejection rate, you know, how often a legitimate user gets turned away or an illegitimate user might be inadvertently granted access. So those are important security considerations on the biometric side.

So, you know, looking at that kind covers multifactor password list. Now let's look quickly at risk based authentication.

You know, this is looking at context, you know, things about the user things about the devices that they're using, you know, not just the behavioral biometrics, but you know, what, what kind of devices it, the authentication services could build a footprint, a fingerprint off of, you know, all the installed attributes of a device.

Then looking at like the, the network context and then the user behavioral analysis, you know, this is particularly useful in finance or retail transactions because knowing if, like I said before, knowing if a transaction kind of falls within the bounds of what a user has done or would be expected to do can certainly elevate or decrease the overall risk assessment. So looking at these things, you know, at transaction time, as opposed to saying, you must authenticate explicitly with, you know, a password, an OTP or a gesture or something, looking at these, these different factors.

And if they haven't really changed at all, don't bother the user. If the risk associated with what they're trying to do has an increased, then keep this as unobtrusive as possible. This is where I think risk-based authentication has, you know, many benefits, many values, a quick word on PSD two.

It is a, a directive rather than reg a regulation that is active now in the EU. The European banking authority is the administering organization.

And, and it is in effect. What is interesting about this is it's a banking regulation that essentially mandates multifactor authentication and risk based authentication. So they define strong customer authentication as like we, we do in computing security, generally two of the, you know, something, you know, something you have or something you are in transactional risk analysis.

The, you know, the risk based authentication that we were just talking about can be used to reduce the need for those very explicit authentication events where you might have to enter a password or, or prove who you are. If you're doing transactional risk analysis under PSD two, then that can reduce the number of times that a user has to log in explicitly.

So reducing friction, you know, this is an analogy that we often use in the identity and computing security world to talk about interactions between user and systems, you know, and I think it is a good analogy because friction is, you know, slowing something down, you know, causing it to generate heat consumers, experience friction with IM systems, you know, during the registration process, how much information do you ask for upfront as a site operator, identity proofing, you know, it's necessary in many contexts, but you know, it can be done in a way that's not as painful for consumers and then authentication.

You know, we certainly understand that not all friction can be reduced. And of course there are cases even where we expect it.

You know, if you logged into the bank and tried to transfer $10,000 to somebody, you hadn't done that before. I certainly feel good when the bank stops and asks for a proof that I really want that to happen. So getting the right amount of friction for the, the proper kinds of transactions I think is, is necessary and something that we need to focus on in the cm world.

Lastly, I'm updating the leadership compass on consumer identity right now. And some of the latest trends that we see our email address is still the most common registration method.

You know, social account credentials are still an option, but, you know, we see increasing use of mobile number as a primary identifier in some parts of the world, the demand for fraud reduction intelligence platform integration is rising rapidly. It's probably one of the most important most sought after things in CIM. These days, there are use cases for identity proofing outside of just, you know, traditional finance anti-money laundering, know your customer. We see that more in more in things like the hospitality industry, multifactor authentication is underutilized.

There are really no clear winners among all the different kinds of authenticators out there. Many different kinds are used. Finance and banking are still have, seem to have the more secure cm implementations comparing industries. This is probably no big surprise, but passwords are still widely used. So let's take a quick couple of polls here. Does your organization that you're working for now currently offer some form of passwordless authentication, multifactor authentication or risk based authentication? Yes or no. Okay.

And then the second one is if you're not doing passwordless risk based authentication, why not? Is it because of budget it's because the perception that, you know, the risk of breaches isn't really that high, the lack of customer demand, or, you know, difficulty with implementation, you know, integration with legacy apps and systems.

Okay, great. Thank you. And just a reminder, if you have any questions, feel free to put them in the questions section in the go to webinar control panel and we'll take them at the end. And with that, I will turn it over to J good Morning. My name is J I lead a product marketing for our secure customers product at beyond identity. John covered some really great points. So you know where this overlap I'll probably just speed it up, but yeah, looking forward to sharing this presentation with all of you. Okay.

So customer authentication, what's really exciting about customer authentication is, you know, a lot of tooling and platforms since cybersecurity is about risk mitigation, right? It's about reducing your risk, reducing the surface area of attacks, but when you get customer authentication, right, you can actually drive revenue and you can do so in three ways, one of them is user experience because customer authentication spans across the entire life cycle of the customer, right? So registration, which is linked to acquisition login, which is linked to engagement.

And then of course, recovery, which is linked to retention and the ability of users to return to your app after a period of time, passwords are a major contributor to drop off. And when we talk to companies, you know, I hear a lot of things like we can see the number of visitors that hit our website or our mobile app, and then the steep cliff of drop off when they're faced with the registration or login page. And that sucks because that is a problem that can be fixed, right? Just with some of the new technology innovations that make it possible today, which we're gonna cover.

And then the second thing that customer authentication can do for a business is increase security. Trust is earned and in today's world, it's hard earned and easily broken. So 68% of consumers have actually stopped using a product or a service because of a breach. And there's research that shows, you know, stock prices drop by an average of 5% following the disclosure of breaches. And it costs organizations a lot of money to deal with the legal and organizational ramifications of fraud or breach. And it turns out passwords account for 80%, over 80% of breaches.

And then of course, when it comes to authentication, you need something that works because it's the front door to your services. It needs to work for a hundred users, a hundred million users, and also seasonal spikes and increases in demand. A lot of organizations historically have built authentication on an app to app basis, which creates data silos and essentially multiplies maintenance efforts exponentially as they grow with each application. So when you can get customer authentication, right, you can solve three concurrent problems and in doing so really move the business forward.

But the thing is right. Passwordless is not created equal. People have been trying to solve the problem with various tactics. And these tactics include a one time push code sent over SMS or push notification magic links. But these tactics all have two things in common. One on the user experience front, they take the user out of the flow of the product experience. So if I have to go grab a one time code, I am no longer within the authentication. I'm no longer within the product flow. I have to go to my SMS app and check the code, copy paste, all of that.

Or, you know, if I'm on the web and I want to log in and you're saying, Hey, we need to provide, you know, click this push in a patient on your mobile app. Sometimes my phone's charging in another room. The user experience is interrupted by these types of tactics and on the security side, a lot of the times they leave the password in place, which means that your database is still, still has a red target on it because attackers can breach it and essentially get the shared secret out of the database. So these tactics are fall short of an ideal user experience.

And that ideal user experience is that your user comes to your product and they're able to log in with minimal effort on their part. They don't have to pick up a second device. They don't have to have interruptions to their experience. And it takes place in less than five seconds, essentially taking the burden of authentication off of users and putting it onto technologies that we have today. So the second front of passwordless is the password list. Different passwordless methods don't offer the same level of security.

I really enjoy this graph that Daniel Myler put out that shows the strength of vulnerabilities of various methods. A lot of it really boils down to fish ability. Fishable factors are factors that bad actors can acquire from users by posing as a legitimate institution. Unfortunately, most common methods of going passwordless are fishable, you know, to really common techniques at work include social engineering and notification flooding. And this is not just a theoretical exercise, right? This is not just focusing, oh, like this is a potential risk, maybe five or 10 years.

Now I know this, this is happening today. These factors are being attacked today. And these types of attacks are at the scale. And the extent to which that the government actually issued a strong mandate against SMS OTP and push notifications. So in short, anything that is less than UN fishable, MFA is not good enough. So it's against the context of these various vectors, user experience security and the fundamental criticality of scalable customer authentication that we build the secure customer's product.

So, you know, I said earlier, this technology today that can be deployed that eases the user effort while increasing security and those technologies combine user biometrics, proven security protocols and the secure enclaves of modern devices. So this combo allows organizations to move away from authentication, with fishable factors and symmetric secrets and move towards passwordless facilitated via asymmetric cryptography, a private public key schema, where the private key is constructed and can never leave the hardware enclave on that exists on all modern devices.

The result of this type of approach, this type of architectural approach is that when we say passwordless, we don't mean, oh, like we're gonna hide the password or tuck it behind a face ID, or you don't have to use the password. You can use your one time code, but if you use access to your device or whatever, like give us a password on our recovery.

No, none of that, when we say password list, we mean, we get rid of the password altogether from usage and storage. We replace password with asymmetric photography, next five, nine certificates with no certificate management and keep in mind, this is the same technology that is securing trillions of dollars in online transactions.

Every day, the private key on registration is created, never leaves the devices TPM and the fundamental on moveability of the private key is actually really nice because if the secret can't be moved, it can't be disclosed. And it's unfishable. The public key is sent to the cloud. And not only is this asymmetric crypto happening, we also gather device security signals that is captured from the exact authenticating device at the exact time of authentication.

So sign package containing the risk signals is also sent along with the certificate for each authentication request, which results in unfishable MFA by default, layered on with dynamic risk based authentication. So the risk based part, which John mentioned earlier is really exciting, right? Because we talk about friction as if it's something that is, oh, you know, God forbid this friction in my application and friction is really bad for conversion rates. There's good reason to, you know, try to reduce the friction.

But as John also pointed out they're instances where friction can be leveraged actually to make the transaction feel more secure. And also there's instances where friction can actually allow you to turn the dial on the security of an authentication. So for instance, I, you know, log in from New York to my banking app at a certain time of day. And then all of a sudden, you know, the banking institution sees a transaction happening at 3:00 AM, Eastern standard time in a location that I do not frequent. That is a high risk transaction.

At which point our system would allow companies to say, okay, at, if, if we see these risk signals happening, please prompt a step up authentication requesting an additional biometric or a native device pin. Again, that native device pin is never shared to the cloud.

So it's, it's not like shared secret in that way. And then in doing so, friction no longer becomes this thing that is always like it is this terrible thing. Suddenly friction becomes a lever that you can pull to actually increase security of your transactions. The way we deliver our secure customers product is via SDKs. And with our SDKs, you can recreate the core beyond identity passwordless experience natively within your native mobile apps, as well as web applications. The user experience involves no second devices.

One time codes, push notifications or application downloads the user pretty much just indicates that they need to, they want to log in and the device, the private keys, the certificates are sort of authenticating on their behalf and doing so securely and doing so with unfishable factors on, in terms of security, the password no longer exists. It's just it's, you don't need it. You don't need it for registration login or recovery. When we say unfishable MFA by default, we mean you're capturing something. You are from the device, biometric something you own from possession of private key.

And then also device level security posture checks, right? And that's a granular user and device level checks that's happening at time of authentication and even beyond during the session so that you can make sure that your consumers are authenticating securely and that the right person is access accessing the right application at the right time. And then of course, with custom authentication, scalability is a really big deal. Reliability is a really big deal.

Again, this is a fundamental part of a product experience. So we are a cloud native SaaS platform built on open standards for extensibility and offer quite a robust set of developer support.

So, you know, at the end of the day, the ideal customer experience that really moves a needle forward in terms of revenue is a seamless omnichannel experience that can accelerate conversions at key user steps, UN fishable security. That's not vulnerable to social engineering, and it's not vulnerable to, you know, credential stuffing or push notification flooding all of these techniques that even the government says, people and companies should start moving away from and then of co backed by a reliable and scalable platform. And that is my portion.

I think we can move towards some Q and as I'm also curious about the, the poll results. So first question, do you offer password list MFA or risk based authentication for consumers? Wow. 83% said yes. And only 17% said, no. Cool.

Yeah, that's good. Let's not be that many people from the sites I visit.

Well, yeah, that's great. That's great to see that level of adoption. Next question was, if not, why not? And let's see what we've got here.

Oh, well, you know, that's wow. That's really interesting. It's not budget. It's difficulty with implementation and integration with legacy apps.

You know, I guess that's not surprising. I mean, you think about all the applications that, that organizations, different kinds of enterprises have to maintain. Just keeping the applications up to date themselves can be difficult. And if they are not using, you know, modern standards, it can be difficult to integrate what, what's your take on what we see here, Jing. Yeah. Yeah. That is interesting because it also seems like budget and risk are both sort of negible here. I think integration is really big piece, right?

Like I, I think everyone, or a lot of really sophisticated security professionals know that password list offers better user experience, better security, but the blocker tends to be all of the scaffolding around password list that make implementation really difficult. So, you know, a few months ago I actually went on to stack overflow just to see what are some common challenges developers are having with authentication. And I think another part of it is developers. A lot of times don't necessarily have security identity access management expertise, so they can work with standards.

They can work with good documentation, but implementation both in terms of, you know, legacy applications, maintenance also in terms of like engineering expertise. I think all of those kind of created environment where people might want password lists, but making it a reality can be a little bit difficult. You know, I think the other thing that's interesting is yeah, 62% said it was difficult to implement and had integration issues, but 38% said, you know, lack of customer demand.

I know from talking to some end user orgs, and like I said, I'm doing the update on consumer identity and access management, leadership compass report. I, I do hear sometimes people from those spaces say, you know, we're not really getting the customer demand for it.

And, and, but, you know, in a way I think that's bogus too, because how's a customer supposed to say that unless they sometimes vote with their feet, I mean, you know, and how do you quantify that? You know, I, I don't, I don't think that good authentication is something that you need to wait for customer demand to make it happen. Yeah. It also reminds me of this very famous quote of, you know, if you ask people what they want, they they'll say they want faster horses, not a car. Right.

So with customers, sometimes you can try to future pace them a little into the experience that is actually quite ideal, that they may not have been exposed to turns out not everyone is plugged into customer authentication as much as we are. But I think when people start experiencing the, the kind of near magic of passwordless authentication, that demand will organically rise and also, right.

Like, yeah. How do you measure, how do you measure that? If you have drop off around registration login and recovery, there might be something you can do to improve that experience. Yeah. Yeah.

I mean, I would say survey customers, but you know, that sometimes doesn't work either. So To say that there's no demand for it, I think just may, you may not be in tune with what customers are, are looking for. So let's move questions. Yeah. How does P technology complicate or compliment 5 0 2?

You know, that's, that's a very good question. You know, I'm aware of some work that went on, you know, a few years back to sort of combine Fido authentication with, you know, P the, the mobile P solutions. And I know that there are a couple of vendors that offer that capability, you know, in that sense, it's like using strong authentication to unlock the key and certificate that are the parallel from the, the P issued certificates. So I know that those things are technically possible, have been codified into products, and I believe RN use in several different agencies already.

Do you have any insights into that from your side gene? Unfortunately, I do not have a sophisticated opinion on this question, so I will leave it to you. Okay. So let's see. Next question. What does it mean to be unfishable?

Well, I, I would say, you know, kind of building on what Jing said earlier, you know, if you've got a type of authentication or registration mechanism, even that, that does it protect the channel in which it's sent, you know, you know, above and beyond passwords, even, you know, something that gets evaluated locally on a device. That's why I think, you know, the pin on a, on a phone or the mobile biometrics to unlock a key. And I think that's preferable because, you know, you really can't fish somebody for that.

You know, you can't send them an email, you know, with some sort of misleading or threatening tone and, and get them to give up a password because they wouldn't have a password if it's gone. Totally. Passwordless using one of these, you know, passwordless mechanisms for authentication. Yeah. Yeah. That sounds right.

I think, you know, a lot of fishing is done via social engineering sometimes with a strongly worded email. Sometimes it just looks like your CEO sending you a text.

It, so it's gotten really sophisticated, but it does boil down to, you know, are there shared secrets and can a consumer, we manipulated into doing the action that would allow a third party or someone else to authenticate into an application, but no share secret. There's nothing to fish if they can't, there's no push notifications. There's no way to execute notification flooding for instance.

So it's about removing, removing the risk and removing the responsibility of the end user to always be on the sort of vigilant about their own security and sort of moving that towards, you know, a private key that stays in a TPM that cannot be fished. It cannot leave the TPM. It never leaves the TPM. It never sees the light of day, but fishing is about bringing the secrets to the light of day. Right.

So any, any sort of factors that can be that, to which that can be done is considered fishable. And if we go by the, the government standards, you know, SMS one time codes push specifically. Yep. Right on next question. How do you make the implementation of SDK is as simple as possible. Say frictionless, How do we make the SDKs frictionless? Okay. So I think there's potentially two ways to answer that question on the user experience front it's frictionless, because it is an embedded part of the user journey.

Like you take the SDK and as with most SDKs and API products embedded into your product, and the user is sort of tapped within the flow, right? At registration, the private key is created without, without much fuss, you know, they can check an email and at what time, you know, they can check.

Yeah, right now the registration flow is they check an email, click a link, and that initiates the token binding certificate. And they log in. They never have to do anything for login. You can add a biometric to login if you want, but you don't have to the user, can't just be logged in with a simple click of the login button or some indication that they wanna log in. So the SDKs are frictionless for users because there's no second devices, there's nothing they need to remember. There's nothing that they need to copy and paste, or, and it's on the same device. Never need a second device.

I think the other way to answer the question is how can you make the SDK frictionless possibly for developers? Because I think developers are a primary user group that actually interacts with SDK's.

I think that goes down into like really thinking deeply about the developer experience and making sure your documentation is task based instead of oriented around, you know, feature sets of your SDK, for instance, making sure that SDK's are available and that multiple languages are supported in popular development languages, making sure that your SDK support open standards, like the IDC and OA and Sam. So all of these things that make it easy for developers to also get up and running. So I guess that's my interpretation of the question. Yeah. I think that makes sense. Let's see.

Next question. How is the registration process made better in a passwordless environment? That's a pleasure.

Well, it's not necessarily the, well, I guess you don't have to choose a password that might be And do not understate the importance of not creating a password. I think I forget the exact number, but research shows, you know, 67% of users will drop off specifically out account creation specifically because of a password requirement. Because when you say create a password, it's not for a lot of companies, right? Like there's password requirements you can't use, you know, you have to have special characters, special letters, like things like that. You can't use it previously used password.

Some companies now have implemented, you know, breach password policies like, oh, you can't use passwords that been previously breached. I was talking to a CSO the other day and he said, you know, I'm working with an auditor and auditors really pushing me to have breach password protection. But you know, a lot of my users are reusing their password. A lot of breaches have happened in the past. Like in the next five years, there may not be passwords that people can use.

So, you know, like getting rid of the password actually makes a really big deal in terms of registration and getting the user on. And then, you know, I think checking your email for a verification link is almost standard practice now, right? So when you can match the user experience that have, that users are accustomed to, and at the same time, make sure they're registered and logged in. That's a one time kind of minor lift on the end user.

It is not, you know, creating an email, putting a password, I'm checking a one time code. It's much simpler than that. And then once that's done, the login is kind of frictionless forever and ever. But registration is a really interesting point in the user journey, right? Because some companies also may choose to have identity proofing. So in some ways, registration, the, the threshold for minimum friction is a little bit higher than login in my opinion, just because, you know, your users are coming to you as unknown identities with unknown devices. Yep. I would definitely agree.

Next question. What about users that don't have a mobile device in these scenarios where most of the signals rely on mobile devices?

You know, that's a very fair question. I think, you know, we kind of assume that everybody does have a mobile device for a lot of these use cases, but there are plenty of cases where people don't, you know, and I, I guess I would say that's where things like risk based authentication come into play.

You know, let's say a person doesn't register mobile device, but they have a computer, you know, there are lots of attributes that can be ascertained about the computing device itself. If you can figure out, you know, what kind of hardware, what kind of software, if it's a desktop, then it's not gonna move around a lot.

Then, you know, then it comes down to, you know, which person maybe within the household is using the computer. Can you use behavioral biometrics to get a profile of all the different individuals in the household and distinguish between them?

Yes, you could because that relies on JavaScript. So you could do something like that and still get, you know, a lot of passwordless bang for the buck with risk based authentication rather than necessarily having to have a mobile device to make that happen. What are your thoughts on that, James?

Yeah, I think it's a really weird question. I think in the browser context, right? It's not that there are no signals you can gather. It's just that it's limited. So some browser just given browser limitations, some signals that people can work with include, you know, browser version, operating system, TPM enablement, status, IP address, and you can do, you know, risk-based medication based on some of those signals or yeah, I think, yeah.

Or, you know, the behavioral biometrics that you were talking about, John, I was pausing because there are some companies that, you know, say for these types of operations, you know, use our native mobile device or vice versa because they have better device finger printing on a mobile device. But I guess that doesn't really apply if, you know, your company only has web applications. So Yeah. Yeah. I think there are ways to make it happen. Let's see. Next question. What are our best practices for designing a user experience for passwordless authentication?

Oh, I love this question. I think, I think this question is so, so important because if you introduce a dramatic change in the user experience, especially around authentication, that actions does not inspire feelings of safety. People are jarred by it, you know, and that's why, you know, Fido actually put out a, a user experience best practices, handbook that's published on their website for how to introduce users to passwordless. I think a key thing to remember when introducing any new feature, especially passwordless is you wanna match the existing UX.

So you're not introducing too much change at once. So users have established UX patterns, including, you know, a lot of the mobile contacts have face ID enabled. Like if I'm trying to sign in to a lot of these apps on my phone, it'll throw up my apple face ID, the little thing will twirl. And I understand that that is an authentication process. Another really common UX pattern is this kind of trusted device language.

So, you know, if you log into a specific application, I think Amazon is just top of mind for me right now, but you can see all of your authenticating devices and you can have the option to add or remove. So I think in terms of passwordless a lot of passwordless that's based on asymmetric photography work off of device extension. So leveraging kind of the trusted device language, and of course, end users also are used to seeing multiple authentication options.

So you have your password, you have your social logins, you know, adding a passwordless option might be another way to just kind of get people over the initial adoption hurdle. And then of course, when you're introducing new things in your UX, good practices include in app queues, you know, a little popup that says, Hey, like, did you know you can do this and kind of walking users through. And I think there are some users who are going to be interested in like how passive this works.

So also giving them an option for more in-depth learning through, you know, if you wanna learn more click here, those types of interactions. But I do think we have the existing user experience patterns and frameworks today that can support passwordless quite well. So I think it's a matter of leveraging those patterns and kind of getting users used to it. And then as more companies do this at scale passwordless will kind of just become the, the default amen or something.

Okay, well, it's getting close to the top of the hour, but there's one more really good question here. I wanna take this one. Is friction actually dependent on equilibrium being achieved between the actual threat experience or realized by users?

Yeah, I, I think that's a great question. It's definitely one to think about for, you know, how you design this passwordless experience and not to get too deep into, you know, thread versus risk. But I think really it's, it's on the risk side here where, you know, friction is appropriate as the risk level increases, not necessarily the threat, but let's say what's at stake from a service provider side.

If you, you know, I always like that high value transaction example, you know, maybe, maybe the threats around a user using a mobile banking app or are the same, regardless of the value of the transaction, you know, maybe, you know, a $10 transaction doesn't pose as high, a risk as a $10,000 transaction. So I think the friction has to be matched with the overall risk level.

Any, any parting thoughts on that or anything else? Jamie? I think frictionless by default friction when needed is a really good mandate to live by when it comes to friction. And that necessity depends on the type of application industry you're in, but that necessity is determined by risk, as you said. Yeah.

Well, great. Thank you. Thanks J for your participation and thanks to everyone who submitted really good questions today. This has been a good session. I think.

Any, anything else to add before we close? No, thanks. This is great. Okay. Well thanks everyone. And like I said, the recording should be available in a few days, along with the slides. Thanks for attending and hope to see you on the next event.