Adopting Passwordless Authentication for Modern Enterprises

Hello everyone, welcome to this KuppingerCole webinar on enterprise passwordless authentication. I am Guillaume Teixeron, Senior Analyst at KuppingerCole. Today's session is based on my latest leadership compass on the passwordless authentication B2B market, and at the end of my presentation I will be joined for a moderated conversation by Dave Taku, VP of Product Management at RSA. Hello Dave. So let's start. A little bit of housekeeping information before we start. You are all muted, don't worry, no need to mute or unmute yourself, everything is under control.

Pause, there will be two pauses along this presentation. You will be able to participate with filling your answer in the panel in the livestorm tool.

Q&A, there will be a Q&A session at the end of this webinar. Make sure you participate, happy to answer, feel free to fill in your question in the livestorm control panel. And finally, everything will be made available for download in the coming days. I don't know the exact date, but in the days to come. So you will have everything including recording and slides. So let me start by getting your attention with two numbers. Two Airbus phone calls over half a billion dollars in losses.

In 2023, attackers called the Las Vegas MGM Resorts, IT Airbus and impersonated an employee. They convinced the support staff to reset multi-factor authentication. The breach cost MGM around 100 billion dollars. In April 2025, the same playbook was used against Marks and Spencer in the UK. The estimated profit recognized by the company exceeds 300 million pounds.

Now, here is the part most people miss. Not a single password was cracked in either attack. The attacker didn't break authentication. They went around it through the recovery flows. Most organizations in this digital virtual room have certainly deployed MFA. Many of you have deployed passkey probably. And most still have an Airbus recovery flow that would have failed in the exact same way. That is the uncomfortable truth I want to start with. Because passwordless without recovery hardening is just theater.

Here's what I want you to take away from the next 25 minutes before I bring Dave from RSA for a practitioner perspective. First, I want you to understand where this market actually stands in 2026. Not where vendors say it is, but where buyers experience it.

Second, you will be able to evaluate solutions on the dimension that now matters most. I will give you three points. Why passkeys are now the baseline and not the differentiator. Why recovery is a real test of any passwordless project. And why device trust and adaptive risk now belong inside the authentication decision itself. And finally, and this is the practical one I want you to live with, you will know which question to put in your next RFP. If you only stay for the next 20 minutes, 25 minutes, you will live with all three. So let's start from there. Here is where the market stands.

Passwordless authentication has shifted from emerging best practice to structural requirement for enterprise identity security. That is the conclusion I want to learn first. Four forces are driving this shift.

First, phishing-resistant authentication is now the minimum acceptable level. OTP, SMS, push-only MFA no longer meet most risk and compliance requirements. In a report very soon, and the report was the Data Breach Investigation Report. In one of their report, they confirm it. Stolen credentials remain the number one initial access vector of breaches at 22%. The second point is that passkeys have moved from novelty to baseline. They are supported across all major operating systems now. The adoption barrier is no longer technical.

The third point is the fact that zero-trust programs have raised the bar. Authentication is no longer a single moment. It must combine cryptography with continuous contextual verification. What was a differentiator years ago, two years ago, is now considered standard. And vendors who have not evolved are visibly falling behind in the leadership combat. And there is a fourth force, naming regulation.

In Europe, EIDAS-related initiatives align public sector identity program with phishing-resistant assurance level. In the US, NIST has formalized AM2 and AM3 requirements that now explicitly call for hardware-bound phishing-resistant authenticator. In financial services and critical infrastructure, sector-level regulations are increasingly referencing this framework directly in their criteria. The practical consequences for buyers in regulated industry, in the industry, in banking, in telco, and so on, is that being passwordless is no longer purely a security decision.

It's a compliance obligation. And that changed the procurement conversation. Beyond that, even if regulated and large enterprises are leading investment, we see that mid-market adoption is now also accelerating. As cloud-delivered and OS-native capabilities reduce the implementation, everything is there to accelerate. This market is not broadening.

Sorry, this market is broadening. It's not narrowing. It's expanding. But adoption is uneven. On one side, what is now mature, you do have the success, the modern web application, the managed Windows and macOS endpoint, file-to-server availability, the easy half of the estate is largely sold. This is there. This is a problem. It works. But on the other side, you have what is still hard to tackle.

All the legacy applications we are all running since years, Reduce, VPN, VDI, shared workstation, the management of contractors and partner access, and obviously at the bottom of the list, the most critical, the recovery. So the enterprise passwordless conversation is no longer about authentication method per se. It's about recovery and assurance across the full estate. And I'm curious to know where is your organization today on its passwordless journey. So here is a quick poll. You can see the option on your screen. Take a moment to answer.

