Passkeys for banking: A conversation with CyberRisk TV
In this blog, we recap the discussion between Adrian Sanabria, Principal Researcher, The Defenders Initiative, and OneSpan CTO Ashish Jain at RSAC 2026.
This episode of CyberRisk TV is titled Why passkeys are ready for prime time in modern banking. It covers practical tips for banks implementing passkeys, including:
- Design and test the experience across onboarding, sign-in, and account recovery
- Nudge adoption over time
- Roll-out in phases
- Start with a single platform or region to gather metrics
- Strongly consider mobile as the first channel
- Plan to coexist with other authentication methods
Host: Welcome to RSAC 2026. I'm Adrian Sanabria. Joining me today is Ashish Jain, CTO at OneSpan. Thanks for joining me.
Ashish: Thank you for having me.
Adrian: How's your show been so far?
Ashish: It's been great so far, hectic, back-to-back meetings. I'm getting my steps done!
Adrian: Me too, definitely!
All right, so today we're talking about why passkeys for banking is primetime. It's ready for banking. I think maybe a year ago when I saw that Target defaulted to having you set up a passkey when you first created an account. I was like, okay, this is going to be a thing. It's time. What were some of the barriers we had to go through to get here? To be able to say, “It's time for passkeys.”
Ashish: I think over the years there has always been a challenge in between security and experience for the end-user. Authentication has always been in the middle of that. Login is the first touchpoint your end-user has, to your application or your services. And you're changing the behavior of the consumer. So we had to get the things in the back right, but we also had to get the things for the end-user to get it right, so that we can ask for a change of consumer behavior. We are at a point now where we can make that happen.
Adrian: I'm glad you brought that up, because one of the bits of feedback that I've heard is some people are uncomfortable with passkeys because they've been so behaviorally trained that there's a username and there's a password. And MFA was easy because it was just like a second password, right? Like this code on a hardware token on my phone or something like that, push auth, that just felt like an additional step.
But taking away a step, that feels weird. It feels unsafe to people. Is that just more training? How do we get people comfortable with using passkeys?
Ashish: I think we have trained our end-users over the years that, that is the behavior you have to go through. I won't say it's easy, but it is consistent. And whenever it comes down to consumer rollouts, consistency generally ends up beating simplicity. That's what happened with passwords and SMS-based codes. But if you look at the actual data, and in fact FIDO Alliance did something you can search for called the Passkey Index report.
One of the key metrics that you look at for authentication is the sign-in completion rate. The number of users who show up to the login page and number who are able to complete the login. For a username and a password, generally, that sign-in completion rate is about 80 to 90% across the industry.
It varies on the platform. On the web it's easier, on the mobile device it's a little bit harder because you have to type it in. The sign-in completion rate for SMS is about 60 to 70%. The number of people who attempt it, who get a code and type it in, that's about that range. In the Passkey Index report, I think it came to about 63%, so right in that range.
The passkey completion rate is 93%.
So even though the perception can be, “Hey, I'm asking you to change the behavior,” once the behavior is changed, 93% of people who attempt a passkey are able to complete it.
The second data metric that we have measured is when you do an MFA, the average time it takes for an end-user to complete an MFA is about 31.2 seconds. The average time it takes for a user to log in using a passkey is 8.5 seconds. So overall, from the data, we feel we are at a point to feel very confident that the experience of the passkey is much simpler and easier.
We had to get to the point that people feel this is a consistent experience across every site.
Adrian: I think this is particularly important in banking because most of the applications I log into leave me logged in for weeks, months, years at a time, right? I have some kind of OAuth token that just sits in my browser cache somewhere and keeps me logged in. But banking, a lot of banking still times out after 15 minutes, makes you log back in.
I remember when I was just going through my transactions, updating my finances, I would probably log into my banking website 10, 20 times each time I do that. It's really annoying. With passkeys, reducing that friction, that seems like maybe even a differentiator to other banks. Something that people do so often, checking their balance, checking their payments, just reducing that friction, that's a lot of overhead.
Ashish: Yeah, and I think that's the balance that you mentioned, the OAuth access token. So generally what happens is, you log in, I give you an access token, and depending upon my security risk posture, I may make it to 10 minutes or I may make it to 30 days. And if you are a social site, maybe it's okay for banking. So that's the choice every website owner has to make every single day, that what is the right time out. And the reason is, because if I try to ask you to log in every single time, and it takes 31.5 seconds, my sign-in completion rate would be significantly lower and it needs to be taken into account.
I think what passkeys have done, which is they are inherently more secure by design.
I'll give you three key data points of how the attack happens today, for instance.
You mentioned password. The most common way people attack the passwords is what you call stuffing attacks or credential stuffing attacks. So you get to a dark web, you get what you call a combo list, a username and a password list, like a million. And then you run a very simple script, you go to every website, you try to replay it. See how many good ones you've got. These are the most common volumetric attack. You have a million list, you get 10 successful logins, it will make your day.
The second one is phishing, where I'm sure you've seen that. You get an email or a text message, you click on a link, you go to the website, and you end up entering your credentials, and next thing you know, you have a breach.
The third one is the man-in-the-middle or adversary-in-the-middle attack, where you can either do that by a proxy layer or somebody will call you on the phone by saying, I'm calling from customer support, give me your code.
What passkeys has done from a security standpoint is just eliminate all of them – just by design.
There is no shared secret. It is a key pair, cryptographically secure, so the website never has access to the private key. So there is no such thing as a combo list that you can go and try.
Similarly, for phishing, every passkey is domain-bound or origin-bound, which is a phishing website, and you go to that website to present a passkey, the OS and browser will not give you the option. So even by accident, you cannot be phished.
Same thing for man-in-the-middle, there is no code to get. The way passkeys operate is the private keys on the device, it gets unlocked by a gesture, can be a face ID or a fingerprint or a PIN code, but the user presence is required.
And because of that, if somebody calls you to ask: Hey, can you give me your SMS code? I have nothing to give. So it's inherently more secure, and the time to complete is fairly good, which I think allows us, the banks, to say, I can ask it every time, and I don't have to worry about the delay of 20 seconds.
Adrian: So if it's that convenient, that useful. Is there any reason to continue using username/password with MFA these days? Are there still use cases where we're going to see a long tail of, there's still going to be TOTP, there's still going to be push-OTP, there's still going to be FIDO security keys, hardware keys?
Ashish: I think each of the different authentication methods that we mentioned, they have their pros and cons.
When you're dealing with a large consumer population, there are so many edge cases that you have to support the other methods. What I would say is that passkeys become the de facto standard, but you may still have to support a few other ones. And like I mentioned, there are pros and cons.
Push notification, I think it's a great experience. Cost-wise, effective. But then you're asking the end user to download an application on the device, so it's an extra onboarding step.
SMS, there is nothing to download. It's a very consistent experience. But we have heard of SIM swapping. It is also expensive, like you pay a penny for an SMS. In some countries, like Germany, it's expensive. In China, it's about five cents for an SMS. So you have to take that cost.
Plus, you have something called international revenue share fraud or SMS pumping that you may have heard of, where fraudsters use the telcos, and then they ask you to send a message to a premium number. So there are a bunch of other issues.
But having said that, when you have a large population, you need to be prepared to support more than one.
Adrian: So what are banks doing to make this? I mentioned before, it's a different behavior. People are going to have to, again, like banks deal with 100% of the population, right? So they've got to make it easy for everybody. What are you seeing from banks, what steps do they need to take to make this move, to make this adoption?
Ashish: I think there has to be a practical consideration how a bank would embark upon the journey, if I may say that. You're not going to start with saying all populations starting Monday are going to use passkeys. So the very first thing we recommend to the bank is nail down the experience for the end-user. For onboarding, for sign-in, and for account recovery, these are the three main touchpoints.
Because you are asking the user to change their behavior. They have been at it a very long time. That's the first thing.
The second thing we say is: Let the user opt in. Get them used to it. Give them a chance to go back if they are not comfortable. Don't force it. Nudge it, but don't force it. And once you get a little bit far ahead, then the nudge can become stronger. But on day one, don't force it.
Third, don't roll out on all the platforms all at once. Stage it. Have a rollout plan. If you have multiple geos, if you have a global bank, pick a location. If you have multiple platforms, pick one of the platforms to get the metrics. I mentioned that KPI on the front end is also KPI on the back end. Like, is the latency working out the way you expect it because it's a new protocol?
Banks can decide whether they want to go web depending upon their security posture or where they are seeing attacks. What we have found is that mobile generally makes it easier, simply because the end users are more used to using a Face ID or a biometric to log into a mobile compared to an old Windows device.
Adrian: In some markets, there's only mobile. They don't own a laptop. All the banking is done through a mobile device.
Ashish: And at the same time, if you think about it, the population who uses the mobile are a little bit more digital-native. They [find it] a little bit easier to adapt to the new technology because they grew up with that mindset compared to the population who has been using the web for a very long time. So banks can decide, but at the end of the day, you have to roll it out in a phased approach as compared to all at once.
Adrian: And before we wrap up, your particular implementation of passkeys, tell me more about how OneSpan does it. What differentiators do you have from the rest of the market?
Ashish: OneSpan has been one of the very early founders or members of the FIDO board. And we also recently acquired a company called Nok Nok Labs, which was the founding member of FIDO. We have years and years of experience in helping shape the spec, all the different nuances, combinations, and permutations. From a DNA standpoint, we know the FIDO spec in and out. And you combine that with 30 years of OneSpan selling authentication software to banks. So overall, I would say we have a lot of experts in the company that can help you do that. So that's the first point.
The second point is that OneSpan has always offered optionality to customers. So today, we offer OTP, we offer SMS, we offer FIDO passkeys, we offer UAF. We offer you to pick on-prem versus cloud. We offer you to have client SDK and a server-side SDK. We also offer you mobile. We also have FIDO2 security keys, again, the same spec. So we call ourselves, for instance the most comprehensive consumer authentication suite, because we have all the options.
And then we help you with the transition based on what you already have.
The third part is that since we have rolled it out to many customers over the last several years, we have this real-time experience of deploying it in a transition fashion. Both the front-end metrics, which is built into the product, and the back-end metrics around latency.
We have customers who have rolled out to millions of users, and the latency requirements are very, very strict.
So I think the net-net would be that we have deep domain expertise on FIDO, we have a deep authentication expertise, and then we have a real-world experience of deploying it.
For the longest time, OneSpan’s tagline used to be that we are the authentication company. And for 30 years, we have been calling ourselves the authentication company. Now we expanded to a few areas, mobile app protection and fraud for banking. But that strong DNA of being the best authentication solution still is what we live for.
Adrian: Excellent. Ashish, thank you so much for joining me today. Loved the conversation. I am ready to get rid of my passwords. I'm looking forward to it.
Ashish: Thank you. This is the year!
Adrian: Yes! Appreciate your time. All right, to learn more about OneSpan, you can visit securityweekly.com/OneSpanRSAC. For full RSAC 2026 coverage from CyberRisk Alliance, visit securityweekly.com/RSAC.
This episode of CyberRisk TV was filmed live at RSAC 2026 and first published on YouTube on March 25, 2026. This transcript has been lightly edited for readability.