System-preferred authentication

System-preferred authentication prompts users to sign in by using the[added: ir] most secure [removed: method] [added: registered authentication method. For passkeys, it also considers the device and browser the user is signing in from to prioritize a passkey] they [removed: registered.] [added: can use locally.] It's an important security enhancement for users who authenticate by using less secure methods like passwords or SMS.

For example, [removed: if] [added: when system-preferred authentication applies to first-factor sign-in,] a user [removed: registered] [added: with] both a password and a [removed: passkey, system-preferred authentication prompts the user] [added: passkey available on their current device is prompted] to [removed: sign in with] [added: use] the passkey instead of the password. [added: Registering a passkey on one device doesn't mean the user is prompted to use it on every device.] The user can still choose [removed: to sign in by using] another [removed: method, but they're first prompted to try the most secure method they registered.] [added: allowed sign-in method.]

After system-preferred authentication is enabled, [removed: the authentication system does all the work. Users] [added: users] don't need to set [removed: any authentication method as their] [added: a] default [removed: because the] [added: authentication method. The] system [removed: always determines and presents] [added: selects] the [removed: most secure] [added: preferred] method [removed: they registered.] [added: for the applicable authentication step. For passkeys, the initial experience can differ between devices and browsers.]

Note System-preferred authentication is scoped to users, not devices. Administrators include or exclude users or groups but can't assign the feature to specific devices or device groups. [added: This policy scope doesn't mean users see the same passkey prompt on every device. Passkey selection also considers the device and browser used for sign-in.]

[added: When a passkey is the preferred authentication method, system-preferred authentication prioritizes a local passkey when one is available. A local passkey is one the user can access through the current device's built-in authenticator or a passkey provider available on that device or in that browser. The user doesn't need to switch to another device to use it.]

[added: Important The first passkey prompt is a starting point, not a restriction. Regardless of which passkey experience is shown first, users can navigate the browser or operating system's passkey options to use any of their registered local or portable passkeys that is accessible, supported, and allowed by your organization's policies. They don't need to use the suggested passkey or wait for an attempt to fail. See Choose another passkey or sign-in method.]

[added: For example, if a user has a passkey available on their Windows PC and another passkey on their phone, the local passkey experience is prioritized over asking them to use the phone.]

[added: Local doesn't mean the same provider on every device or browser. In Chrome, a passkey saved in Google Password Manager can be the local option. On Windows, Windows Hello for Business can be the local option. The browser and operating system determine which available local provider is displayed, so a user with multiple local passkeys isn't necessarily prompted for Windows Hello first.]

[added: The exact experience also depends on browser and operating system support. If the device or browser can't be identified reliably, the browser or operating system presents its default passkey experience.]

[added: Note A registered passkey isn't necessarily accessible on the device being used. For example, a synced passkey must be available in the user's passkey provider, and the user might need to sign in to that provider or browser profile. A passkey prompt doesn't guarantee that a matching passkey is present.]

[added: System-preferred authentication includes logic for device-bound, nonportable platform credentials: Windows Hello for Business, Microsoft Entra passkey on Windows, and macOS Platform SSO. These credentials stay on the device where they're created. They aren't synced to other devices and can't be used from another device through cross-device QR code sign-in.]

[added: System-preferred authentication uses the operating system to decide whether to offer one of these platform experiences. Using the credential still requires its private key on the original device:]

[added: Registered credential Prompt can appear on Credential works on Windows Hello for Business Windows. Only the Windows PC where the credential was created. Microsoft Entra passkey on Windows Windows. Only the Windows PC where the passkey was created. macOS Platform SSO macOS. Only the Mac where the credential was created.]

[added: These credentials aren't offered on incompatible platforms:]

[added: Windows Hello for Business and Microsoft Entra passkey on Windows aren't offered on non-Windows devices, including a Mac, iPhone, iPad, Android device, or Linux device.]

[added: macOS Platform SSO isn't offered on non-macOS devices.]

[added: If no other applicable passkey is registered, system-preferred authentication continues with the next applicable registered authentication method.]

[added: Note Microsoft Entra ID can identify the operating system, but it can't confirm before the prompt that the current device holds the credential's private key. A user might therefore receive a prompt on a compatible operating system even when the credential isn't available on that device. If no matching credential is available, the user needs to choose another allowed sign-in method.]

[added: These credential types also differ in where they apply during authentication:]

[added: Windows Hello for Business and macOS Platform SSO: First-factor only. In the Microsoft managed state, their platform experiences can be offered before the password on a compatible operating system. Completing sign-in requires the credential on the current device.]