Your responses will tell us where most of you actually are, and I will reflect on the results in a moment. So where do you feel that your organization is today? Still passwordless with MFA, fast key deployed for some application, passwordless across most workforce access, fully passwordless, including recovery. Okay. So let's move with the triple advice I wanted to give you, and let's start with the first one. You should treat fast keys and 502 as the minimum, not the differentiator. Three pieces of evidence to support that statement.

If you read the leadership compass, virtually all leaders now ship 502 and web of fast keys alongside platform authenticators, like Windows Hello, Touch ID, Face ID, Android biometrics. All of them. Second one, second point supporting that statement, operating system level fast key operating system level fast key support, it has removed the historical adoption barrier. The fact that all the operating system, the major operating systems support fast keys, the barrier is gone. Let's be honest. The question is no longer whether user can use fast keys. It is whether the enterprise can govern them.

And the third point is that OTP, SMS, and push only MFA are explicitly called out as no longer sufficient for most risk and compliance requirements. So what? So stop evaluating vendor on whether they support fast keys. Evaluate them on how they govern fast keys at enterprise scales. So what does that mean? What governance of fast keys actually mean? Four different things. Four different pillars should be used to answer that question.

First, the environment. Credentials should be issued against a verified identity, not via anonymous self-service. Wherever you bind that fast key to, you need to know who they actually are. Device binding. Credentials must be cryptographically bound to hardware-backed key storage.

TPM, secure enclave, or equivalent. Without this, you do not have phishing resistance. You have a stronger password, and that's not what you want. Lifecycle. The automated provisioning and deprovisioning across managed device and personal device. When someone leaves, their access goes with them without negotiation. And the fourth one, recovery, which is the next line because that is where most projects quietly fail. So let's focus a little bit on recovery. That's my Power BI 2, and this is where I want you to lean in.

If your recovery flow uses a password, an SMS, or a security question, you are not passwordless. Three pieces of evidence to support that statement.

First, post-mortem breach analysis states explicitly that most authentication failures occur during onboarding, re-enrollment, or recovery, not during regular login. Second, many vendors still allow fallback to email OTP, SMS OTP, or knowledge-based questions during the recovery flow. The moment you do that, you have reintroduced the phishable factor that passwordless was supposed to eliminate.

Third, and this is the operational reality, helpdesk-driven recovery is now an active attack vector. The group behind the MGM, and Marks and Spencer attack, and many others, they succeed in almost every public 2025 incident by calling the helpdesk. So what? So you must evaluate passwordless projects by the strengths of their recovery and lifecycle control, not only by their authentication method. And there is a corollary to the recovery program that I want to name, because buyers frequently miss it. If enrollment was weak, your recovery cannot be strong.

Several leaders in the leadership compass have built identity proofing directly into their enrollment workflow. Needs to align onboarding, or government ID verification, or some sort of biometric proofing, but at the moment, the user first buying their credential. The logic is simple. Recovery is only as strong as the identity you can verify at re-enrollment. If you enroll with a corporate email confirmation, your recovery will rely on the corporate email confirmation, which is phishable, which is TIA.

The vendors who close this gap are the ones who treat onboarding and recovery as two sides of the same identity assurance problem, not as a separate helpdesk workflow. The RFP implication of that is that you should ask vendors what identity assurance level they target at enrollment, not just at login, and what recovery pattern they support.

Because, according to me, three recovery patterns enterprise should now require. The first one, the verified device rebinding. Re-enrollment is gated by possession of a previously trusted device or other authenticator. The user proves they still control the original credential, so they can recover.

Second, identity proofing bake recovery. Government ID verification or biometric reproofing replace knowledge-based questions. The recovery becomes as strong as the original onboarding. And the third one, the policy control helpdesk assisted flows. The helpdesk is involved, but the process has administrative oversight. Audit trace, out-of-band verification, and clear escalation. Not a self-service form filled with old and so on. These three patterns are the difference between a passwordless project that holds and a passwordless project that becomes a 1 million dollar headline.

The third power point I want to share with you is that authentication is no longer a single moment. It's a continuous decision. Strong cryptography alone is not enough. Device posture and contextual risk now decide whether or not to Strong cryptography alone is not enough. Device posture and contextual risk now decide whether a credential is honored or not. The first evidence of that and that is identified in the leadership compass is that the device trust and posture are core elements of the passwordless authentication. Not optional add-ons. Core.

