Authentication method capabilities
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit 1954c05 · +36 −65 lines · also on GitHub
⋯ 4 unchanged lines
55
ms.service: entra-id
66
ms.subservice: authentication
77
ms.topic: overview
8
−ms.date: 10/30/2025
8
+ms.date: 11/10/2025
99
1010
ms.author: justinha
1111
author: justinha
⋯ 6 unchanged lines
1818
1919
Authentication is the process of verifying a person's identity before granting access to a resource, application, service, device, or network. It's how a system makes sure **users are who they say they are** when they try to sign in.
2020
21
−Microsoft Entra ID supports different [authentication methods](concept-authentication-methods.md), including options for [multifactor authentication (MFA)](tutorial-enable-azure-mfa.md) and enhanced security policies that enable customers to meet their business requirements for usability and security posture.
22
−
23
−While traditional MFA with SMS, email, OTP, or authenticator apps significantly improve security over password-only systems, these options introduce friction—requiring more steps for users, like entering codes, approving push notifications, or using authenticator apps, and remain vulnerable to remote phishing attacks. Despite these obstacles, MFA remains a critical security control, but its user experience and administrative overhead can hinder adoption and effectiveness.
24
−
25
−This article describes best practices for achieving convenient and usable authentication and recovery experiences while improving your organization's security posture.
26
−
27
−## Passkeys (FIDO2)
28
−
29
−Passkeys (FIDO2) are modern user credentials based on FIDO standards that are both easy to use and more secure than traditional MFA options. Passkeys are built on origin-bound public cryptography thus preventing a user from inadvertently presenting their authentication credentials to a malicious actor or being intercepted by an attacker.
30
−
31
−There are two types of passkeys – device-bound and synced passkeys.
32
−
33
−- **Device-bound passkeys** are those where the private key never leaves the device. Microsoft Entra ID already supports device-bound passkeys like FIDO2 security keys and passkeys in Microsoft Authenticator.
34
−- **Synced passkeys** sync through the provider's cloud (such as Apple iCloud Keychain, Google Password Manager). They can be used from multiple devices that belong to the same trust group and are signed in to the same sync service. Microsoft Entra ID supports synced passkeys (preview), and admins can select groups that can sign in with device-bound and synced passkeys.
35
−
36
−Synced passkeys offer a seamless and convenient user experience where users can use device's native device unlock mechanism like face, fingerprint, or PIN to authenticate. The following observations are based on the learnings from hundreds of millions of consumer users of Microsoft accounts that have registered and are using synced passkeys:
37
−
38
−- 99% of users successfully register synced passkeys
39
−- Synced passkeys are 14 times faster compared to password and a traditional MFA combination: 3 seconds instead of 69 seconds
40
−- Users are 3 times more successful at signing-in with passkey than legacy authentication methods (95% versus 30%)
41
−
42
−Synced passkeys in Microsoft Entra ID bring MFA simplicity at scale for all enterprise users. They're a convenient and low-cost alternative to traditional MFA options like SMS and authenticator apps. Learn [how to deploy passkeys](how-to-authentication-passkey-profiles.md) in your organization.
43
−
44
−It's recommended to use FIDO2 security keys in highly regulated industries or for users with high privilege. Note that however, these can incur higher equipment, training, and helpdesk costs due to lost productivity when users need to recover access to their account when they lose their physical key, and the cost of replacing lost physical keys is high. Passkeys in the Authenticator app are also an option for this user group.
45
−
46
−For most users in your organization, outside of the regulated industries or for privileged users with access to customer data, critical information, or computing systems, synced passkeys should be considered as convenient and low-cost alternatives to traditional MFA.
47
−
48
−In general, any type of passkey, whether device-bound or synced, is a huge upgrade over MFA options that are vulnerable to phishing.
49
−
50
−For more information, see [Get started with phishing-resistant MFA deployment in Microsoft Entra ID](how-to-plan-prerequisites-phishing-resistant-passwordless-authentication.md).
51
−
52
−Next, we review how passkeys can be used in different scenarios where users need to authenticate.
53
−
54
−## Authenticating while bootstrapping new devices
55
−
56
−This is the scenario where existing users are asked to perform some interactive authentication step on a device where the user has never authenticated before. For example, when users get a new physical device. Note that on a “new” physical device that doesn't yet have the user's account, the local lock screen (Face ID, Windows Hello for Business, etc.) inherently can't be used as a credential to bootstrap the device. In this scenario, our recommendation is to follow the same general recommendation for using FIDO2 security keys, Authenticator app passkey and synced passkey.
57
−
58
−## Lock screens for primary re-authentication
59
−After a user has bootstrapped a device with their account, there's some ongoing need to verify that the session is still controlled by the original user. Generally, the standard device-unlock gesture used to unlock a device is the primary form of interactive reauthentication used for that verification.
60
−
61
−For users who access high-risk applications, we more specifically recommend using full mobile device management (MDM) to:
21
+## Authentication methods supported by Microsoft Entra ID
6222
63
−- Enforce a lock screen
64
−- Enforce operating system updates
65
−- Integrate with Mobile Threat Defense (MTDs), including Mobile Defender for Endpoint, for antimalware
66
−- Apply app protection policies
23
+The following table outlines when an authentication method can be used for primary or first factor authentication, secondary factor authentication when you use Microsoft Entra multifactor authentication (MFA) and for self-service password reset (SSPR).
6724
68
−For users who access medium-risk applications, we recommend using mobile application management (MAM) where feasible, and rely on the aggressive efforts operating system vendors have to:
6925
70
−- Promote a lock screen
71
−- Promote OS updates
72
−- Help users avoid installing apps that might contain malware
26
+| Method | Primary authentication | Secondary authentication |
27
+|--------------------------------|:----------------------:|:-------------------------:|
28
+| [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-overview) | Yes | MFA<sup>1</sup> |
29
+| Platform Credential for macOS | Yes | MFA |
30
+| [Passkey (FIDO2)](concept-authentication-passkeys-fido2.md) | Yes | MFA |
31
+| [Passkey in Microsoft Authenticator](concept-authentication-authenticator-app.md)| Yes | MFA |
32
+| [Synced passkey (preview)](concept-authentication-passkeys-fido2.md)| Yes | MFA |
33
+| [Certificate-based authentication](concept-certificate-based-authentication.md)| Yes | MFA |
34
+| [Microsoft Authenticator passwordless](concept-authentication-authenticator-app.md#passwordless-sign-in-via-notifications)| Yes | No |
35
+| [Microsoft Authenticator push notifications](concept-authentication-authenticator-app.md#mfa-via-notifications-through-mobile-app) |Yes | MFA and SSPR |
36
+| [Authenticator Lite](/entra/identity/authentication/how-to-mfa-authenticator-lite) | No | MFA |
37
+| [Hardware OATH tokens (preview)](concept-authentication-oath-tokens.md#hardware-oath-tokens-preview) | No | MFA and SSPR |
38
+| [Software OATH tokens](concept-authentication-oath-tokens.md#software-oath-tokens) | No | MFA and SSPR |
39
+| [External authentication methods (preview)](/entra/identity/authentication/how-to-authentication-external-method-manage)| No | MFA |
40
+| [Temporary Access Pass (TAP)](howto-authentication-temporary-access-pass.md) | Yes | MFA |
41
+| [Short Message Service (SMS) sign-in](howto-authentication-sms-signin.md) | Yes | MFA and SSPR |
42
+| [Voice call](concept-authentication-phone-options.md) | No | MFA and SSPR |
43
+| [QR code](concept-authentication-qr-code.md) | Yes | No |
44
+| Password | Yes | No |
7345
74
−For users who access low-risk applications, we recommend relying on the aggressive efforts operating system vendors have. Also rely on the efforts by browser vendors to promote incognito browsing.
46
+<sup>1</sup>Windows Hello for Business can serve as a step-up MFA credential if a user is enabled for passkey (FIDO2) and has a passkey registered.
7547
76
−## Single sign-on (SSO) after device bootstrap
48
+## Phishing-resistant authentication methods
7749
78
−For accounts and devices that follow the preceding guidance, once a user has bootstrapped their account, we don't recommend any interactive reauthentication when users try to access applications beyond the standard user gesture to unlock the device. Traditional SSO technology should be used instead (such as SAML, OpenID, and so on). This includes applications on remote virtual devices if SSO can be used to bootstrap a session for the same user account on that device. The Microsoft Entra ID default configuration comes down to "don't ask users to provide their credentials if the security posture of their sessions didn't change."
50
+While traditional MFA with SMS, email OTP or authenticator apps significantly improves security over password-only systems, these options introduce friction—requiring additional steps for users, like entering codes, approving push notifications, or using authenticator apps. Moreover, these options for MFA are prone to remote phishing attacks. Remote phishing is where attackers use social engineering and AI-driven tools to steal identity credentials—like passwords or one-time codes—without physical access to a user's device.
7951
80
−## Secondary reauthentication
52
+Microsoft recommends using phishing-resistant authentication methods such as Windows Hello for Business, passkeys (FIDO2) and FIDO2 security keys, or certificate-based authentication (CBA) because they provide the most secure sign-in experience.
8153
82
−There's a limited set of scenarios where the standard device unlock gesture isn't the recommended approach for interactive re-authentication, and the user faces more UX friction with re-authentication. For accounts and devices that follow the preceding guidance, the recommended guidance for each scenario is:
54
+The following phishing-resistant authentication methods are availble in Microsoft Entra ID.
8355
84
−- **Step-up authentication**: Admins/power users might use a synced passkey, as described earlier, to bootstrap a new device if they initially access only low-risk or medium-risk applications. If they later want to access high-risk applications, they need to perform an interactive reauthentication flow with one of the other credential types suggested earlier.
85
−- **Compromised account**: If an admin believes a user's account is compromised, then any sessions that belong to the account should be invalidated, and potentially compromised credentials should be removed from the account. The user then need to re-authenticate with a credential of a type listed earlier that is still valid, or was issued to the correct user as a new credential.
86
−- **Adding new credentials**: If a user tries to add a new credential that can be used to bootstrap other devices, then Microsoft Entra ID risk engine may ask them to perform another interactive reauthentication step.
87
−- **Extended inactivity**: If a session is completely unused for an extended period, then the user needs to re-authenticate with a credential listed above. However, this would primarily be to prevent against local attacks by (1) someone who knew the user's lock screen PIN, and (2) had access to a device the good user hadn't used for an extended period of time, and (3) didn't have access to a device the good user more frequently used, which wouldn't have this other check. Given that low likelihood, this extended period defaults to 90 days in Microsoft Entra ID.
88
−- **Transaction approval for specific high-risk actions**: If an admin/power-user is performing a high-risk action (such as large monetary transfer, or major software update to critical systems), then another interactive re-authentication may be used via authentication context as an added layer of protection against local malware. In such situations, we suggest forcibly invoking the lock screen as the lowest friction form of re-authentication. Note that malware could still trick users into performing reauthentication step no matter what credential type is used. In such cases we recommend also requiring a second employee, and on a different device, to review and approve the high-risk action.
89
−- **Policy exception**: The section on lock screens gives guidance for high/medium/low risk application types. If your organization wants to give access to high-risk applications without MDM to some users, then the time period of access could be limited to a few hours (or at most days) using the Conditional Access sign-frequency feature that enforces interactive reauthentication to happen again after that time period. However, we still advise avoiding that configuration for high-risk applications and instead rely on MDM. One way to do that is to allow employees to use a physical device for low-medium risk applications that don't have MDM and then require them to SSO into a virtual device that does have MDM to access high-risk applications.
90
−- **Other regulatory requirements**: Your organization may have regulatory requirements beyond the list above where SSO can't be used, even after the user has performed the standard device unlock step. Most such regulatory requirements take a while to be updated based on latest industry techniques such as the recommendations above. Until the requirements are updated, you can work with your compliance review process to accept the risk of instead following the guidance listed here. However, if you can't do that, you can use the features of Microsoft Entra ID Conditional Access to enforce another interactive re-authentication. In such situations, we suggest forcibly invoking the lock screen as the lowest friction form of reauthentication if that is an option in the regulations. If the regulation applies to an application that the employee is accessing on a virtual desktop, then Microsoft Entra ID has support for forcibly invoking the lock screen on the user's local device. If the regulatory requirement can't be met by forcibly invoking the lock screen, then you likely need to require interactive reauthentication using one of the credentials listed earlier.
56
+- Windows Hello for Business
57
+- Platform Credential for macOS
58
+- Synced passkeys (FIDO2) (preview)
59
+- FIDO2 security keys
60
+- Passkeys in Microsoft Authenticator
61
+- Certificate-based authentication (CBA)
9162
9263
## High assurance account recovery
9364
94
−Account recovery is a critical component of your organization's security posture. The recovery process should be as strong as user authentication to prevent unauthorized access and preserve trust. For users protected by phishing-resistant authentication, such as passkeys (FIDO2) or certificate-based authentication, account recovery should be as robust as the initial onboarding process. This means you should perform strong identity verification and validation of account ownership as part of the recovery process.
65
+Account recovery is the process where users have lost all their credentials and can't access their account anymore. The traditional way to help users recover their credentials includes the user calling helpdesk, where they answer some questions to verify their identity, which allows helpdesk to reset their credentials. Microsoft Entra ID now supports government-issued ID and biometric verification, which offers AI powered biometric match against government issued IDs for high-assurance account recovery.
9566
96
−In Microsoft Entra ID, we offer an integrated and seamless process for identity verification. Organizations can configure trusted partners to verify a user's identity, typically by presenting government-issued identification. After other validation steps, users can securely replace lost credentials, such as by registering a new passkey, to maintain account security throughout the recovery process.
67
+Organizations can choose amongst the leading identity verification providers (IDV) via [Microsoft Security Store](https://securitystore.microsoft.com/): Idemia, Lexis Nexis, and Au10tix. These partners offer coverage across 192 regions and countries and remote verification for most government issued identity (Gov ID) documents, including driver's licenses and passports. Entra Verified ID Face Check, powered by Azure AI services, adds a critical layer of trust by matching a user’s real-time selfie and the photo from their identity document. By sharing only the match results and not any sensitive identity data, Face Check improves user privacy while allowing enterprises to be sure the person claiming an identity is really them.
9768
98
−For users who rely on passwords and don't have access to phishing-resistant methods, [self-service password reset (SSPR)](concept-sspr-deploy.md) remains available. To enhance security for these users, especially users with multifactor authentication (MFA) capability, we recommend requiring at least two distinct authentication methods to complete password reset. This layered approach reduces the risk of account compromise during recovery.
69
+Once enabled, this capability enables a natively integrated end-to-end flow for users to easily and securely regain access to their accounts. For more information, see [Overview of Microsoft Entra ID Account Recovery](concept-account-recovery-overview.md).
9970
10071
## Related content
10172
⋯ 2 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/entra-docs, © Microsoft Corporation, under MIT. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 02:15 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.