Passkeys for decision makers

Marketing free guide, for managers, CISOs, CEOs, engineers, and normies.

Vincit Omnia Veritas

Despite the hype, passkeys are not as simple as they seem. They represent a fundamental shift that has moved quickly, without much discussion, proper documentation, or transparency. Passkeys have raised many questions that need clearer answers.

The main reason this article exists is because I failed to find answers to those questions myself. There were multiple occasions where I wanted, up to date information that I can just share with my colleagues, without the need to make powerpoint slides, and explaining all the pros and cons all over and over again.

I don’t want to downplay the great technical resources from W3C, awesome-webauthn, and passkeys.dev. They have done amazing work, and a lot of thought has gone into these technical guides. But the issue isn’t the technical side — it’s the lack of a unified business analysis, security evaluation, and compliance discussion, which are key to making informed decisions.

The aim of this article is to bridge that gap: to offer clear, factual insights to help those deploying passkeys make the best possible decisions. It’s designed to be a straightforward Q&A guide that tackles the core questions with practical answers.

Important note on term Passkey

In this article, just like in all my other articles, I will refer passkeys as synced, multi-device passkeys. Passkeys can be device bound, however industry standard is: Passkey means synced, unless explicitly specified otherwise.

TL;DR When I say passkeys, I mean synced passkeys, unless specified otherwise.

The 101s

In this section, we’ll cover the basics of passkeys and address key questions that might be causing hesitation.

What passkeys actually are?

At its core, a passkey is a phishing-resistant replacement for passwords. Instead of logging in with a password, users can now log in with a passkey, which offers greater security against phishing attacks and improves user experience.

Technically, passkeys rely on a challenge-response authentication, bound to a specific origin or relying party (RP), using digital signatures. This is often referred to as FIDO2 or WebAuthn, and “passkeys” can be considered FIDO2/WebAuthn credentials.

Let’s break down the jargon:

Challenge response:

The website generates a challenge and sends it to the passkey provider (authenticator). The passkey provider then returns a response that includes the signed challenge.

Origin/rp binding:

It means that a passkey is tied to a specific website, and the website can verify where the passkey is being used. For example, if a passkey was created for “example.com,” it will only work for “https://example.com.", “https://login.example.com." This helps prevent phishing attacks by ensuring that the passkey can’t be used on a fake website. More details on this will be covered later.

Digital signature:

Simply means public key cryptography. Private key at user side, and is used for signing. Public key is at the website, and is used for verifying. When a user logs into the system, the website can just verify authentication with a passkey using previously known public key.

Passkey vs security key

Passkeys are generally synced across a user’s devices, meaning they can be accessed from multiple devices rather than being tied to a single one. In some cases, passkeys may be device-bound, but this is the exception rather than the rule. When we refer to passkeys, we are typically talking about synced credentials that can be used on different devices within the same ecosystem.

Security keys, on the other hand, are physical hardware devices that support FIDO authentication. While passkeys can technically be hardware-based, the industry typically uses the term “security keys” for any physical FIDO-compliant device.

FIDO’s original model was built on the promise of “keys bound to devices,” but passkeys have shifted away from that model. Instead of being tied to a specific device, passkeys are tied to a set of devices synced via the cloud. This means that passkeys do not meet the criteria for true two-factor authentication (2FA), as they lack the strict device-binding that would provide an additional security layer for sensitive accounts, such as retirement funds or financial assets.

While passkeys improve the account recovery process — making it easier for users to access their accounts if they lose a device — they do so by relying on cloud sync. All devices linked to a user’s cloud account can access passkeys, meaning even a device that has never accessed a specific account before can retrieve the necessary credentials. This provides a smoother user experience in the case of lost devices but raises concerns about security if the cloud service is ever compromised.

In summary, passkeys offer more convenience than security keys, but this comes at a trade-off in terms of security. This shift from device-bound credentials to cloud-synced keys simplifies user experience but introduces potential vulnerabilities. Historically, convenience often comes at a cost, and passkeys may eventually expose similar risks if not managed with strong controls.

