The state of passkeys in 2025

The humble password has had a good run but it’s time for something better. In a recent episode of Random but Memorable, I sat down with Nick Steele, Senior Staff Product Manager at 1Password and long-time member of the FIDO Alliance, to unpack the rise of passkeys. From the origins of passwordless authentication to the latest developments in Credential Exchange Format (CXF) and Credential Exchange Protocol (CXP), we discuss society’s steady shift toward a truly passwordless future.

In this interview, Steele explains why passkeys are more secure by design, how adoption has grown since 1Password first embraced them, and what the next generation of authentication might look like. Whether you’re a developer curious about the specs or an everyday user ready to leave passwords behind, this is your inside look at how 1Password is helping to make signing in faster, simpler, and more secure for everyone.

Nick Summers: Can you briefly explain what passkeys are, and how they work?

Nick Steele: Let's step back before we talk about passkeys. Before passkeys, and really before MFA in general, we had passwords. Passwords are generally a nuisance. Even the guy that created passwords, Fernando Corbató, said they don't really work and maintaining them is really hard. Until the day Corbató passed away, he kept his own passwords in a notebook that he didn't enjoy using.

Passwords are the largest source of breaches, security concerns and vulnerabilities on the web. And so the goal of passkeys, when that work started around 2015, was to provide a way for stronger credentials to be used in lieu of traditional passwords. 

And we call them passkeys now. They're unique by design. They're made by secure hardware or secure software. And they're tied to one or a set of domains. They're harder to steal. They're based in public-key cryptography. They're essentially a public and private key. And the only key that is ever exposed is the public one, and it's stored by the website or app. Now, if that key is stolen, not a whole lot is lost because it's a public key. And we've made it very hard by design for a malicious actor to get access to the private key associated with it.

We've done a lot of work over the years to make sure that passkeys are stronger, better, and really just a better experience than passwords.

We've done a lot of work over the years to make sure that passkeys are stronger, better, and really just a better experience than passwords are. And we've really helped kind of change the narrative around how login should be occurring, and how it can be not only simpler, but also safer.

Nick Summers: You just mentioned some of the security benefits of passkeys. What are some of the other major benefits for end users?

Nick Steele: The biggest benefit beyond security is the ease of use. Traditionally, in the best case scenario, users were creating long, random passwords. But in practice, that's not the case a lot of the time. Folks not only have to try to remember and use all these different passwords – they have to enter them. That can be really easy if you have a password manager like 1Password. Otherwise, it's really hard! 

When passkeys were first implemented on sites like Google, they saw a huge reduction in failed credential logins because passkeys were that much easier to use. You just hit a "sign in" button and then the passkey is presented without the user having to type anything in and potentially get it wrong. So the simplicity of passkeys is really great.

Nick Summers: What is passkey adoption like in 2025? Are more or less people using them than you expected?

Nick Steele: I always knew that this was going to be a long tail. We've been using passwords on the internet for over 50 years. So it's really ingrained into the identity of the internet, and how we access things. 

That being said, eight of the top 10 sites on the internet now support pass keys. We've seen over a billion passkeys generated, and 1Password stores millions of them. Overall, we're seeing a trend towards at least 20 % of the market using passkeys, which is pretty impressive given it’s only been a few years.

It's going to take a long time to get folks to move over from passwords.

It’s not the meteoric rise that I hoped would happen. But it's to be expected. It's going to take a long time to get folks to move over from passwords and start seeing passkeys as a more natural way to log in online. But it’s something that is definitely increasing. Adoption is moving forward. 

And it's also become much more natural in a lot of settings. The way we log in to things on mobile devices today tends to be biometric and passwordless already. So certain contexts and modalities of using passkeys is going to be a driver too. We're going to see more passkey adoption on mobile devices sooner than on desktop flows and in enterprise settings.

Nick Summers: Have there been any sticking points along the way that have made it difficult for people and websites to support passkeys?

Nick Steele: One of the biggest hurdles by far is just that supporting passkeys is more complex than supporting traditional passwords, right? From a developer’s perspective, supporting passwords is fairly easy. Verifying a passkey on the relying party side, as we call it, is a little more intensive. Developers need to know more about security and identity. So the blocker is really just like the time and attention that development teams need to not only overhaul their existing password systems to support passkeys, but to understand how this technology works. And that can be hard.

