Passkeys: Are They Ready for Enterprise Use?

This blog was first published in 2024 and has been updated. 

Passkeys are becoming increasingly common thanks to consumer services such as Google, Apple, Facebook, Meta, and more. The use of passkeys significantly increases security compared to traditional password-based logins or passwordless MFA.

It’s normal for some consumer solutions to spill over into professional usage—think being able to send emoji reactions to emails. But just because Instagram lets me log in using a passkey, does that mean businesses should?

In short: are passkeys ready for enterprise use?

The FIDO Alliance was founded in 2013 by various companies to develop an authentication standard that would serve as a second factor; today, FIDO can serve as a strong passwordless authentication method.

Since 2013, FIDO has become one of the most popular passwordless login methods in large part because it delivers on the acronym that makes up its name: it provides fast identity online. The FIDO Alliance has a strong focus on the consumer environment. No wonder, its largest members are active in this area: Apple, Google, PayPal, and Microsoft. RSA is a member of the FIDO Alliance and co-chairs its Enterprise Deployment Working Group.

FIDO credentials use asymmetric key pairs to authenticate into a service. When a FIDO credential is registered with a service, a new key pair is generated on the FIDO authenticator and the service then trusts that key pair—and that key pair alone. The key pair is connected to the exact domain name of the service.

That strict pairing between a service and a FIDO credential is what creates a high degree of phishing resistance: if a user were to try to log in to a phony phishing site with the passkey created for the real site, they would fail because the domain named wouldn’t match with the credential.

In 2022, Apple, Google, and Microsoft launched support for a new type of FIDO credential, which they called a passkey. In 2023, the FIDO Alliance adopted the term “passkey” for any type of FIDO credentials, leading to potential confusion in exactly what an organization means when it mentions “passkeys.”

This possible ambiguity has been addressed by the FIDO Alliance (see below) but could still exist in organizations. It’s important to address that ambiguity, because not all passkeys are created equal or appropriate for enterprise use.

Types of passkeys

There are now two types of passkeys, as defined by the FIDO Alliance: device-bound and synced.

Device-bound passkeys vs. synced passkeys

Device-bound passkeys are generally hosted on specific “security key” devices. This passkey type is generally considered more secure because the private key never leaves the device, making it resistant to extraction or remote compromise.

However, this also means that if the device is lost or damaged, the user would need to register a new  passkey  to a new device . Device-bound passkeys are particularly favored in high-assurance environments and enterprise use cases, often leveraging hardware such as security keys or Trusted Platform Modules (TPMs).

Device-bound passkeys are also now supported in certain mobile applications, such as the RSA Authenticator app for iOS and Android.

Synced passkeys

With synced passkeys, the key material is saved via a so-called remote sync fabric, and the key material can then be restored on any other devices owned by the same user. The current major sync fabrics are Microsoft, Google, and Apple. This means that if you were to register your Android phone as a passkey, then the corresponding key material would be stored by Google, and therefore available on all your other Android devices shortly after.

Synced passkeys are—in addition to having the support of widely used services such as WhatsApp or Facebook—a main reason for the sharp increase in the general use of passkeys. It’s easy to see why: one user with a lot of accounts and a lot of devices can use the same synced passkey between all of them.

Passkeys replace traditional passwords with cryptographic key pairs, delivering strong, phishing-resistant authentication. When a user registers for a service, their device generates a unique private-public key pair. The private key stays securely stored on the user’s device while the public key is shared with the service. During authentication, the device proves possession of the private key by signing a challenge from the service, and the signature is verified using the stored public key. No shared secrets are transmitted, and no passwords are created or stored, dramatically reducing the risk of credential theft or replay attacks.

Traditional passwords rely on shared secrets that can be guessed, stolen, or phished, making them a common entry point for attackers. They’re often reused across accounts, stored insecurely, and vulnerable to brute-force or credential stuffing attacks.

Passkeys eliminate these risks by replacing passwords with public-private key cryptography. Authentication happens by proving possession of that key—without transmitting it. This approach renders most common attack vectors obsolete, including phishing, credential theft, and password reuse. For organizations, passkeys offer a leap forward in secure authentication, while reducing the burden of password resets and support tickets.

• Phishing-resistant: Passkeys are designed to prevent traditional phishing attacks. Since there’s no password involved, there’s nothing to steal or reuse.
• Fast and convenient: Logging in with a passkey is often as simple as using biometrics (like Face ID or a fingerprint), making the experience smoother for users.
• Familiar user experience: Passkey logins resemble common mobile authentication patterns, so there’s little to no learning curve.
• Domain-matching security: Passkeys offer an extra layer of protection by ensuring the key material only works with the original service domain—a benefit not all MFA methods provide.
• Government-approved: In the U.S., phishing resistance is a key driver behind federal mandates. Executive Order 14028 requires passwordless, phishing-resistant authentication to protect critical infrastructure.

