Are passkeys ready for the enterprise? A qualified yes

Passkeys are a genuine step forward but they don’t ‘solve’ identity security

Last week, the UK National Cyber Security Centre (NCSC) issued a recommendation that the default online authentication method for businesses and consumers should be passkeys.

The agency noted that previous implementation challenges have been overcome and listed advantages over passwords including resistance to phishing and credential theft, as well as improved ease of use.

But while passkeys are an improvement on passwords in security terms, they are not perfect, and there are inevitable trade‑offs in their implementation.

How do passkeys work?

For authentication, passkeys replace something you know with something you have. Instead of asking users to create, remember and safeguard a long string of characters, passkeys use devices they already trust - phones, laptops and security keys - as the primary factor, with local authentication carried out using biometrics or a PIN.

Unlike passwords, passkeys cannot be guessed, reused or phished, meaning they close off several important entry routes for attackers.

“Passkeys are like passwords, but better and inherently more secure because they aren’t created insecurely by humans,” said Niall McConachie, regional director UKI at authentication company Yubico. “Rather, they use public‑key cryptography to create fully secure experiences.”

When a user first registers with an online service their device generates a unique cryptographic key pair. The public key is shared with the service, while the private key is stored on the device in a secure isolated enclave, such as a Trusted Platform Module (TPM), which is protected from unauthorised access.

When the user next logs in, the service sends a challenge encrypted with the public key. Authentication only succeeds if the device can prove possession of the private key by decrypting and responding to the challenge, typically after the user unlocks access locally using a PIN or biometric authentication.

“If the user successfully deploys their private key to respond to the challenge, they are authenticated into the application. In this way, the authentication process is like a handshake between the public key and the user’s private hardware key,” McConachie said.

Crucially, the private key is never transmitted, which is what makes passkeys resistant to phishing and credential theft.

Passkeys can be synchronised

For ease of use, passkeys can be synchronised, making authentication seamless across devices associated with the same online service. Apple, Google and Microsoft all store passkeys in secure, platform‑managed credential vaults and synchronise them across users’ devices via their cloud accounts. This is obviously convenient - but it is also one of the key trade-offs.

“While synced passkeys offer convenience within specific platform ecosystems, they inherently tie a user’s security to their phone or cloud account,” McConachie explained. “This can introduce risks for security conscious individuals and organisations by creating attractive failure points for attackers.”

An alternative is to store the passkey on a physical security key. These are not synchronised, cannot be cloned, and remain under the user’s physical control - but for many users this will be less convenient. Organisations must also factor in the cost of purchasing keys and providing backups.

Are passkeys ready for the enterprise? What are the gotchas?

The NCSC explicitly recommends passkeys for business as well as personal use, and they can already be used with several enterprise systems.

Identity and access management vendors including Okta and Ping Identity support passkeys. Google Workspace allows enterprises to enable them, and Microsoft is in the process of integrating passkeys into Entra ID. However, support is not universal. On-premises Active Directory does not support passkeys, nor do many legacy enterprise applications.

In practice, this means passwords will be with us for years, with organisations operating in a hybrid world that supports passkeys alongside passwords and MFA. This limits some of the immediate operational gains. Helpdesk assistance with password resets and SMS one-time codes will not disappear overnight, and employees will still need support with authentication and account recovery.

Enterprises must also address device loss, employee onboarding and offboarding and privileged access.

There are other trade‑offs between convenience and security. For example, some platforms allow multiple passkeys to be added to a single account. This handy but it introduces risk, said Jared Atkinson, CTO at adversary-simulation firm SpecterOps.

“If I gain the ability to set up a passkey, I can backdoor your account with an additional passkey and maintain long-term access.”

Other vendors deliberately restrict users to a single passkey to force recovery and detection, trading user experience for visibility and control. For admin accounts this is probably a trade worth taking, but even then it’s not a substitute for post‑authentication controls.

“Ultimately, strong authentication is only the starting point,” Atkinson added. “Businesses really need to be looking at controlling what users can access and do once they are inside.”

That means focusing on session controls, least privilege, re‑authentication for sensitive actions and visibility into identity attack paths - not just login methods.

“Passkeys have real potential to reduce risks like phishing and credential theft. The problem is they don’t fully remove identity risk - they just move it onto devices, account recovery processes and the platforms managing those identities,” said Spencer Young, SVP international at identity security company Delinea.

“Stronger login security is only half the story for businesses. The real challenge is what happens after authentication - controlling access and privilege once human and nonhuman identities are inside, and making sure those identities are secured, monitored and governed.”

What about lock‑in?

Passkeys are based on open standards such as FIDO2 and WebAuthn, which are supported across major browsers and operating systems. In theory, this limits vendor lock‑in. In practice, lock‑in can occur at a layer above the standard itself.

Synchronised passkeys place significant power in the hands of platform providers, particularly around account recovery. Losing access to a cloud account could affect access to passkey-protected sites. Moving between vendor ecosystems can also be difficult, with recovery mechanisms that are platform specific.

Understandably, given its focus on national resilience, the NCSC does not dwell on these risks. However, organisations would be wise to consider the consequences. In practice, measures could include using hardware security keys or hardware‑bound passkeys with attestation - cryptographic proof of device identity and integrity - for high‑privilege accounts.

In conclusion, passkeys are a genuine step forward and most organisations will benefit from their protections, but they do not “solve” identity security. They remove the most unsafe aspects of passwords, while shifting risk towards devices, recovery processes and post‑authentication controls.