Nick Summers: Let's switch gears now and talk about 1Password. How have we been refining the passkey experience in our apps and browser extension?

Nick Steele: We’ve done an excellent job of making sure that we're up to date with areas of the specification that are currently being developed. 

Myself and other folks from the passkey team at 1Password have been involved, not only on the internal development side, but external development as well. We've been very much involved in the W3C, the World Wide Web Consortium, to help develop the underlying specifications. 

On our end, we're focused on making sure that the standards are usable for all types of authenticators, not just 1Password, which is considered a credential provider or a passkey provider in this space. So we're keeping up to date with the spec as it develops and we're testing new features as they’re added to the spec. There are new functions like the pseudo random function that allow us to encrypt additional data with passkeys, which is a really neat feature.

But we've also started adding our own standards.

Nick Summers: Before we go deeper into that standard work, let’s talk about FIDO. Can you explain what the FIDO Alliance does, and how you're involved?

Nick Steele: Absolutely! FIDO is the Fast Identity Online (FIDO) Alliance. It’s existed for more than a decade and was started by a group of security-focused companies. The Alliance designs specifications that allow better, quicker, more secure login and authentication for websites, and for the hardware providers that allow for that technology and those types of protocols to exist. 

Companies like Yubico, Google, PayPal – and 1Password of course – alongside Dashlane, Bitwarden, and all the other credential providers are working together to build the specifications to allow for more secure and simpler authentication. 

Over the past five or six years, we've been really focused on FIDO 2. FIDO 2 is the collection of standards that help make passkeys possible. And it's really just two of them. It's the client to authenticator protocol – CTAP – and WebAuthn. 

WebAuthn is maintained by the W3C, the World Wide Web Consortium, while FIDO maintains CTAP. Between those two standards bodies, we work together to drive the work and development of passwordless technology for consumers and for businesses. 

My involvement with FIDO has been going on for almost a decade now.

My involvement with FIDO has been going on for almost a decade now. And I've been working on the technical working group. And I co-chair that group with another guy from Google. And we've been working on a lot of new standards like Credential Exchange Protocol (CXP) that allows importing and exporting of passkeys.

Nick Summers: Before we get to CXP, let's talk about the credential exchange format (CXF) first. Can you walk us through what that one is in principle?

Nick Steele: If you try to export your passwords today from a provider, ⁓ it tends to happen in a CSV or a JSON blob. And it tends to be in no particular format. And this is bad for a couple reasons. 

The first one is that if you're exporting credentials from a secure vault, you should expect those credentials to remain secure in transit. Exporting them into a CSV is what we call clear text, which is no good because they're all just existing on your desktop and can be viewed by anyone that is either walking by or has access to that machine.

So it’s really important that those CSVs get deleted once the import or export has taken place. The other issue is when we do have those import events and we move credentials from the CSV file into a new provider, it can be really hard for that provider to figure out how to marshal the data that is in that CSV file because every provider creates that file differently.

So the format of the credentials in the CSV isn’t standardized. So what credential exchange format (CXF) is trying to standardize is exactly that. We want the format of credentials when they're passed between password managers to be exactly the same and standardized. And as new types of credentials come out we've been trying to make universal formats for all these. So this could be something like a credit card, a secure address, or passport information. 

And most importantly for this conversation, that could be a passkey. And this format won’t just be helpful when you’re moving to a new password or passkey manager. This is really good for sharing, too. If you're using Bitwarden and I'm using 1Password and someone else is using Google’s password manager, I should be able to share a credential with you or a passkey with you without having to download the other credential provider. If we're all speaking the same language and we're all using the same format, we can do that much more easily and securely.

Nick Summers: So what you're saying is CXF isn’t just a standard that can support passkeys but really any of the data that you would normally store inside a password manager.

Nick Steele: That's right. And as new types of credentials come out, we'll be able to support those too through Credential Exchange Format, CXF.

Nick Summers: So we've reached quite an exciting moment with CXF. Can you share the news with us?