The second one is that adaptive risk engines that evaluate IP replication, geovelocity, device health, behavior, anomalies, name it, are now standard among the leaders. The vendors who don't have them, they are visibly behind. The third evidence I want to share with you is that integration with MDM, UEM, and EDR determines how reliably you can distinguish a managed device from a personal device from a shared workstation. And without such integration, your policy is simply guessing. So what to take from that?

So as a buyer, you should require device posture and adaptive risk as part of the authentication decision itself. Not as a separate access control. It should be included. It should be part of the solution. And this brings me to a capability the leadership compass calls out as a meaningful differentiator between the two. The leadership compass calls out as a meaningful differentiator among vendors, that is orchestration. A mature passwordless platform does not just evaluate signals. It acts on them through configurable policy joining.

A user logging in from a managed device, from LC device, on a trusted network, at a normal time, passkey alone. That's fine. The same user on an unregistered device from an unusual location, step up, additional biometric confirmation or blocking. Vendors have invested heavily in what the leadership compass calls journey orchestration. This is the ability to design these flows without writing code. Conditional access rule, multi-stage authentication, recovery procedures, all configured through policies, not through engineering, tickets, integration, development, blah, blah, blah.

The buyers who get this right stop thinking about authentication as a control point and start treating the authentication as a policy surface. Every authentication event becomes an enforcement moment, not just an identity check. And for architects in the audience, if any, the question to ask is whether the platform exposes the policy engine you own or whether you are locked into vendor-defined flows. And that's a very important question to ask. Three buyer questions you can take into your next RFP based on that. The first one, how does the vendor evaluate device health and binding?

And especially, does it work consistently across managed, personal device, and shared workstations? Because vendors will demo on managed windows, but the R scenarios are the rest. The second one you should bring with you, which contextual signals does the risk engine actually consume? IP reputation, geovelocity, device posture, behavioral anomalies, and critically, can policy act on them in real time? Can you allow step-up denied automatically at the moment of the authentication? These are questions to ask. And the third one, how does it integrate with your existing stack?

Your MDM, your UEM, your EDR, your SIEM, natively or through custom work? Because the answer determines whether you deploy in three months or in three years. That being said, I would be curious, you knowing what I just introduced for the moment, which of these is the biggest gap in your current authentication strategy? As you wrote, let me share what I expect and what we tend to see in that vis-a-vis work. Most organizations underestimate gap number three, recovery and enrollment. But I'm curious to see what is for you the biggest gap at the moment.

The phishing-resistant method deployment at scale, the management of the device, trust, and posture, your recovery and enrollment, or your capacity to play with adaptive risk and contextual access. Wherever you place your vote, the next two slides give you the inline takeaways and the action to work out with.

So, three things to take with you. If you remember only three things from this session, remember this. Phishing resistance is the fraud. Select vendors on how they govern, pass keys, not on whether they support them, because they must. Recovery is the real test. A passwordless project that recovers with a password is not passwordless. And the third one, authentication is now a continuous decision. Device trust and adaptive risk belong inside the framework. Before I conclude, let me give you one market observation that will shape how you read the vendor landscape.

So, the leadership compass identified 50 overall leaders in this market. This is a large number, and looking across them, a clear superposition of the top 50 50 overall leaders in this market. This is a large number, and looking across them, a clear superposition has emerged between two buying archetypes. The first archetype is the platform consolidator. Vendors who embed passwordless directly into their broader IAM suite. If you already operate their platform, adoption is lower friction.

The trade-off is that passwordless becomes one capability among many, and the assurance depth may be shallower than a dedicated solution. The second archetype is the specialist. Vendors who are built specifically around high assurance device-bound passwordless. Their differentiation is depth. Tighter posture integration, stronger recovery hardening, more granular credential governance. The trade-off is integration work alongside your existing IAM stack. Why does this matter? Because when you evaluate vendors, you are not just evaluating features, you are also choosing an architectural question.

Add onto your existing platform or introduce a dedicated authentication thing. There is no universally right answer to that question, but the question belongs in your RFP because you see the first demo. I will finish on that slide, and I will give you two concrete actions I advise you to take for next Monday morning. The first one is audit your current recovery flows. Map every fallback factor. If any are fishable, that is the first project, not your next RFP, your current testing. Second one, add the three bias questions from this session to your next RFP.

