passkeys
Transition to passkeys promises organizations a cost-effective path toward robust employee authentication, increased productivity, and regulatory compliance. We’ve already covered all the pros and cons of this business solution in a separate, in-depth article. However, the success of the transition — and even its feasibility — really hinges on the technical details and implementation specifics across numerous corporate systems.
Passkey support in identity management systems
Before tackling organizational hurdles and drafting policies, you’ll have to determine if your core IT systems are ready for the switch to passkeys.
Microsoft Entra ID (Azure AD) fully supports passkeys, letting admins set them as the primary sign-in method. For hybrid deployments with on-premises resources, Entra ID can generate Kerberos tickets (TGTs), which your Active Directory domain controller can then process.
However, Microsoft doesn’t yet offer native passkey support for RDP, VDI, or on-premises-only AD sign-ins. That said, with a few workarounds, organizations can store passkeys on a hardware token like a YubiKey. This kind of token can simultaneously support both the traditional PIV (smart cards) technology and FIDO2 (passkeys). There are also third-party solutions for these scenarios, but you’ll need to evaluate how using them impacts your overall security posture and regulatory compliance.
Good news for Google Workspace and Google Cloud users: they offer full passkey support.
Popular identity management systems like Okta, Ping, Cisco Duo, and RSA IDplus also support FIDO2 and all major forms of passkeys.
Passkey support on client devices
We have a detailed post on the subject. All modern operating systems from Google, Apple, and Microsoft support passkeys. However, if your company uses Linux, you’ll likely need extra tools, and overall support is still limited.
Also, while for all major operating systems it might look like full support on the surface, there’s a lot of variety in how passkeys are stored, and that can lead to compatibility headaches. Combinations of several systems like Windows computers and Android smartphones are the most problematic. You might create a passkey on one device and then find you can’t access it on another. For companies with a strictly managed device fleet, there are a couple of ways to tackle this. For example, you could have employees generate a separate passkey for each company device they use. This means a bit more initial setup: employees will need to go through the same process of creating a passkey on every device. However, once that’s done, signing in takes minimal time. Plus, if they lose one device, they won’t be completely locked out of their work data.
Another option is to use a company-approved password manager to store and sync passkeys across all employees’ devices. This is also a must for companies using Linux computers, as its operating system can’t natively store passkeys. Just a heads-up: this approach might add some complexity when it comes to regulatory compliance audits.
If you’re looking for a solution with almost no issues with sync and multiple platforms, hardware passkeys like the YubiKey are the way to go. The catch is that they can be significantly more expensive to deploy and manage.
Passkey support in business applications
The ideal scenario for bringing passkeys into your business apps is to have all your applications sign in through single sign-on (SSO). That way, you only need to implement passkey support in your corporate SSO solution, such as Entra ID or Okta. However, if some of your critical business applications don’t support SSO, or if that support isn’t part of your contract (which, unfortunately, happens), you’ll have to issue individual passkeys for users to sign in to each separate system. Hardware tokens can store anywhere from 25 to 100 passkeys, so your main extra cost here would be on the administrative side.
Popular business systems that fully support passkeys include Adobe Creative Cloud, AWS, GitHub, Google Workspace, HubSpot, Office 365, Salesforce, and Zoho. Some SAP systems also support passkeys.
Employee readiness
Rolling out passkeys means getting your team up to speed regardless of the scenario. You don’t want them scratching their heads trying to figure out new interfaces. The goal is for everyone to feel confident using passkeys on every single device. Here are the key things your employees will need to understand.
- Why passkeys beat passwords (they’re much more secure, faster to sign in with, and don’t need to be rotated)
- How biometrics work with passkeys (the biometric data never leaves the device, and isn’t stored or processed by the employer)
- How to get their very first passkey (for example, Microsoft has a Temporary Access Pass feature, and third-party IAM systems often send an onboarding link; the process needs to be thoroughly documented, though)
- What to do if their device doesn’t recognize their passkey
- What to do if they lose a device (sign in from another device that has its own passkey, or use an OTP, perhaps given to them in a sealed envelope for just such an emergency)
- How to sign in to work systems from other computers (if the company’s policies permit it)
- What a passkey-related phishing attempt might look like
Passkeys are no silver bullet
Moving to passkeys doesn’t mean your cybersecurity team can just cross identity threats off their risk list. Sure, it makes things tougher for attackers, but they can still do the following:
- Target systems that haven’t switched to passkeys
- Go after systems that still have fallback login methods like passwords and OTPs
- Steal authentication tokens from devices infected with infostealers
- Use special techniques to bypass passkey protections
While it’s impossible to phish the passkey itself, attackers can set up fake web infrastructure to trick a victim into authenticating and validating a malicious session on a corporate service.
A recent example of this kind of AiTM attack was documented in the U.S. In that incident, the victim was lured to a fake authentication page for a corporate service, where attackers first phished their username and password, and then the session confirmation by having them scan a QR code. In this incident, the security policies were configured correctly, so scanning this QR code did not lead to successful authentication. But since such a mechanism with passkeys was implemented, the attackers hope that somewhere it is configured incorrectly, and the physical proximity of the device on which authentication is carried out and the device where the key is stored is not checked.
Ultimately, switching to passkeys requires detailed policy configuration. This includes both authentication policies (such as disabling passwords when a passkey is available, or banning physical tokens from unknown vendors) and monitoring policies (such as logging passkey registrations or cross-device scenarios from suspicious locations).
Tips