Trends in Passwordless Authentication for CIAM

Thank you. Hope everybody can hear me. Okay. So Passwordless trends, very interesting topic. I will not, you know, talk about more about, you know, how Passwordless is very good for you, right? But what is important to understand is there are multiple different methods when it comes to, you know, going passwordless in your organization. So I'm gonna peel the onion a little bit, you know, and talk about what are the different trends that we see? What are different problems that we see in the industry? How did we arrive at the different methods of passwordless? And then dive a little bit more deeper. And I have a demo as well to showcase that to you, right? So let's take a deeper dive into it. So first thing I'll just state, you know, the problem today, when it comes to on the customer side, two big problems that you did not see about five to six years back.
One was around account take code and specifically you're looking at account take code from your customers. All of you have seen multiple different attacks that are happening. You're getting bombed on your phones, on your email, trying to click, bait you into clicking a link, right? For them to take over your account. And then the second is more with respect to synthetic IDs. All of these problems that you essentially see are primarily with respect to the traditional method of login, which is a username and a password, right? And five years back, these account, these takeovers were limited, were not happening as much. Primarily because, you know, the hackers were trying to break in, they were trying to break in into your account to, you know, get access. Whereas now all they're doing is they're just logging in, right? Again, a statement that you know, we are often using, but just the context behind it is that your credentials most likely are available on the web where, you know, all a hacker has to do is just pick it up, try the lottery of, you know, which website they have to go after, right?
And use that to log in. So essentially when in, you'd look at these different methods that organization had, they said, let's introduce a much stronger way to authenticate, right? And then came in the mfa, right? MFA causes a little bit more friction, but I actually know who the user is that is logging in. I'm gonna send them an sms, I'm gonna send them an email with an OTP to log in. Lo and behold, right? You also see all of these attacks that have led to, from an MFA standpoint, if you an attacker is going after a targeted user that can still go ahead and, you know, get access to user's credentials. And if it's more from an organization or a service standpoint, if one of your employees are compromised, you essentially get, you know, your entire repository in a compromise as well. So just to summarize the traditional method of login, user password mfa, we are still seeing problems.
So the main reason behind this is today we do not know who's the user behind the glass. Right? Behind your laptop, behind the device who's logging in, right? And all of the, all of the behaviors that we are dis that we are talking about atos, you know, synthetic IDs are primarily happening because we just don't know who the user is in the physical world. This problem doesn't exist. You log in, you walk into any of the service, right? You can essentially say that, Hey, I am zafa, alright, let me know who you are, right? I can just take out my government issued credential and that's it. I'll get the service that I like. Right? We have created proxies, we have created band-aids in our digital process, which is primarily more with respect to, I don't trust who the user is, right? And let me see how I can introduce more methods to make sure that the authentication is strong.
So again, peeling back the onion, you'll see there are three different silos when you look at any kind of customer authentication, and I use the word silos and I'm emphasizing on it because they are all sitting in different buckets. The first one being, you know, when you look at any kind of registration that happens, registrations that may happen, and it may be just with respect to very seamless. Even if you're getting a user's email, you know, phone number and you start the digital journey, or depending on if you're a financial institution and you're doing a K Y C, you go through the more detailed process of identity proofing, document verification, taking a doc picture of your ID selfie. But all of this is sitting in a bucket, right? Which doesn't interact with the other two services which are there. So it's one time, one point in time to know, you know who the user is.
Second, when you look at authentication, right? That essentially says, I don't care about what the registration process was, you went through it, I created a username. Now let me just use that username to log in, right? Whereas I would rather leverage, right? How the whole registration process happened, right? And use the methods and utilize that for authentication as well. And then the last and the most important point, right? Which we are all trying from a customer standpoint, improve fraud. And most often, even if you look at team structures today in organization, fraud is sitting in a completely different vertical today. They come in after the fact, after the whole identity journey has been created, where fraud is essentially saying, I, let me analyze all of these patterns of login that is happening. Let me analyze all the different users who are logging in as well, right?
And then, you know, analyze the different trends and there are multiple different methods and tools that are very good at catching fraud. But maybe if there was a better way, you know, for login to happen, that will essentially even limit, right? Or eliminate fraud as well, right? So we have an a term that we've called, which is hope based authentication, which is what your process is today. You're hoping that the user who's logging in is the right user, right? Because you don't a, you don't know who the user is behind as well as you also are trusting the device that they're logging in from. So there's a lot of hope behind, you know, any of the authentication that is happening. But the new method that we are prescribing, which our customers are using today, is to look at two pieces of information, the identity and authentication.
So coming together in any kind of a login journey. And there are multiple different standards that, you know, prescribed to that today in, you know, we are based out of us. So we prescribe to the NIST 863 dash three when it comes to identity proofing and registration. We are also, you know, certified with, from a Fido standpoint, more with respect to how the authentication has to happen. But the idea being that when you are registering a user, right? You can essentially use that for any of your login processes. You can associate any of your fiber devices and your FI keys to the proof user. And at the same time, if you need to prove a user in your authentication journey, you can essentially, essentially use that as well. And we can demonstrate that right later in my, in my presentation. So all of these are different standards too.
Canara is the one that certifies with respect to the identity assurance level. So the reason why I have that is these are very well adopted standards which are out there today, right? So if you are looking for your vendors to, you know, go through this process, it's important that they're prescribing to these standards, right? And the last point I'll make on this one is that everything that I'm prescribing over here is when you look at user identity, you're looking at, you know, what the documents are that has a privacy concerns, you have to manage the user's information in a much more easier way, right? So just from an architecture standpoint, it's important to take that into perspective as well. You want to make sure that that architecture that is, you know, managing the user's credential is privacy, preserving the user's information is always under their control rather than the organizations or any of your providers as well.
So all of those limiting factors that you often hear that, hey, I need to introduce biometrics in my registration or my authentication journey. They need to be managed first, right? Otherwise, you know, you'll never be, you know, moving forward into this new method of, you know, how your users need to be logging in, right? So security are, I security is important too, but I also believe that all of us in the room, either if you are vendors or if you're managing, you know, our customer's data security is important. It is inbuilt, you know, in all of the different tools, but keep, make sure that it's privacy preserving as well, right? And you bring that into the equation, right? So what would that experience look like, right? There are two scenarios I'm gonna demonstrate to you, right? The first one is, how do you make your existing customers password less?
And that method is prescribing to, you know, what Fido has in place. So whereas an example, hopefully my video plays, it does. So if you have an existing service, you know, user is logging in with the username and a password, right? And then using, you know, their Fido key, this is in this case it's windows, hello. They can register and you know, get their Fido key registered as well. And this can apply to any other key that they have. If it's a Mac touch id, if you have a UBI key, right? You can prescribe to all of this, right? So once that has been registered, it easily provides that user the experience to say, Hey, now I know that you have a Fido key that is associated with you right now, log in, right with that specific Fido key. The reason I'm demonstrating this to you is you have not introduced friction to your users in this particular journey.
All you have done is given them an additional option to log in, right? Which makes them much more easier. They don't have to remember passwords, it's gone, it's a day, it's something in the past and it's allowing them to log in, right? Using a Fido key, right? And yes, there are geographies where they may not have a Fido enabled device. There are methods that they may, you may still have to use an otp, right? But you can still remove the username and a pass or a password at least, right? But you can just prescribe with a username for the user to login. Now, the question you'll ask me is, how's the secure, right? Where is the security? I need to know everything about the user to log in. And the reason why we do that is because it's essentially one big kit that we create where when a user, before a user is logging in, you're essentially asking them, I want you to prove who you are in every way possible so that now I can open up my services.
Whereas your point of entry, what we prescribe from a passwordless standpoint is that your point of entry has to be much more easy for the user to interact, right? And Fido is one mechanism to essentially do it, but then you run into the scenario that you know, I'm gonna open up my services a little bit, my next demo is going to demonstrate that where this is a sample bank and a user is essentially doing a money transfer. Right? Now I need to know who the person is. Yes, they have a registered fighter device, that's fantastic, right? But what if that particular device is compromised, right? I need to know who the user is as well. So based on that, you introduce additional steps of authentication and friction, right? To your users based on the interactions that they're having. So as a first example, again, I hopefully my video plays right, that the user is logged in into this particular service, right?
And by the way, what you're seeing on your right is an authenticator, right? That has this capability for them to approve any of the login requests. So the first scenario is a user is transferring money for the people in the back. If you cannot see, it's 4 99. So it's a small amount, but the user is essentially transacting, right? And then what you're doing in this particular scenario, I'm just not very good with my clicks, right? Yeah. Is essentially, and this one is 7 75, right? You're setting a login request, right? To your authenticator and all the user at that point is doing is face id. It's still device based if you compromise your face id, right? Yes, that's gonna be a problem. But you're saying I'm trusting at least the device that the user has, right? But I have a more sensitive transaction, right? And in this case it's a hundred thousand that the user is trans transmitting another request that goes out, right?
And what you will see is something that users, and I have to imagine very quickly, but we have something called a live biometrics, right? That shows up the idea being that when you're proofing and registering a user, right? Where you are saying that you know, I need you to scan your driver's license and your selfie, you can use that same biometrics to authenticate them as well, right? Or you can introduce your identity verification in this particular journey that I know that you have registered your Fido keys, I know you're logging in password less, right? But I need to trust you a little bit more, right? And this one time I need you to do identity verification and every other time that you're logging in, you have to just use your live selfie to come in, right? So what happens at that point is if you are introducing these methods of activity with your users, we have proven at least it increases adoption, right?
Adoption more with respect to logins, and at the same time, primarily from a fraud standpoint, right? You are knowing the user a little bit more, right? Which immediately has a lot of benefits too, right? And all of these are different authenticator options. You know, you just, the previous session was talking about ai, there's one more method to catch the activity, right? But before if you, if you have to catch it, there's behavior that you can bring in into the equation. So I gave you an example of a transaction of a certain value, but if that user is logging in from a different geography, from a different device, right? I can bring those behaviors in to introduce, right, what the different login factors can be, right? So this is just bringing this back from a summary standpoint that you know today, two big items, identity verification and onboarding as well as authentication, they need to be working together, right? Where you are trusting the user's identity in your authentication journey, right? Which will automatically lead to, you know, reduction on the fraud side, right? Rather than fraud working on its own vertical and trying to catch the bad guys right after the entire authentication journey that happens,
Right? So just two key challenges that we are looking to solve, right? One, the most important one, a very easy way to roll out, you know, what your passwordless is and that's where you know, PAs, keys 5 0 2 web, introduce it as much as you can, right? As your initial point of entry. And then is, you know, anytime when you have your business requirements that requires you to, you know, trust the user, bring in your identity verification flows in it. And I have a minute left, but you know, I'll take any questions. We are also up on booth 40 if you have any questions or if you need to see a more detailed demo, right?
Thank you. Yes. Any any questions? Any questions from the audience? If not, we have an online question. Yes. It sounds a bit vague, but is the question is are there any limitations in PA authentication
Limitations? Are there more with respect to how we implement it? Right? That's that, I know it's a very marketing line, but I would say that you know, today, as long as if you're knowing you know, what your user's journey is or your customer's journey is, you can introduce passwordless, right? There are multiple different methods to use it, right? And like I mentioned earlier, if 5 0 2 PAs keys are there for any organization to adopt and embed that within their flow, another important piece is always give the user the option, right? Rather than having a very broad stroke, right. That can be established as well. Yeah.
Well thank you so much. A round of applause.
Thank you.