Passkey governance, recovery patterns, device trust integration. And three, use the leadership compass as a starting point for shortlisting and pair it with a proof of concept against your actual estate, including the legacy and shared device scenarios. The vendors who demo well or manage windows are not always the ones who survive contact with reality. This is my analyst view of the market, and to bring this back to the operating reality, I would like to bring in Dave from RSA who has been working with enterprise on exactly this question.

Dave, welcome back. Give us a little bit of an introduction of you and your job at RSA and present us where you sit at RSA, what has changed the most in enterprise passwordless conversation over the past months, and what has surprised you?

Yeah, well, happy to, and welcome everyone here to the webinar today. So RSA has been, for the last 35 years, one of the leaders in multi-factor authentication and now passwordless solutions.

I think what's unique and maybe a perspective that Yeom I can bring in this conversation is that as the vice president of product management at RSA, I've had the opportunity to work with and consult with hundreds of different customers, enterprises, nationally, internationally, of all sizes on their passwordless journey, but even more so as RSA, you know, we take this very, very seriously and we are our own first and probably most difficult, challenging, and demanding customer.

We embarked on this passwordless journey ourselves, and over the course of about six months of time, we were able to get to a point where today we are about 94% passwordless for all users and use cases across RSA, right? So, I mean, we've lived this, we've breathed this ourselves, and so I can bring a perspective not only as a vendor and a consultant of authentication solutions, but also as a practitioner helping to roll out these solutions and as an end user, right? And I do think that the end user perspective is very, very important.

It's something that I'd love to dig into a little bit more as we go, you know, through this particular conversation. As far as what I've seen in the market over the last 12 to 18 months, I think you hit on something really important, right? FIDO has really reached the stage of maturity within the market today, and I think there's a couple of key things that are really driving that. Not only is FIDO now ubiquitously supported across all major web browsers and a lot of the operating system platforms, but I think there's been two significant changes over the last 12 to 18 months.

First is that FIDO historically was really the domain of hardware authenticators, right? I mean, you saw a lot of hardware token-based solutions, and yes, the FIDO specs did have the UAF standards, which allowed for interaction within a mobile app, but the ability to use your mobile phone as an authenticator, as a companion device authenticating to other systems, which is something that people have become very familiar with in the MFA world, was not possible until very recently with the addition of the hybrid transport specifications in the FIDO.

So now the ability to use either a mobile device or hardware authenticator really opens up, I think, FIDO technology to the masses and a much broader set of users. I think the second thing that I've seen is that FIDO has now really hit mainstream within the consumer world, and much like we saw with technologies like Face ID and Touch ID, as users become more familiar with using these technologies in their personal lives, the ability then to adopt those within the enterprise becomes much, much stronger and much easier. And so today, I think FIDO has actually done a fantastic job on this.

If you're interacting with a mobile app and you go to your favorite consumer service, whether that's an Amazon or an eBay or something like that, and you're asked, well, would you like to use Face ID next time you log in instead of a password? You say, yes, I would. What many people don't actually realize is that Face ID is just the first factor unlocking the FIDO passkey underneath.

So I mean, FIDO passkeys are very ubiquitous in the consumer world. And it's interesting to see now, even like my father was asking me about passkeys the other day, right?

I mean, this is something that's become mainstream, and those things are all helping to drive adoption within the enterprise. We're also seeing that even within the FIDO Alliance, the FIDO Alliance now is starting to focus much more on enterprise use cases. And RSA is a co-leader within many of the workforce specific sub-working groups within the FIDO Alliance to help drive the necessary supporting standards, things like how we handle recovery and how we handle secure enrollment to really make this an enterprise-grade solution.

So I think one of the things that's really surprised me the most so far is that, I think similar to your poll, it'd be interesting to see the results there, is that as I speak with customers and even at the CISO level, I think everyone today now is saying, yes, we know we need to go passwordless, we know the phishing risk is real, we know we need to do something about that. But I think a lot of folks are still struggling with how to take the first steps of that journey. They're looking to their peers, they're looking to others for advice.

And so that's why I think a webinar like this is so valuable today. That's very interesting to hear. And when we discuss with large enterprise that they do not run a single user population. They have employees, contractors, frontline workers, privileged administrators, or whatever. So from a product standpoint, what does it actually take to deliver phishing-resistant authentication consistently across all of those different populations in a coherent manner for those enterprises? So it's a challenging problem. It's one that even we RSA face as we are rolling out passwordless internally.

