Implementing Passkeys in the Enterprise: A Practical Guide

Passkeys are phishing-resistant and cannot be stolen from a server database. With Apple, Google and Microsoft now providing the infrastructure in their ecosystems, enterprise deployment is a realistic prospect. New research from August 2026 shifts what matters in a rollout: not the choice of passkey type, but endpoint security.

What are passkeys and how do they work?

A passkey is a cryptographic key pair instead of a password. During registration, the device generates a private and a public key. The private key remains stored locally, whilst the public key is held by the service. Each signature is bound to the exact domain of the service, which renders any fake login page inherently ineffective.

A server attack therefore only captures public keys, which are worthless on their own. Even credential stuffing comes to nothing, as there is no reusable secret.

With device-bound passkeys, the private key remains on the hardware, for example in the TPM or on a FIDO2 token. With synchronised passkeys, it is stored in encrypted form in the provider’s cloud wallet and is available on other devices.

Earlier versions of this post recommended synchronised passkeys for widespread roll-out and device-bound passkeys only for privileged accounts. This distinction is no longer valid.

Switching between synchronised and device-bound passkeys does not eliminate the attack surface. Both variants are vulnerable as soon as malware is running in the user’s context.

Why are traditional MFA methods insufficient?

SMS codes and time-based one-time passwords have a structural weakness: they are transferable secrets. A fake login page can relay the entered code to the genuine service in real time before it expires, compromising the account whilst the user believes they are on the correct page.

Push-based MFA has another vulnerability. Push requests have no cryptographic link to the specific login session. The authorisation applies to the attacker’s session, not to an authentic connection initiated by the user.

A passkey signature is bound to the exact domain of the service and valid for that session only. An attacker who intercepts or forwards the request holds a one-off, domain-bound token, not a reusable secret.

How secure are passkeys?

Passkeys are resistant to phishing; the cryptography behind them remains intact. However, three research papers from August 2026 show that both types of passkey are vulnerable as soon as malware is running on the endpoint.

On 3 August 2026, Unit 42 from Palo Alto Networks described the Pass-ta-key attack family targeting the Google Password Manager in Chrome. Malware without elevated privileges signs a WebAuthn assertion via the Windows CNG interface without a PIN or biometric prompt appearing. The ‘Golden’ variant of Pass-ta-key reads the Security Domain Secret from the Chrome process memory, uses it to decrypt all synchronised passkeys and exports them in a transferable format.

A further variant from Unit 42: ‘Silver’ Pass-ta-key spoofs a biometric unlock against the Cloud Authenticator without using the victim’s device during the login session. The attacker logs in from their own environment; the victim’s device does not need to be online. Unlike the basic variant, access gained this way is reusable; elevated privileges are not required here either.

On 5 August 2026, Dirk-jan Mollema demonstrated that a Windows Hello for Business key can be used from within a logged-in session. The call via Ncrypt.dll and the Passport Key Storage Provider requires neither a PIN nor biometrics, but instead relies on cached data. The login is successful even in an incognito window without SSO support, and without a device enrolled in Entra ID. From a compromised session, a device can thus be registered and a Primary Refresh Token requested.

On the same day at Black Hat USA, SpecterOps presented the Pass-the-Passkey chain. Windows stored FIDO2 signatures in plain text, where authenticated unprivileged users could read them, even remotely. It is not the private key itself that is extracted, but a signature that has already been generated.

CVE-2026-34348 affects the Windows Event Logging Service and is classified as an information disclosure vulnerability with a CVSS Base score of 6.5. An update is available and must be applied immediately to all Windows clients and servers.

Three Recommended Actions

1. Apply the CVE-2026-34348 update to all Windows systems. This affects environments with Windows Hello for Business as well as those with FIDO2 hardware keys.
2. Monitor logins via Windows Hello for Business without a registered device ID. The following query in Entra ID corresponds to the pattern demonstrated by Mollema.
3. Set userVerification = required in custom web applications and validate the UV flag server-side. Setting the parameter alone is not sufficient: eBay had set it but remained vulnerable because the response was not validated.

SigninLogs
| where AuthenticationDetails has ‘"authenticationMethod":"Windows Hello for Business"’
| where DeviceDetail.deviceId == ""

Deadlines in Microsoft Entra ID

For organisations whose users have only SMS or voice authentication methods configured after 1 February 2027, passkey registration will be blocked at login. Microsoft does not provide an opt-out option.

Setting Up Passkeys

Setting up passkeys with Microsoft

Activation takes place in Entra ID under Security > Authentication Methods > Microsoft Authenticator using the Passkey (FIDO2) function. Self-registration is enabled in the same dialogue box. For privileged accounts, a FIDO2 token is also recommended.

A Temporary Access Pass with limited validity is suitable for initial access. Users log in with it once and then register their own passkey.

New-MgUserAuthenticationTemporaryAccessPassMethod `
  -UserId "user@company.com" `
  -LifetimeInMinutes 60 `
  -IsUsableOnce $true

A Conditional Access policy using the Authentication Strength setting for phishing-resistant methods excludes SMS codes and time-based one-time passwords. Windows Hello for Business covers the native registration process on Windows devices and works with a PIN or biometrics.

Setting up passkeys with Google

Activation takes place in the Google Admin Console under ‘Security’, ‘Authentication’, ‘Passwordless sign-in’. The option for passwordless sign-in via passkey can be enabled there. The enforce-passkeys toggle should only be set once the roll-out has been fully completed across the organisation.

Users set up their passkeys via myaccount.google.com under ‘Security’. On Android devices, the Google Password Manager handles this task. For signing in via a Windows PC without a stored passkey, Windows Hello or a FIDO2 hardware token is available.

For cross-device sign-ins, the browser displays a QR code; the smartphone scans it and performs a Bluetooth proximity check, then unlocks the passkey for the sign-in session on the PC. This is called cross-device authentication and requires no shared account between the devices.

Passkeys on Apple devices

With iCloud Keychain enabled, passkeys are available on all Apple devices linked to the same account; they are managed via the Passwords app. A new device is authorised via an already set-up device or the old device code, after which the Keychain updates automatically.

For businesses, this is the boundary case: the Keychain is linked to employees’ personal accounts, not to the organisation. Where employees bring personal Apple devices, the passkey therefore falls outside the organisation’s control. For privileged accounts, a FIDO2 token is therefore the more robust choice.

What are the disadvantages of passkeys?

Passkeys have three practical limitations: device loss requires re-registration, as the private key is non-transferable; applications without WebAuthn support are integrated via single sign-on (SSO) using SAML or OpenID Connect; and staff without a biometric device need a hardware token or PIN.

If a device is lost, a second registered method can help. A sensible approach is to combine a smartphone with a hardware token, supplemented by an administrative reset procedure.

The identity provider handles the passkey sign-in; the legacy application receives its token via SAML or OpenID Connect.

Employees without a biometric device use a hardware token or a PIN via Windows Hello. On personal devices, a passkey remains the stronger choice compared to a password with a time-based one-time password.

Assessment

Passkeys remain the most resilient defence against phishing, and the underlying cryptography is uncompromised. What has shifted is the endpoint’s role: losing control of the client means losing phishing-resistant authentication. In the risk analysis of an information security management system, endpoint compromise should be treated as a separate scenario, independent of which passkey type is deployed. Security awareness training ensures employees support the transition.