Nick Steele: Yeah, so credential exchange format (CXF) is now fully published as a recommended standard. And we'll get there soon with credential exchange protocol (CXP) as well. 

CXF has been published by myself and other folks from across the FIDO Alliance in order to get not only feedback but adoption and implementation from a much broader audience. 

"We're going to be able to get a lot of really great feedback."

One of the hurdles in FIDO is that we work on things behind closed doors until we reach a publication point. We've done a really good job at collecting initial feedback and comments from the community, like other credential providers. But being able to publish this now means that we're going to be able to get a lot of really great feedback on it by the time we're ready to publish credential exchange protocol (CXP).

Nick Summers: So what is credential exchange protocol (CXP)? If credential exchange format is the file format, is CXP the handshake or the pipe that needs to exist between different password managers?

Nick Steele: That's exactly it. It's both the handshake and the pipe. As I mentioned before, credential providers produce CSV or JSON files in order to export passwords. And they do this in clear text. And so this isn't really good. 

Credential exchange protocol (CXP) provides an encryption key upfront in order to make sure that those credentials are never exposed. And it’s done in a way that is consumable or decryptable by a service that isn't the importing provider. So we assume that these credentials are going to go somewhere else. It’ll create a secure channel in which to give these credentials to the new provider in order to prevent a user from potentially exposing the credentials on the desktop as they move them.

Nick Summers: Once these standards are actually implemented, what do you think the experience is going to be like for the end user? Will I ever see a “.CXF” file, or will this all happen within the UI of my password manager?

Nick Steele: I think it's going to be abstracted away. It's going to be a really simple experience. 

Nick Summers: And what do you think the impact of CXF and CXP will be on passkey adoption? I often see people online say that they need the ability to import and export passkeys before they’re comfortable using them.

Nick Steele: I see that a lot too. I hear a lot about vendor lock-in. I'm hoping that CXP will help alleviate a lot of the concerns around how passkeys are going to be stuck on a single platform all the time.

Nick Summers: So what's next for CXF and CXP? What are the next steps to actually implement them in 1Password.

Nick Steele: Some companies have already implemented CXF and CXP. We're working on it as well. We'll probably have a more full, GA (general availability) version of CXP available soon. 

As we build them out, I don’t want them to be just consumer specific. There's a lot of features and a lot of additional security configuration that we'd like to explore and develop.

But the first step is going to be having all these credential providers be able to support CXP and CXF in a “V1” state, which is really just moving credentials around in bulk.

Nick Summers: Let's bring it back to the present day. What can our listeners and 1Password customers do to start switching to passkeys?

Nick Steele: One of the things that's coming out that I'm really, really excited about is passive passkey enrolment. This is the idea that users are going to be able to start going to sites and then have that site upgrade them to a passkey without doing anything in the meantime.

"Start enrolling passkeys today."

But until that starts seeing more adoption, what users can do today is start enrolling passkeys today. You might have already been prompted to do so by Google or another website or app. Most sites will tell you if they have passkey support but if they don't, check out your account security settings and see if you can add a passkey.

Nick Summers: Where can people go to learn more about this, these new FIDO standards that we've been talking about today and also pass keys and one password in general?

Nick Steele: If you want to mess around with passkeys and WebAuthn, which again is one of the protocols that's associated with passkeys and FIDO2, I'd recommend checking out a website that I used to maintain, now my friend Matt Miller maintains, called WebAuthn.io. This is a quick and easy way to test out how passkeys work and what they look like in practice.

You can also check out passkeys.dev, which is a site made by myself and others to help developers implement and adopt passkeys. There are a lot of tools in there and documentation on how all these standards work. 1Password also maintains passkey-rs, which is our own Rust library, which will help developers run passkeys if you're using Rust today and you're interested in implementing passkeys, 

And for myself, I help maintain go-webauthn which is the Golang library for WebAuthn.

Nick Summers: I would add passkeys.directory to that list, which  shows which websites and apps currently support passkeys.

Nick Steele: That's a great one too!

Love passwordless authentication? Join the 1Password Community to chat with passkey adopters and developers!