If you have a workforce employee, it's much easier to dictate particular terms or even to justify the investment of a hardware-based passkey. If you're working with contractors or external parties, that becomes more challenging, not only the cost aspect of a hardware authenticator, but also secure distribution and management of those keys and recovery of those when people are on a short-term contract. And so having that range of authentication options I think is really important.

So as I mentioned earlier, hardware authenticators and mobile passkey options provide a lot of additional flexibility. I think the other challenge that large enterprises are seeing today is that a traditional large enterprise may be using a lot of SaaS applications and services fronted by web services on the front end, but there's also a lot of legacy infrastructure in those environments.

And so whether these are servers in your data center, your IT or your OT infrastructure, or other legacy applications, there are a lot of use cases in which it's not necessarily easy to use something like a FIDO passkey technology. So one of the things we had to look at, and we advise our customers on as well, is to understand what your phishing risk is in those various different environments, and don't settle for a password. If FIDO is not possible for a particular use case, settling on password is not enough.

There are other multi-factor and passwordless options that you can use to help plug those gaps. And so for example, if you're looking at a mainframe infrastructure within a data center, the phishing risk or attack surface there is much different than it would be for a SaaS-based application. So something like an OTP, for example, may work very well in that type of environment, and it doesn't have the same level of phishing resistance as FIDO, but is certainly far better than a password.

And if it's a time-based OTP, then that attack window would have to be a very specific spear phishing type of attack, and have to be able to leverage that in real time, right? So use FIDO wherever you can, but if you can't, then use something equivalent. So where that becomes interesting then is that if you have users in your population, and some have hardware, some have mobile, and you have some applications that are FIDO, others are using OTP, user experience is where the rubber hits the road, where the real challenge comes into play.

So when we rolled out these solutions internally, we did an experiment on ourselves, right? We knew that ultimately where we are today is we're FIDO everywhere we can, everywhere that's possible to use FIDO, we're using FIDO. But at first, we made every authentication method available to every user just to see what would happen. And we knew what was going to happen, but we played out the experiment anyhow. Sure enough, people got very, very confused that, you know, the experience was different every single time they went to a different application.

And so what we kind of really settled in on that was there seemed to be sort of a nice complement between a couple of passwordless authentication methods. Again, FIDO wherever you could, but then also QR code and OTP. Those three seem to naturally kind of work together, particularly OTP and FIDO, because you can have a hardware authenticator that supported both methods, you can have a mobile authenticator that supported both methods. And if you implement it correctly, you could have a unified user experience where the user really doesn't have to think about the underlying technology.

So imagine the user experience, I come into an application, I'm asked to authenticate, either I pull out my mobile phone, or I stick in my FIDO passkey, security key, and I'm asked to enter a PIN. And from there, the technology magic happens, right? It doesn't matter if that magic is a passkey interaction, or if it's an OTP submission, we can make that experience such that it's invisible to the end user, right? So we're using technology to apply the right credential in the right place, but the user doesn't have to think about that.

That was a really, really important part of us being able to drive successful user adoption within our enterprise. Yeah, there is no one single solution. There is a portfolio of solutions, and you should pick the best one for the best application. Right. And one of the points that I try to make in my presentation is about the recovery flow.

That is, for me, where most of the projects face when we talk about passwordless. They want to eliminate the password, and at the end, they use the password to recover from a passwordless solution. So I'm curious about your point of view, and whether a recovery flow that doesn't break the passwordless promise actually looks like in practice, according to you.

Yeah, so I really appreciate your presentation, right? Because this is something that, as Arash said, we've been saying for years, that phishing resistance is the first step. But in order to really secure the passwordless ecosystem, you need to go beyond phishing to address a number of other factors, right? And so the recovery, the enrollment, these are the types of what we call bypass attacks that we've seen at MGM and in other places where attackers don't need to steal a credential. They don't need a hacker credential, right?

They can just request a credential, whether that's through a self-service portal or by compromising the help desk. So this is a narrative that I would say, as we've spoken with our customer base, has really, really resonated. Regardless of where folks are in their passwordless journey, they realize that they're already behind the eight ball because the attackers have changed their tactics and are going off of these weak enrollment processes. So there's a couple of things I would say, right?

And you laid out, I think, some good recommendations of options that you can begin to use, whether that's identity verification or some sort of a secure device rebinding. A couple of things I would say. Number one, your enrollment process and your recovery process has to be multi-factor, right? It can't rely on a single factor and it certainly can't rely on a factor that's knowledge-based.

I mean, not only if we think passwords are bad, right? It's even worse when you go to a help desk interaction and you're using knowledge-based questions, like what's your manager's name or your employee badge ID, right? So we have to eliminate those from the equation. So anywhere you can use multiple factors.

