Introduction to Passkeys

Security

Passkeys are a new standard for authentication that provide users with an alternative to traditional passwords that is much easier to use, and far more secure. The name "passkey" is a play on "password" to be more recognizable to end users, but they are not at all similar to passwords. The FIDO Alliance added passkeys as an extension to the WebAuthn specification, and since then industry adoption has been steadily growing and user demand is increasing. Passkeys are meant to replace passwords, but they do not imply "passwordless". Just because a passkey is used for authentication doesn't mean the user can't also use a password. Service providers that do support passwordless are likely to require a passkey as the primary authentication factor, but many service providers will allow users to have both for the immediate future. A passkey is essentially a new, specialized type of self-signed certificate generated on the client. It utilizes asymmetric encryption with a public and private key pair (similar to certificates used for code-signing or web server encryption). This diagram provides a simplified explanation of how passkeys are used for sign-in:

Usage scenarios and details

Passkeys are resistant to phishing attacks

Passkeys can only be used with the original site they were created for, which prevents them from being used with a malicious site masquerading as another site. This circumvents the most common types of phishing and Adversary in the Middle ("AITM") type of attacks. Proper security has always been a journey with an ever-changing threat landscape, and passkeys are the next solution along the way. Passkeys will likely need to evolve as attackers find new methods to phish accounts from users.

Passkeys can be device-bound or multi-device

There are different options available for where passkeys are stored and how they can be managed (e.g., synced, exported, backed up, etc.). When passkeys are created and used, each site or service provider can choose to enforce specific policies such as where they are stored, whether they are restricted to a single device, or allowed to be synced across multiple devices. Although Microsoft Entra ID supports multiple passkey types and multiple storage providers, for now Microsoft 365 has imposed stricter limits:

  • Device-bound passkeys only
  • Microsoft Authenticator for storage only

Note: At this time M365 support for passkeys is in public preview so these requirements may change in the future, but it's unknown if they will change before the feature reaches General Availability.

Passkeys can also be used as a way for an existing device to help authenticate another device

Sites and service providers may choose to support Cross-Device Authentication ("CDA"), which allows a passkey from one device to be used to sign in on another device. For example, if you can already sign-in with a passkey on your phone for a site and that site allows CDA, you can sign in from your laptop by using the passkey from your phone. The implementation details will vary by site but will usually involve the new device displaying a Quick Response ("QR") code that is scanned by the camera of the existing device, and ideally will require a proximity check using Cloud-Assisted Bluetooth Low Energy ("caBLE"). Without ensuring both devices are in close proximity, this process can be exploited by phishing attacks (e.g., an attacker in one location could generate the QR code and use phishing/social engineering to get the user in a different location to scan it).

The way passkeys are stored and how they are accessed varies and is still changing

Passkey adoption is changing rapidly, and therefore the user experience differs between operating systems and platforms, and between browsers & apps on the same device. Conditional UI / Autofill UI / Conditional Mediation is a standard that's gaining adoption, but not all operating systems, browsers and apps support it yet. When an app or browser asks the devices to create a passkey, the operating system will usually prompt with the default storage location (e.g., the device's TPM/T2 hardware encryption, iCloud Keychain, etc.) but may also provide other options like password manager apps that are installed.

Users will have multiple passkeys, quite often in multiple passkey provider stores

As passkeys become more prevalent, most users will have many different passkeys stored in different locations. For example, a user on an iPhone will likely have multiple passkeys for various sites stored in their iCloud Keychain, and these are automatically synced so they can be used from other MacOS/iPhone/iPad devices. That same phone might also have a passkey for M365/Azure/Entra stored in the Microsoft Authenticator app, and this cannot be synced across devices. That same phone might also have passkeys for various sites stored in password management apps like Bitwarden and 1Password, which can be synced and used on other Windows/non-Apple devices. That same user might also have a Windows device with passkeys stored for various sites in the TPM, and these are not synced across multiple devices (although Microsoft plans to implement this someday).

The security strength varies depending on how the passkey is stored and accessed

Not all passkeys provide the same security-to-convenience ratio. Hardware-based FIDO2 Security Keys (essentially the original passkeys) are generally considered the most secure option because the private key store is never accessible to software running on the host machine, but are less convenient and must be purchased. Device-bound passkeys (aka single-device) provide the next highest security, but are less convenient because they must be set up for each device. Multi-device passkeys (aka synced) provide more convenience but are considered less secure because the risk of the replicated storage being compromised increases with each copy (depending on the implementation and the type of MFA used to protect the passkey storage). An extension has been proposed to the WebAuthn spec called supplementalPubKey which aims to increase the security of synced passkeys by adding supplemental keys for an additional layer of authentication. These supplemental keys would never be allowed as standalone authentication methods, but rather augment the primary passkey, reinforcing its trustworthiness with evidence of device integrity. These supplement keys could help determine user risk, for example Conditional Access Policy could require an additional key when a user sign-in comes from an unusual geographic location. Apple has also added passkey support for shared password groups, so they can be shared with contacts, family, and Shared Groups. Sharing a passkey via AirDrop works similarly on MacBook, iPad, and iPhone.