While passkeys provide significant advantages, they also come with a few significant challenges and problems.

• User experience: Passkey prompts such as requests to insert the security key into the USB port or enter the PIN, for example, look different depending on the operating system and browser. Those prompts will likely make it more difficult to train users and increase support calls.
• Distraction from other attacks: Anyone who thinks that the use of passkeys suddenly makes them immune to MFA bypass like social engineering attacks is very much mistaken. Passkeys help against one type of social engineering attack: phishing. Unfortunately, there are other variants. The attacks on MGM Resorts or Caesars Palace in Las Vegas had a social engineering component: exploiting the help desk to allow the attacker to register an MFA authenticator himself.
• Device loss or upgrade challenges: If users lose access to a device supporting device-bound passkeys, they can’t be recovered.
• Limited support across all services: While adoption is growing, not all websites or enterprise systems support passkeys yet, which can limit their day-to-day usability.
• User confusion or lack of awareness: The concept of passkeys is still new to many users, which can lead to confusion about setup, syncing, or what’s happening under the hood. Variations in terminology (passkeys, security keys, FIDO keys) and evolving standards across the industry can increase this confusion and make it challenging for users and organizations to clearly understand best practices and consistently implementing and adopting passkeys. This can also lead to mistakes during setup and use, increased support calls, and potential gaps in security.
• Infrastructure readiness: Deploying passkeys may require organizations to make updates to identity platforms, device management policies, and training efforts—especially when moving away from legacy authentication. Organizations may find that legacy or on-premises resources may not be compatible with passkeys due to web-only authentication. In those cases, organizations should modernize their MFA with passwordless capabilities that can span environments and maintain legacy infrastructure.

Given the challenges today’s passkeys pose when it comes to delivering uniform workflows across various browsers, devices, and operating systems, what can the industry do to ensure a truly seamless, cross-platform experience? How can we determine the best path to resolving the inconsistencies that may confuse users and stall widespread adoption?

At RSA, our UX leadership is actively involved in the FIDO Alliance’s working groups to advocate for consistent user experiences. By contributing our insights, we aim to help shape standards that result in fewer distractions, less friction, and more uniformity for end users.

Mobility is another aspect of creating a seamless passkey experience across environments. Workforce users increasingly expect the convenience of mobile-first workflows. If accessing corporate resources on a smartphone feels as intuitive as unlocking that same device, adoption of new authentication methods—like passkeys—becomes significantly easier. A frictionless mobile experience helps break down user resistance, minimizing the learning curve and making the transition away from passwords far smoother. By delivering an interface that’s familiar, transparent about permissions, and consistent regardless of the user’s device or platform, organizations can reduce confusion and improve trust. The RSA mobile FIDO solution serves as an example of how to implement a passkey in a device-agnostic manner.

For secure facilities and high-assurance environments where mobile authentication isn’t permitted, the RSA iShield Key 2 Series provides a FIPS 140-3 Level 3, FIDO2-certified hardware authenticator that delivers phishing-resistant, cross-platform passwordless security.

They say that when you have a hammer, everything can look like a nail. Turning a solution—even a great solution—that was originally intended for consumer use into an enterprise application can introduce significant risk.

While reading this article, you may have had a queasy feeling at the mention of “sync fabric.” Your gut was right.

The fact that synced passkeys appear as if by magic on all devices on which the user is logged in via Apple or Google is a major red flag in the corporate environment and should raise some significant questions:

• Should users be allowed to use several (possibly also privately used) devices for authentication at all? If so… how many?
• Synced passkeys make restoring a “lost” passkey possible with the account recovery processes of, say,Google or Apple. That’s great… but are these processes secure enough for you?
• The Apple feature that allows users to share passkeys with friends or family is quite nice… but does this also apply to passkeys that are used to log in to enterprise applications?

When using synced passkeys, the security of your company suddenly depends largely on the technical and organizational security of Apple and Google. Sure, there is a certain dependency anyway due to the use of iOS and Android—but synced passkeys increase this dependency considerably.

This isn’t a theoretical vulnerability, either. Retool discussed how threat actors had used it to gain access to its systems, noting that the functionality means that “if your Google account is compromised, so now are your MFA codes.”

Whether passkeys should be used in the company cannot be answered in a general way. Every organization is different and must balance its unique security and operational priorities.

Moreover, whether to use passkeys shouldn’t be a yes/no question. The introduction of passkeys or passwordless logins in general should be used to fundamentally review an organization’s entire MFA processes. What has been good for hardware OTP tokens for 15 years is probably no longer entirely true for passkeys or other MFA methods today.

RSA believes that passkeys can be deployed for enterprise use if they align with organizational strategy and if organizations think through their answers to the following questions. We’ve seen organizations use passkeys successfully with RSA^® ID Plus, our comprehensive identity and access management (IAM) platform that provides a range of passwordless options.