Now, I'm not a fan of SMS OTP or email OTP, right? I mean, those things are very, very weak, particularly when used in isolation. But if you have to use a known phone number or known email as one of multiple factors, it's still better than just using a password, right? And the other thing that, as you talked about, continuous authentication, the ability to use risk-based context as part of that interaction, I think, is really, really important as well. So it's really all about a defense in depth type of strategy.

If you can go back to something like an identity verification, I think that's fantastic, right? But there is certainly a burden or a load on end users to have to have a password or driver's license and go through that type of a process for recovery. And depending on your risk profile, that may be what you need to do. But there are other ways of being able to match multiple factors plus risk to be able to achieve that as well.

Now, one of the most interesting areas is definitely the help desk, right? Because when you're in a self-service portal, you're doing things electronically, you have certain tools available to you. Classically, when you're talking to a help desk, whether that's over a telephone or via Teams chat or Slack chat, you don't have as many tools available to you to be able to do that, right? And so there's two different attack vectors that we see.

Attackers pretending to be end users requesting credentials from the help desk, and also attackers pretending to be the help desk contacting your end users and tricking them into providing their credentials. So it's really important that whatever solutions you use, and RSA has rolled out a solution called LiveVerify, for example, that is able to do bidirectional authentication, authenticate the user to the help desk and the help desk to the end user, and to do that electronically using the means that you would have similar to an authentication or identity verification flow.

And so we've seen those types of solutions to be very powerful in terms of plugging those particular gaps within the recovery process. Okay, good to understand. I hadn't thought about the two-way authentication. You go both ways, yeah. And that's true because, yeah, someone tried to call me pretending being my bank, but that's the same thing with help desk. They can pretend to be the help desk.

Yeah, and you talk about adaptive risk, and that's also something I mentioned in my presentation, but I advertise and I talk about that for years, but I think that there is a kind of momentum around that. But from a product perspective, what is the hardest part of getting that right at scale? Because this is not simple to move from yes or no authentication to adaptive authentication. There is a kind of philosophical gap around that. And so from your side, how do you see that? How do you pitch that? What do you see as a journey for the future?

Yeah, so I think there's a lot of moving parts involved, right? So many solution providers today, including RSA, will have risk engines that use things like behavioral analytics and conditional variables to understand the risk level of a user attempting to access a particular resource. The problem there is that authentication is a front door, right? So once a user passes through a front door, typically these authentication systems lose visibility. So you mentioned things like device posture, right?

These are very important sources of input into these authentication products to understand a level of risk associated with these solutions. Now, if you have something like a managed Windows PC or managed Chrome browser or Edge browser, then you have tools available to be able to extract that information from a posture perspective or your MDM. When you deal with unmanaged devices, which is far more common when you talk about mobile authenticators, that's where things become a little bit more challenging.

And so one of the things RSA has done is we've taken mobile threat detection technology and embedded that directly within our authenticator app as a part of a solution called mobile lock so that we can do device posture even on unmanaged mobile devices. But I think where the industry is going is in order to get to continuous authentication, we really need to have a better understanding of what happens after the user passes through that front door, right?

So I'm really excited about a lot of the work that's going on right now around the shared signals framework and more vendors beginning to adopt this particular standard, which will allow more of your security ecosystem to share information with each other around risk in a standards-based way, right? So imagine, if you will, an authentication product like RSA, we evaluate risk as the user passes through the front door, everything's fine, but after that user passes through that door, they start doing really weird things within that target application.

We want to be able to know about that so we can not only terminate that session, but if we're involved in a single sign-on solution as well, that we may want to terminate other sessions associated with that user as well. We maybe want to be able to report that activity to the SIEM. We may want to flag that within a governance system for account review.

And so that ability to share information within the ecosystem has traditionally been one of the most difficult problems out there, but with shared signals framework, this is something that hopefully over the next couple of years has become far more standardized, and that's one of the things I'm most looking forward to here.

Okay, but one of the things I see about the continuous authentication concept and adaptive risk and so on, it works very well for the last generation of application and so on, but as everybody, we have to deal with legacy application, with our former reduced authentication, authenticated application and VPN and so on. So for all of those legacy ecosystem, if I may say, how realistic is it today to bring those systems into a passwordless solution? What is the gap to switch to an adaptive risk model?