What problems do passkeys actually address?

Passkeys are primarily designed to tackle phishing, the most prevalent threat in traditional authentication. By eliminating the need for passwords or shared secrets that attackers can steal, passkeys provide a far more secure authentication method. They use public-private key cryptography, meaning the private key remains on the user’s device, making it much harder for attackers to access or intercept.

In addition to enhanced security, passkeys significantly improve the user experience by removing the need for users to remember or manage passwords, and they address the common issue of password reuse. Passkeys also simplify account recovery and device synchronisation, allowing users to regain access to their accounts easily, even if they lose a device. This combination of strong phishing resistance and improved user experience makes passkeys a solution to both security and usability problems in authentication.

Quickly breaking down jargon

• Passkey — technically, passkeys refer to any FIDO2-based authentication. However, in practice, the term usually refers to the synced, multi-device version that works across different devices in the same ecosystem.
• Multi-device or Synced Passkeys — are the default form of passkeys that sync across multiple devices. While they operate as a single factor, they offer several advantages over device-bound passkeys, such as ease of use and seamless access across different devices in the same ecosystem.
• Device bound passkeys — are a form of passkeys that is bound to the devices, and is non-exportable. Basically traditional FIDO2 Platform credentials.
• Sync fabric — a way to synchronise passkeys between devices. More on it further down.
• Other terms can be found in my older terms guide “Sorting FIDO/CTAP/WebAuthn terminologies”

What does basic experience look like?

The passkey experience can be broken down into three main stages:

1. Enrolling passkey
2. Authenticating with passkey
3. Managing passkey

Enrolling passkey

User opens their account, and clicks on “Add passkey”. The user shall be given some basic instructions on how to enrol passkey. Once user consented enrolment, and done verification using biometrics, the passkey is ready to use.

Enrolling passkey for Google Account

Authenticating with passkey

Once user has registered their passkey, they may login with “webauthn autofill”, without even having a need for typing username.

Authenticating using passkey autofill to Google Account

Managing passkeys

Once user is logged in, the are able to modify passkey name, or outright delete it.

Managing passkeys

I highly recommend taking a look at FIDO Alliance’s UX Guidelines

Passkeys vs traditional factors?

Passkeys offer a significant improvement over traditional authentication methods primarily due to their phishing resistance. Unlike passwords, SMS, or OTPs, which are easily compromised through phishing attacks, passkeys provide a more secure alternative by eliminating the need for user-shared secrets that can be stolen. This makes passkeys a much more resilient option for protecting against the most common forms of credential theft.

However, as I discussed in my article “Are Passkeys MFA?”, multi-device passkeys aren’t truly multi-factor authentication (MFA). Although passkeys are highly secure and phishing-resistant, they function as a single factor — a synchronised secret stored across devices via cloud services. This prevents them from meeting the traditional MFA definition, which requires a separate “something you have” factor. For high-value accounts, such as those in financial services, this limitation raises concerns about whether passkeys alone are sufficient. While passkeys significantly reduce the risk of phishing, organisations handling sensitive data may still need to supplement them with additional step-up authentication methods to meet stricter security and compliance standards.

What are sync fabrics?

A “sync fabric” is essentially a keychain that stores your passkeys.

By default, all sync fabrics are encrypted storage systems with strict access controls, managed through a master password or biometrics.

There are two main types of sync fabrics:

1. Platform Sync Fabrics: These are integrated with the operating system, like Apple iCloud Keychain or Google Password/Passkey Manager, and sync your passkeys across your devices through your platform account.
2. Password Managers: Independent tools like Dashlane, 1Password, Bitwarden, or KeePassX that store and sync passkeys across different devices, independent of any specific platform.

TLDR: Sync fabrics are just a way to sync passkeys between devices. They can be built-in, like iCloud Keychain, or external, like password managers.

Challenges and Considerations

Compliance and MFA

One of the fundamental changes introduced with passkeys in 2022 was the shift from device-bound keys (platform credentials) to synced, multi-device passkeys.