Because we’re a security-first organization and use Secure by Design / Secure by Default principles, we prevent using synced passkeys by default. Only device-bound passkeys are available by default in RSA environments to provide the maximum level of security out-of-the-box, and without any extra work by admins.

When assessing whether to introduce passkeys, organizations should ask: How are our authenticators registered? Are there processes that safely handle the “I lost my authenticator” scenario? What about the classification of users, applications, and data?

Passkeys are one MFA method among many. Yes, their phishing resistance is fantastic, but can users log in with it on all the protected resources they need to access.

For these reasons and many others, it’s important that your MFA system isn’t just technically up to date, but that it also supports a wide variety of MFA methods, such as QR codes, biometrics, OTP, push messages, and passkeys.

It is also important that the processes around MFA are adapted to new threats. This goes far beyond the actual MFA system: is your help desk also safe from social engineering attacks?

If passkeys make sense to you, then we want to help. Contact us to learn more or start a free, 45-day trial of ID Plus.

Deciding to deploy passkeys is the easy part. This guide covers the three phases of a successful rollout — assessment, pilot, and enterprise deployment — with real-world examples from organizations that have made the journey. For a full overview of RSA’s passwordless capabilities, visit the RSA passwordless solutions page.

Phase 1: Assessment and planning (four to eight weeks)

1. Conduct an authentication audit. Map every application. infrastructure and system that require or are involved with authentication, noting which which ones don’t yet support FIDO2.
2. Identify high-risk user groups. Privileged admins, finance staff, remote workers, and shared-device users each need different approaches — segment your workforce by risk level before planning deployment.
3. Define your passkey policy. Decide which populations should use device-bound passkeys, synced passkeys, or a mix. RSA recommends device-bound as the default, with synced passkeys reserved for cases where the trade-off is justified.
4. Review internal policy which may impact use of passkeys, such as constraints on use of USB ports, BLE or mobile devices. Create a phased deployment timeline. Set milestones, assign owners, and define go/no-go criteria. Get executive alignment early.

Phase 2: Pilot deployment (six to ten weeks)

1. Choose your pilot group carefully. IT and security staff make ideal first users. Adding a small group of executive assistants helps reveal practical edge cases like shared computers and delegation scenarios.
2. Depending on your use cases, test both passkey types in your environment. Validate enrollment, login, re-authentication after device sleep, and SSO across the device types and operating systems your organization uses.
3. Build and test help desk procedures. Run through lost device, forgotten PIN, onboarding and offboarding scenarios before they happen in production. Help desk staff should be able to execute recovery workflows securely without being susceptible to social engineering.
4. Define success metrics. Track enrollment rates, authentication success/failure rates, and help desk ticket volume as baselines before scaling.
5. Collect structured feedback. Survey pilot users at two and six weeks. Use what you learn to update training materials and configuration before broader rollout.

Phase 3: Enterprise rollout (two to six months)

1. Launch a change management program. Short video walkthroughs and written job aids work better than long documentation. Tailor content by user segment — a remote developer’s experience looks different from a shared-workstation floor user’s.
2. Roll out in waves. Deploy by department, geography, or risk tier. High-risk users typically go first; shared-device and legacy-dependent users last.
3. Keep backup authentication methods available. Don’t remove legacy MFA immediately. Maintain OTP push, QR codes, or hardware tokens as fallbacks until enrollment reaches your target threshold (typically 90%+ per department).
4. Monitor adoption and authentication health. Use platform dashboards to track enrollment completion, failure rates, and help desk trends. Set alerts for anomalies early.
5. Close the loop with security. After full deployment, update your MFA policy documentation and run a post-deployment review. Passkeys eliminate credential phishing — but social engineering at the help desk remains a real risk.

The following are illustrative examples based on common deployment patterns.

Scenario 1: Financial services—regional bank, 5,000 employees
A mid-size regional bank deployed device-bound passkeys via RSA ID Plus with FIPS 140-3 certified hardware security keys for privileged users and branch staff.

• Key challenge: Legacy teller application required a FIDO2 proxy layer; help desk staff needed social engineering resistance training before rollout.
• Passkey type: Device-bound hardware security keys
• Timeline: Six months
• Outcomes: 43% help desk ticket reduction; zero password-related breaches post-deployment

Scenario 2: Government—federal agency, 12,000 employees
A civilian federal agency needed to meet EO 14028 and OMB M-22-09 phishing-resistant MFA mandates across a hybrid environment that included air-gapped classified network segments.

• Key challenges: Air-gapped segments needed internet-free authentication; a legacy case management system required a FIDO2 proxy layer; 30+ field offices needed remote enrollment support.
• Passkey type: FIPS 140-3 Level 3 RSA iShield Key 2 for all staff; RSA DS100 OTP tokens for air-gapped segments
• Timeline: Ten months
• Outcomes: Full EO 14028 / M-22-09 compliance certified; credential capture rate dropped from 18% to under 1%; 38% help desk ticket reduction