How do you see that the people transitioning to more modern authentication, that is a requirement today? Right, yeah. So for legacy systems, it's far more challenging to do things like risk analytics. A lot of what you see of these risk engines today are really assuming a browser interaction, the ability to pull information through the browser.

Now, if you have a radius channel, you get zero information about what's going on on the client side, other than a username and a password or an OTP or something else that you've submitted through that channel on behalf of the user. The good news is that if you take a look at your overall ecosystem, 90% of your users aren't using those applications, right? You have privileged administrators, network administrators, other key people. So if you can begin to sort of assess and refine, you can limit the scope of where those types of situations exist.

And we found that at RSA, very similar to that, it was only less than 10% of users who were really involved in those types of legacy applications. At that point in time, then you want to do the best that you can, right? Apply the strongest forms of authentication, even if FIDO is not a possibility in those particular use cases. But then you also want to look at how you're going to manage and migrate those solutions over time.

So it may not necessarily mean migrating a legacy solution to a cloud, but even if we can change the integration point from being radius-based to an agent-based, for example, that agent code then provides a vendor with more ability to collect at least basic intelligence information like IP address and do geolocation and other things based on that, right? So there is a migration path even for some of those legacy applications. Okay.

One of the points I try to make is the importance of identity verification before the passwordless journey and everything around government ID checks and biometric proofing and so on. How do you see that? Is that discussion you do have in parallel of the passwordless discussion you may have? Is it well understood that it's, and maybe it's only my opinion, but that's the foundation of starting your passwordless journey because you can only prove an identity that is strong enough at the beginning.

So it is something that you need to account, it's the same conversation or you push that message on the side of the passwordless journey? Yeah, so it is a very important part of the story and it's a conversation that we do have with all of our customers as we look at how we go to beyond phishing and protecting against bypass attacks and other things like that. Identity verification solutions, there's a number of them on the market today. They have very broad coverage now where virtually whatever country you're in, you have the ability to use government issued documentation.

I would say that it does put some burden on the end user. You have to be able to find your passport. Most people don't have that on them every day of the week. So for a credential recovery use case, it becomes a little bit more challenging. For initial onboarding, it's the same thing that you would do when you join a company and you get vetted by your HI department. So I think it works really great in those onboarding use cases. Now what we are seeing and I think the next level of this is this move towards verifiable digital credentials.

We see a number of projects within the EU like the IDaaS project that is starting to standardize different types of verifiable credentials. But I think that's going to make it much easier for end users to be able to participate in these processes and then also to be able to have control over what information they share and only sharing what is necessary as part of that onboarding process. So I do think that as these types of solutions become more ubiquitous, that the identity verification process is going to become much easier.

Yeah and I agree with you and identity verification to me will be where passwordless is today. I mean it will be a standard for everyone in the next months or years to come. Maybe a last question before we switch to the final question. If you were on the buyer side this time, what you would prioritize that organizations constantly underestimate according to you and what would be your first topic you would tackle if you would be in the user side of the equation? Yeah so I think I've seen two different broadly speaking two different types of behaviors out there.

I've seen some organizations that have said yes we must go passwordless. They jump straight into it. They roll out FIDO for their SaaS applications. They're very successful but then they get stuck because they don't know where to go next with that. And they may have chosen a solution for FIDO pass keys, not thinking about those next steps of credential recovery and enrollment and identity verification or even how to apply equivalent solutions to legacy applications within their enterprise.

The other type of scenario I've seen is one in which an organization does recognize those, kind of gets a little scared or overwhelmed by the options available and then they get paralyzed and they do nothing. So our advice has really been don't try to boil the ocean. Start small. Start with your most critical and exposed assets. So it's great to start with SaaS. Those things are outside your perimeter. Start with perimeter security, your desktops and your laptops, particularly if you have users who work remote or carry sensitive information.

Work your way back in to the center of your environment. Once you get in the data center, far more secure and far fewer number of folks who are touching that. So start outside in, plan your journey, understand where you're going, but don't let perfection be the enemy of good enough. If you can't apply FIDO today, that's fine. It's not an excuse for staying with passwords. There are other options available to you to help you bridge the gap. That makes sense and I agree with that. Now we are on schedule and we have a few questions in the Q&A, so we are going to try to tackle them.

The first one from Richard, while passwordless may be the future, the current market for password managers has grown from 500 million in 2007 to 3 billion in 2022. How would you encourage people to move away from passwords? What should security experts advise non-technical people? This may be a controversial statement on my part because I think most people in my profession would probably say stay away from password managers, they're terrible, they're still using passwords.

