Merge pull request #235393 from ramical/patch-23

Clarify revocation behavior on password changes

Author: prmerger-automator[bot]

articles/active-directory/devices/concept-primary-refresh-token.md

@@ -142,7 +142,7 @@ A PRT is invalidated in the following scenarios:
 
 * **Invalid user**: If a user is deleted or disabled in Azure AD, their PRT is invalidated and can't be used to obtain tokens for applications. If a deleted or disabled user already signed in to a device before, cached sign-in would log them in, until CloudAP is aware of their invalid state. Once CloudAP determines that the user is invalid, it blocks subsequent logons. An invalid user is automatically blocked from sign in to new devices that don’t have their credentials cached.
 * **Invalid device**: If a device is deleted or disabled in Azure AD, the PRT obtained on that device is invalidated and can't be used to obtain tokens for other applications. If a user is already signed in to an invalid device, they can continue to do so. But all tokens on the device are invalidated and the user doesn't have SSO to any resources from that device.
-* **Password change**: After a user changes their password, the PRT obtained with the previous password is invalidated by Azure AD. Password change results in the user getting a new PRT. This invalidation can happen in two different ways:
+* **Password change**: If a user obtained the PRT with their password, the PRT is invalidated by Azure AD when the user changes their password. Password change results in the user getting a new PRT. This invalidation can happen in two different ways:
    * If user signs in to Windows with their new password, CloudAP discards the old PRT and requests Azure AD to issue a new PRT with their new password. If user doesn't have an internet connection, the new password can't be validated, Windows may require the user to enter their old password.
    * If a user has logged in with their old password or changed their password after signing into Windows, the old PRT is used for any WAM-based token requests. In this scenario, the user is prompted to reauthenticate during the WAM token request and a new PRT is issued.
 * **TPM issues**: Sometimes, a device’s TPM can falter or fail, leading to inaccessibility of keys secured by the TPM. In this case, the device is incapable of getting a PRT or requesting tokens using an existing PRT as it can't prove possession of the cryptographic keys. As a result, any existing PRT is invalidated by Azure AD. When Windows 10 detects a failure, it initiates a recovery flow to re-register the device with new cryptographic keys. With Hybrid Azure Ad join, just like the initial registration, the recovery happens silently without user input. For Azure AD joined or Azure AD registered devices, the recovery needs to be performed by a user who has administrator privileges on the device. In this scenario, the recovery flow is initiated by a Windows prompt that guides the user to successfully recover the device.