Passkeys offer significant advantages in user experience by simplifying logins and removing the need for cross-device verification. However, they also come with a drawback — they are not true multi-factor authentication (MFA) solutions.

As I outlined in my recent blog post, “Are Passkeys MFA?”, passkeys are not considered multi-factor because they are essentially synchronised secrets used for phishing-resistant authentication. Though passkeys offer phishing resistance, from a factor definition perspective, they are simply a synchronised private key shared across devices, making them a phishing-resistant form of a “knowledge” factor.

This creates challenges for enterprises, as compliance and cybersecurity requirements often mandate true multi-factor authentication for high-value sectors like banking, healthcare, and government services. As a result, solutions like “Passkey + SMS” are emerging. While this combination might seem preposterous, it provides the additional factor needed to meet regulatory requirements for MFA.

In my recent article, “Two Years of Passkeys: A Reflection Point”, I explored the challenges of deploying passkeys in enterprise environments and how these challenges impact broader adoption. The core issue with passkeys today is the lack of device binding, which limits their use in scenarios where stricter security is needed. This could be addressed by introducing a device binding extension, like “Supplemental Public Keys,” which would allow enterprise RPs to establish strong device binding, reducing the need for step-up authentication.

However, this extension was recently removed from the specification, though it might be reintroduced in a different form in the future. This uncertainty creates difficulties for enterprises trying to align passkey adoption with their security requirements.

The SPK (Supplemental Public Keys) proposal has its own set of challenges. For device binding to work effectively, there must be an established level of trust in the session before binding it to a device. This means that when using a new device, an initial step-up authentication would still be required to meet MFA requirements. After that, the website can create the SPK, allowing device binding to be maintained over time, which reduces the need for repeated step-ups.

However, this same goal can also be achieved through HTTP-ONLY long-living cookies by creating one during the initial step-up. This way, you get the benefit of an easy, passkey-based, phishing-resistant login, and after a successful step-up, the device can be trusted long-term.

While this isn’t a perfect solution, as attested device binding would be more secure, it’s still manageable. Relying parties can mitigate these challenges through programmatic solutions like long-term cookies to achieve a similar outcome.

This is a reminder that passkeys are not a silver bullet. They come with advantages and disadvantages, just like any other authentication method. Enterprise organisations need to make informed decisions to meet their compliance requirements and should continue to use step-up authentication when reestablishing trust is necessary.

Identity sovereignty

Despite all the issues with passwords, they have one key strength: familiarity.

You can store passwords in your head, write them down, use a password manager, or even put a note on your fridge. They’re a universally understood concept that has been part of human history for centuries.

This familiarity made passwords a foundational element of online authentication. Another critical aspect of passwords is data sovereignty — users can decide how to manage their passwords. You can choose to store them in a manager, remember them, or write them down somewhere safe. The choice remains entirely yours, offering a level of independence in managing your authentication.

Passkeys, in their current form, require users to rely on sync services from providers like Google, Apple, or Microsoft, or third-party managers. This shifts control away from users, leaving them at the mercy of those services. If a platform account or password manager is locked, users can lose access to critical parts of their lives.

We’ve seen instances of this with Amazon locking users out of their smart homes or Apple facing issues with mass account locks. This isn’t about pointing fingers — it’s about recognising the challenges of managing identity at a large scale. When multiple services are tied to a single account, any issue affecting that account can have wide-reaching impacts. Whether it’s a routine event like travel triggering an internal risk algorithm, or an unexpected glitch, users can find themselves locked out without recourse. For a company like Apple, even a 0.01% error rate could mean 130,000 users are suddenly unable to access essential parts of their lives.

Currently, there are no clear legal precedents, policies, or guidelines on handling these situations. Users often have no legal recourse, as the terms and conditions allow companies to deny access to a copy of their data if an account is locked.