Again, I'm going to go back to start with FIDO, use FIDO wherever you can. If you can't use FIDO, use other forms of multi-factor authentication, work your way backwards, but whatever you do, at least do something better than passwords. So I think password managers, you got to be very careful with them. The plus side of that is that they do encourage end users to create more complex passwords that are harder to brute force, but they don't stop the smash and grab attacks.

I mean, if you're using a password vault where these are being all stored centrally on the cloud, you're just setting yourself up for a potentially very bad day if that gets breached. So there are some solutions where they're local vaulted, they're encrypted by keys that the end user holds, but just be aware that brute force attack probably isn't the thing that you should be most concerned about.

I mean, just even this last week, there was the ransomware attack on Canvas here where 8,000 universities in the U.S. were held ransom, right?

I mean, those big centralized databases of IP is what people are going after. So password managers do nothing against those types of smash and grab attacks.

No, but they are still very convenient for the average user. They are still there and they were growing so fast.

Yeah, and so one more thing, also you need to be very careful of some of these consumer-grade password vaults, right? I mean, if you think about what Google or Apple offer today, right?

Very, very convenient, but those are synced to a cloud. They're synced to every device that are registered to that user account. So if somebody gets my iCloud password and then enrolls a device with my password, they get instant access to every key I've ever stored in there, every password I've ever stored in there.

Yeah, and synchronization is a very good transition with the second question from Richard, who said, what are your views on... I didn't even see it. And does RSA provide a solution to manage the syncing of passwords?

Yeah, fantastic question, right? So this is one of the reasons why RSA has really been a leading voice for workforce use cases within the FIDO Alliance, because many of the, you know, the key sponsors and, you know, largest companies in the FIDO Alliance are really looking at this from a consumer perspective, right? And so from a consumer perspective, syncing pass keys is incredibly valuable because, you know, end users tend to change devices, lose devices, use multiple devices, right? So it's very much a convenience play.

I think what a lot of folks don't realize is that when the FIDO Alliance first started, the goal was not to improve security. Like phishing resistance kind of came out of that and is now the, you know, the hallmark of FIDO, but it was really about shifting liability, right?

I mean, these vendors who started this did not want to be victimized by smash and grab attacks where they hit the news, 40 million passwords stolen. So they said, let's make this the end user's problem. In an enterprise environment, making it the end user's problem is not acceptable. It's not the goal. It is security, right? So with an enterprise environment, I would be very, very careful about sync pass keys, you know, so there is now most products will support ability to, you know, leverage metadata from different FIDO pass keys and set policy controls over, do I allow sync pass keys?

Do I not allow sync pass keys? Now there is still some gotchas and some things that we're trying to work through with the FIDO Alliance where particularly on iOS devices, I mean, Apple is really focused on convenience above all else. So iOS actually masks some of the attestation attributes from a mobile pass key that allow platform vendors to tell whether or not it's a synced pass key, right? So this is one of the challenges that, you know, we're still trying to work around. FIDO still has a little ways to go, right?

But again, I think it's, you know, reached a very important, you know, milestone in the last 12 months or so in terms of maturity of broad stream adoption. I agree with that. And maybe the last question, because we have only three minutes left, pass keys are getting a lot of attention right now. Is this genuine progress or mostly marketing? I think it's a progress and more than marketing.

I mean, everybody does for pass keys. Let's say, as I said in my first point, it's a standard. It's not a question of if. It's a question of how do we do we manage that and how do we use that and deploy that.

But yeah, Floyd, I'm laughing because I mean, honestly, I do think that, you know, FIDO Alliance has been one of the most, you know, amazing marketing machines over the last couple of years, right? They've got phishing resistance on the tongue of everybody out there, right? But I mean, for good reason, right?

I mean, they've identified a real problem that resonates and have worked very hard to address that problem, right? So while I do believe that, you know, FIDO Alliance has done a fantastic job marketing the problem and influencing RFPs and influencing regulations, the flip side of that is true as well, right?

I mean, this is absolutely genuine progress. You know, RSA, even though we sort of invented the OTP authentication mechanism, we are 100% fully behind, you know, pass keys. We are board members of the FIDO Alliance is the primary authentication method that we use and promote today. And I think it's absolutely fantastic where the technology is going. Thank you. Thank you for all your answers and your participation.

Thank you, Dave. And thank you all for assisting to that call. It was a pleasure to be with you, Dave, and to chat with you. We'll see you here, conversation. Thank you. Have a good day, everyone. Bye-bye. Thank you.