Authentication method capabilities

This page's changes and edits · All guidance changes

Microsoft's edit · 7 Nov 2025 22:47 UTC

Raise Acrolinx score to passing

Microsoft's commit message in MicrosoftDocs/entra-docs · commit dff44e4 · +8 −8 lines · also on GitHub

⋯ 74 unchanged lines

7575

7676 ## Single sign-on (SSO) after device bootstrap

7777

78 −For accounts and devices that follow the preceding guidance, once a user has bootstrapped their account, we don't recommend any interactive re-authentication 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."

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."

7979

80 −## Secondary re-authentication

80 +## Secondary reauthentication

8181

8282 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:

8383

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 re-authentication flow with one of the other credential types suggested earlier.

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.

8585 - **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 re-authentication 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 had not 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 re-authentication 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 do not 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 cannot 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 re-authentication 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 re-authentication using one of the credentials listed earlier.

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.

9191

9292 ## High assurance account recovery

9393

⋯ 10 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.