Passkeys have their challenges precisely because they are passkeys. They rely on cryptographic keys that are impossible to memorise, which inherently requires reliance on third-party management. There are no easy answers, and even as an expert in the field, I find it difficult to devise a perfect solution. The best I can suggest for now is using encrypted passkeys backups, or printable QR-encoded passkeys, that you can store securely, but these are far from ideal. This issue needs a lot more thought and discussion before passkeys can become a ubiquitous authentication method.

Account recovery

Account recovery is about reestablishing trust once it’s been lost. Forgetting a password or losing a phone means you are no more trusted than a stranger trying to access your account. As a result, account recovery processes need to solve two critical challenges:

1. Ensure that the recovery process itself is not a security vulnerability.
2. Rebuilding trust between the user and the service, ensuring legitimate users can regain access.

Passkeys are often promoted as simplifying account recovery by making authentication more user-friendly and reducing the frequency of recovery events.

However, the core challenges of account recovery haven’t disappeared. If a user deletes a passkey by mistake or it’s compromised, a robust recovery process is still required to regain control. In these moments, passkeys alone are not enough — a proper account recovery mechanism must step in.

Passkeys are simply what they are, a secure authentication method. Passkeys offer phishing resistance and good usability. Account recovery, however, is a distinct process that requires thoughtful design to balance user convenience with security, independent of how authentication is handled.

Deployment and step down attacks

Fully passwordless authentication is still uncommon, and many users aren’t yet comfortable with passkeys, which makes adoption slow. To address this, most services use an opt-in strategy, educating users while keeping passwords as a fallback. While this approach maintains user choice, it also leaves a significant vulnerability — passwords can still be easily phished, undermining the advantages of passkeys.

This creates a complex challenge for deployment. Services need to balance user experience, security, customer retention, and transaction volume — promoting passwordless adoption without alienating users in the process.

Deploying passkeys successfully is challenging because there’s no universal solution. Every service has different goals, risks, and tolerance for user friction. Here are some strategies that can help improve deployment outcomes:

1. Respect and Guide Your Users

Users aren’t dumb; they just need the right information. Offer a concise, informative message about passkeys, like: “Think of passkeys as TouchID for the web — enable them for quicker logins.” Simple, clear communication can go a long way in reducing hesitation.

2. Leverage the Latest UX Features

Take advantage of modern passkey features, such as Passkeys Autofill (Conditional UI), resident credentials, and AAGUID detection. A frictionless user experience can make a significant difference in encouraging adoption.

3. Provide Incentives and Improve UX

To encourage users to switch to passkeys, offer small incentives like “5% off when you pay using passkeys.” This motivates users to try the new method and can make it a habit over time.

4. Transition to a Passwordless Future

Once users have become accustomed to using passkeys, and you see that passwords are rarely used, consider phasing out passwords altogether. This step will ensure that user accounts are much less vulnerable to phishing.

5. Secure High-Value Customers with Hardware Keys

For high-value customers, provide or encourage the use of hardware security keys, like a Yubikey, or Hideez Key. If a customer contributes significant revenue, ensuring their account’s security is worthwhile. Offering a personalized security key as a gesture can also reinforce their importance to your business — just be cautious about branding it to avoid revealing sensitive information, i.e. Don’t print “Bank.com John Doe” on the key.

Ultimately, balancing security and usability is crucial, as with any security system. Step-down risks must be carefully considered and factored into both decision-making and the overall user authentication journey.

Fabric tearing

While passkeys are resistant to phishing, the same cannot be said for the passkey providers themselves, such as Apple, Google, and password managers, which still have issues:

1. Recovery Methods: Apple and Google still rely on traditional recovery methods like passwords, OTPs, and security questions. Despite improvements, these methods can still be phished. If an attacker successfully obtains access, they can compromise the entire keychain, giving them control over all linked accounts in one go.
2. Master Passwords in Password Managers: Password managers rely on a master password for authentication, which is a fundamental limitation. Since this master password is the key to the entire encrypted vault, phishing attacks targeting these passwords remain a risk that is hard to eliminate.
3. Lack of User Awareness: Users often underestimate the risks involved in relying heavily on passkey providers or password managers. They may not fully understand that by consolidating their credentials, the consequences of a successful attack are greatly amplified, i.e. putting all eggs into one basket.

