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.
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 FIDO 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 log-in 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, as its largest members are active in this area: Apple, Google, PayPal, and Microsoft. (RSA is a member of the FIDO Alliance and 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 key pair.
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 organization. It’s important to address that ambiguity, because not all passkeys are created equal or appropriate for enterprise use.
There are now two types of passkeys, as defined by the FIDO alliance: device-bound and synced.
Device-bound passkeys are generally hosted on specific ‘security key’ devices. On a device-bound passkey, key pairs are generated and stored on a single device; moreover, the key material itself never leaves that device.
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 available on all your other Android devices shortly after.
Synced passkeys are—in addition to 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 are an excellent MFA method: safe, fast, convenient, and users are already familiar with them. But the passkey benefit that’s beginning to get a lot of attention is that they’re phishing-resistant.
Passkeys can help organizations stop traditional phishing in its tracks: if there’s no password being used, then there’s no password to steal. And while that’s true for other passwordless MFA methods, passkeys have an added level of security provided by that synched key/service domain match.
In the U.S., phishing resistance is a major driver for government agencies. Executive Order 14028 requires phishing-resistant, passwordless authentication to secure critical infrastructure.
While passkeys provide significant advantages, they also come with a few significant challenges and problems.
For a solution that has grown up in the consumer environment, user guidance and the user experience can sometimes be a challenge.
Dialogs that ask the user to insert the passkey 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 minimize support calls.
Why not just change the prompts you ask? Because third-party service providers like RSA can’t: those prompts are set by the browser or OS vendor themselves in their own vendor (for instance, Apple sets their prompt for iOS, Google for Chrome, etc). There’s some good reason for this: if vendors could change the prompt, then so could attackers, using an updated form to spy on users. Keeping those log-in prompts locked is an important security measure, but it can make for a one-size-fits-all approach.
The high level of phishing resistance is a clear advantage, but it can also be a distraction. Anyone who thinks that the use of passkeys suddenly makes them immune to 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.
Attackers adapt as a matter of course. The proliferation of MFA has made phishing much less attractive, so it’s only natural that vulnerabilities around the MFA system are exploited. Such as the way users register. Anyone who thinks passkeys solve these problems is very wrong.
They say that when you have a hammer, everything can look like a nail. Turing 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 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 e.g. Google or Apple. That’s great… but are these processes secure enough for you?
- The Apple feature that allows users to share Passkey 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. Last year Retool discussed how threat actors had used it to gain access to its systems: Retool wrote 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 login 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 using 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-out-the-box, and without any extra work required 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 their remote desktops?
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 FIDO 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.