Regulatory requirements and compliance certifications are still catching up

Passkeys are relatively new, and many regulatory requirements have not yet published guidance on how support for them should be implemented, so environments that are heavily regulated and required to meet specific compliance certifications may need to wait before supporting them. Recent announcements like this are a good indication that the industry adoption is coming: NIST cites phishing resistance of synced passkeys, confirms that synced passkeys can meet Authentication Assurance Level 2 (AAL2) and device-bound passkeys can be AAL3.

Considerations for Passkeys During M&A

Support for passkeys is not something that can be enabled for all apps at once, most enterprises will need to take a phased approach and adjust policies as they go in order to support passkeys in a way that still allows them the organizational control needed to ensure secure and effective management. This incremental plan should take into account the upcoming M&A projects on the horizon.

What if a company is acquired that uses passkeys, what considerations should be taken during the migration?

If the acquiring company does not have policies and guidelines published for how passkeys are supported and used, that is the best place to start. This policy should be comprehensive and apply to both existing users as well as new users hired or acquired. Passkey usage in the source environment should be included in the application discovery and then categorized:

  • Which apps in the source environment support passkeys and will be migrated and supported in the new environment?
  • Which apps in the source environment support passkeys and will not be migrated or supported, but still allowed?
  • Which apps in the source environment support passkeys and will no longer be allowed?

In this context, how passkeys are handled during a migration would be very similar to how password manager apps and MFA apps will be handled. For example, if the source environment uses password manager apps (e.g., Bitwarden, Roboform, 1Password, KeePass, Dashlane, NordPass, Enpass, LastPass, etc.) the export options for those apps will dictate how both existing passwords and passkeys can be imported to the standardize app in the target environment.

What if the acquired company uses passkeys on their devices, how would that affect a migration?

Migration options for passkeys are limited at this time, but will likely improve as the demand increases and the tools mature. The options available will be different depending on whether the passkey is device-bound or is allowed to be synced, exported, or backed up. Passkeys are locked to specific sites and are typically tied to specific user accounts, so the scenarios that will support passkey migrations are limited.

  • For scenarios like M365 that are only allowing device-bound passkeys, it is unlikely there will be any migration options, new passkeys will need to be generated
  • For passkeys that are synced between devices and/or stored in a password manager app, the migration options will vary depending on what the source and target vendors support for export and import

Passkey support comes in different varieties

When evaluating passkey support across sites and service providers, keep in mind:

  • Find out if the website or service provider supports passkey authentication, and verify if that support also applies when authentication is configured for enterprise single sign-on ("SSO")
  • Find out if the website or service provider supports passkeys in all of their client apps and all of their supported browsers or only those that support pseudo-random function ("PRF") extension

When evaluating password management apps and MFA apps, there are additional levels or types of passkey support:

  • Are passkeys supported for vault decryption?
  • Does the vault support storing passkeys?

Conclusion

Passkeys are being widely adopted and will make the M365/Entra ecosystem more secure than passwords and other two-factor methods. Although passkeys might at first seem like a big change for the average user, that is likely to change very soon. If the momentum continues then users will soon be very familiar with using passkeys with other services (e.g., Adobe, Amazon, Apple iCloud, Google, LinkedIn, PayPal, TikTok) and using them for enterprise accounts won't seem much different. The initial setup process for users is already very simple and the consistency between platforms and apps will continue to improve. At this time M365 only allows device-bound passkeys stored in the Microsoft Authenticator app, so the implementation details for a pilot would be fairly simple to manage. If Microsoft were to allow synced passkeys or alternate storage providers in the future, that would require more discussion about which options your organization would allow and support. M365 support for passkeys is currently in public preview, so most organizations will want to wait until the feature reaches General Availability ("GA") before rolling it out to end users. To prepare for a pilot of this in M365, here are some suggestions:

  • Run a report that shows which devices would be supported for a pilot:
    • iOS / iPadOS 17+
    • Android 14+
  • Run a report that shows which of those devices have the latest version of Microsoft Authenticator installed:
    • Version 6.8.7 or newer for iOS / iPadOS
    • Version 6.2404.2444 or newer for Android
  • Optionally create a policy to always deploy the latest version of Microsoft Authenticator to all devices that have it installed
  • Run a report that shows which users are already enrolled for MFA using Microsoft Authenticator, these users will not need to be issued a Temporary Access Pass ("TAP") to enroll
  • Run a report that shows which users are already using FIDO2 security keys, they would be great candidates for the initial pilot
  • If FIDO2 security keys are already in use without key restrictions enforced, record the Authenticator Attestation Global Unique Identifier ("AAGUID") for these so they can be added to the list of device-bound passkeys that M365 allows
  • If your tenant is still using any legacy policies for MFA and self-service password reset ("SSPR"), migrate away from those and use only the newer unified policies for managing authentication methods (this will simplify the configuration and any troubleshooting)