The positive side is that passkey usage is still relatively limited, and successfully attacking major platforms or password managers requires more effort compared to typical phishing attacks. However, this landscape is changing, and as AI-powered phishing tools become more sophisticated, these attacks will likely increase in quality and effectiveness.

None of this means you should avoid using passkeys or password managers — they are still far superior to weak or reused passwords. However, it’s important for potential adopters to understand these risks and evaluate their options carefully to make informed decisions.

Inconsistent Support and Light UX Issues

Overall, the passkey user experience is quite smooth, mainly because all platforms — iOS, Android, Windows, and MacOS — use the same underlying APIs for passkeys. This consistency means most browsers offer a similar experience when it comes to passkey interactions.

Side by side Safari and Chrome experiences on MacOS

However, there are some differences between platforms and browsers. For example, synced passkey support is still uneven. Just as I was wrapping up this article, Microsoft announced that Windows 11 will finally support synced passkeys. However, this leaves Windows 10, which still accounts for more than 60% of all Windows devices, without this crucial feature, creating a gap in the transition to a fully passkey-supported environment.

As of today Edge on both, Windows 10 and 11, only supports device-bound credentials (non-synced), meaning passkeys created on one device cannot be used on others. Chrome has partially addressed this by integrating Google Password Manager to sync passkeys across devices, but this introduces issues when switching between different browsers, as cross-browser syncing isn’t fully resolved.

Another area with notable challenges is the cross-device authorization flow (also called hybrid or CaBLE flow). This process often receives poor user feedback because of its complexity, requiring careful consideration when being implemented. Safari adds to the confusion by displaying a hybrid QR code when a passkey isn’t found, rather than showing an error message. This behaviour can be quite disorienting for users who aren’t expecting it.

Chrome vs Safari when non-existent passkey is requested.

Requesting non-existing passkey, with explicit device hints (hints: [“client-device”], transports: [“internal”]). You can test using this tool

These discrepancies make the user experience less seamless in certain cases, especially when navigating different platforms and browsers.

While these are edge cases, edge cases can vary widely depending on the platform. A 0.1% occurrence might mean 10 users for one service, but it could represent 100,000 users for a larger platform. This makes thorough focus group testing crucial for ensuring a successful deployment, as it helps identify and address these rare but impactful issues across different user environments.

Enterprise and Gov challenges

Recently NIST announced fourth draft of Digital Identity Guidelines 800–63. This draft finally brought so much needed clarification to passkeys deployment in government sector.

The key issue here is that if you host your sync fabric (or keychain) in a FISMA Moderate environment, you can use passkeys for federal employees at AAL2 assurance levels. For consumer portals like IRS accounts, regular passkeys are sufficient to meet AAL2 requirements. However, this compliance is largely limited to the U.S. government context. In most EU countries and Asia, passkeys are still not compliant with their government regulations, making adoption slower in those regions.

In the enterprise space, passkey support is currently lacking. For instance, Azure Entra ID does not yet support passkeys, although integration is on the horizon (for now, Microsoft Authenticator serves as a workaround). Additionally, most identity providers and enterprises lack comprehensive public guidelines on deploying passkeys and FIDO protocols, leaving much of the enterprise world without a clear path forward for adoption.

The adoption of passkeys and security keys will advance quickly, especially in government and enterprise sectors. However, there is a strong need for clear guidance on how to deploy them effectively in these environments. More detailed best practices around integration, security, and compliance will be essential for organizations making this shift.

In conclusion

Passkeys are a complex topic, and one of the key issues with the current ecosystem is the lack of business strategy behind their deployment. Organisations don’t implement new technologies simply for their features — they need a clear connection to long-term business goals and strategy.

While passkeys are far from perfect and still face challenges that need to be addressed before they can become truly mainstream, they offer a functional, phishing-resistant alternative to passwords. With a significantly better user experience, trying out passkeys makes sense, even if they aren’t yet a perfect solution.

