
Passkeys for enterprises promise a passwordless sign-in that leaves phishing attacks with nothing to steal. In this post, I look at how FIDO passkeys have developed and what that means for companies. Technology giants such as Microsoft, Google and Apple are pushing the topic of passwordless authentication on the consumer side. And on the corporate side?
The FIDO Alliance, founded by companies like Infineon, Lenovo, and PayPal, originally aimed to develop a standard for two-factor authentication (2FA). Over time, this initiative evolved into the passkey, a fully passwordless authentication method based on asymmetric cryptography.
Instead of storing passwords, passkeys utilize a private-public key pair: the private key remains securely stored on the user’s device, while the public key is associated with the specific domain of the service provider.
This domain-specific binding makes passkeys inherently resistant to phishing attacks, as they won’t work on fake sites with mismatched domain names. Our article on AiTM attacks shows how attackers get around conventional MFA.
Passkeys come in two variants: device-bound and synced.
Device-bound passkeys, such as USB FIDO security keys like the iShield Key, store keys locally on a single device.
In contrast, synced passkeys synchronize key material across multiple devices through ecosystems Apple’s iCloud Keychain or Google Password Manager, greatly boosting consumer adoption thanks to seamless cross-device compatibility
But for enterprises, can Passkeys offer the same benefits, or do they introduce potential drawbacks and security concerns? Let’s take a closer look.
| Device-bound passkey | Synced passkey | |
|---|---|---|
Stored on | One device, e.g. a hardware security key | Cloud account with Apple, Google or a password manager |
Can be copied | No | Yes, through synchronization |
IT control | High, model verifiable via attestation | Low, depends on the provider |
Recovery | Backup key and IT process | Via the provider account |
NIST assurance level | Up to AAL3 | Up to AAL2 |
Best suited for | Admins, privileged accounts, regulated areas | Accounts with lower protection needs |
NIST, the US standards body, places synced passkeys at AAL2 at most in its Digital Identity Guidelines (SP 800-63-4). For AAL3, the highest level, it requires a private key that cannot be exported. Device-bound passkeys on a hardware security key meet that requirement.
In Microsoft Entra ID, administrators decide which types of passkeys are allowed. Attestation can also restrict sign-in to specific security key models.
The suitability of passkeys for enterprise deployment depends on a detailed assessment of security needs, user workflows, and MFA processes. Before introducing passkeys, companies should thoroughly review and update their MFA policies, which might have been designed with legacy hardware tokens in mind.
Registration Processes: How are passkeys registered and managed within the company? Are there secure workflows for users who lose their passkeys?
Device Control: How many and which devices should employees be permitted to use for authentication? Should only company-managed devices be allowed, or are personal devices acceptable?
Recovery and Sharing Controls: Apple allows users to share passkeys with family or friends, a convenient feature for consumers but a potential security risk for enterprises. Are recovery and sharing mechanisms secure enough for corporate applications?
Passkeys represent a significant advancement in authentication technology, especially for reducing the risk of phishing attacks. However, their introduction into the enterprise setting requires careful consideration. Beyond technical integration, enterprises need to prepare for potential dependencies on third-party systems, manage device policies, and establish robust processes to safeguard against evolving social engineering tactics. In the end, passkeys may prove to be a valuable addition to enterprise security, provided they are part of a thoughtfully designed and resilient MFA strategy.
From my perspective, there is already a scalable solution for companies seeking enhanced security and phishing resistance: hardware authentication in the form of FIDO security keys. They store device-bound passkeys that can be neither copied nor shared. One example is the iShield Key Pro MIFARE. It supports not only passkeys, but also conventional one-time password (OTP) and personal identity verification (PIV) as well as MIFARE for contactless physical access to company buildings, parking garages, use of the wallbox and payments in the cafeteria.
Today, the range also includes the iShield Key 2 , available with MIFARE DESFire EV3, LEGIC or HID Seos for access control. Our article on physical and logical access explains how this brings the door and the login together.
A device-bound passkey lives on exactly one device, such as a hardware security key, and cannot be copied. A synced passkey is distributed to all of a user’s devices through Apple, Google or a password manager.
For many standard accounts, yes, because they are phishing-resistant as well. The risk shifts to the cloud account at the provider and its recovery process. For admins and regulated areas, device-bound passkeys are the better choice.
That depends on the process the company defines. A proven approach is a second, also registered security key as a backup. IT then removes the lost key from the account.
FIDO Alliance: Passkeys, fidoalliance.org/passkeys
NIST SP 800-63-4: Digital Identity Guidelines (2025), pages.nist.gov
Microsoft Learn: Enable passkeys (FIDO2) in Microsoft Entra ID, learn.microsoft.com
Apple Support: Share passwords and passkeys with contacts, support.apple.com
Want to try device-bound passkeys yourself?