I hope this article was useful to you. If it was, consider subscribing.

I would like to thank all contributors who reviewed my articles, and provided valuable commentary. You guys are the best.

Lastly: I am available to consult. If you like my blogs and need, flicker me email yuriy.ackermann(at)gmail.com, or find me on linkedin. I would be happy to answer your questions.

Resources

• https://github.com/yackermann/awesome-webauthn — Community list of demos, servers, articles, and other things on passkeys.
• https://passkeys.dev/ — Great community resource on passkeys
• https://fidoalliance.org/ux-guidelines/ — FIDO Alliance UX guidelines.
• https://herrjemand.medium.com/are-passkeys-mfa-f2720c983d5e — My article “Are passkeys MFA?”
• https://herrjemand.medium.com/two-years-of-passkeys-a-reflection-point-afbbe5849391 — My article “Two years of passkeys, a reflection point”

FAQ

What is RPID? What is the origin?

The Relying Party Identifier (RPID) is simply the hostname that defines the scope of a credential’s security, while origin is what the website user truly sees. Here’s an example:

If John registers a passkey at “https://example.com," the RPID will be set to “example.com.” When the passkey is created, the website receives the origin (“https://example.com"), which represents what the user sees, and the hash of RPID (“example.com”), which represents the scope for the authenticator.

These values serve different security roles:

• RPID: Controls which credentials the authenticator can use, acting as an access control measure.
• Origin: Ensures the user is on the correct website, helping prevent phishing.

Internally, passkeys are tied to both the RPID and the credential ID. This means that the authenticator needs both to retrieve the credential. If an attacker tries to misuse a credential ID by using a fake website like “attacker.com,” the authenticator won’t match the RPID and will simply reject the attempt. This way, the RPID prevents passkeys from being used outside of their intended context, ensuring a strong layer of access control.

The origin then allows the website to see the exact way the user sees the website. If a user all of a sudden is on the wrong port “https://example.com:3452”, or unexpected subdomain “https://badtest.example.com”, then RP can detect a potential spoofing attack, and prevent phishing. (We will discuss subdomains in the next section)

Can I register a passkey at one domain, and use it on different?

Subdomain yes. External domain, soon.

Subdomains

WebAuthn security is using “child rule” for subdomain management. That means that all children subdomains of the RPID are able to request parent RPID. Examples:

For RPID example.com all these are valid origins:

• https://example.com
• https://auth.example.com
• https://long.long.child.sub.domain.example.com

However for auth.example.comRPID

• https://example.com is invalid
• https://login.example.com is invalid
• Buthttps://dev.auth.example.com is OK

Regarding security, because any subdomain can potentially authenticate using the parent RPID (e.g., https://bad.dev.example.com logging in with example.com RPID), services need to be vigilant. Proper validation of authenticator responses is critical, along with maintaining a strict whitelist of trusted origins. This helps ensure only authorized subdomains can interact with the parent RPID, protecting against unauthorized access.

Get certified™

When deploying passkeys, it’s essential to carefully define the Relying Party Identifier (RPID) to ensure future compatibility and scalability. Choosing the correct RPID helps maintain security and consistency across different domains or subdomains, ensuring that passkeys function properly in the long term.

Related origins — example.com + example.org + …

Recently webauthn specs added support for related origins. That means that international companies that have multiple domains can relate their origins by specifying them in/.well-known/webauthn.

This means that by setting well-know to the list of linked origins, example.com can now allow authetnication on those websites.

{
  "origins": [
    "https://example.com",
    "https://example.co.uk",
    "https://example.co.jp",
    "https://example.ca",
    "https://converse.com",
    "https://converse.co.uk",
    "https://converse.co.jp",
    "https://converse.ie",
    "https://converse.ca"
  ]
}

Full support for this features is coming, and you can learn more at passkey.dev

Updates

• October 13, 2024 — Added important clarification on usage of the term “Passkeys” based on initial feedback.