We've been investigating device-code phishing attacks where an attacker authenticates through a device-code flow, obtains OAuth tokens, and then registers or joins a rogue device to Entra. The concern is that the device may obtain a Primary Refresh Token (PRT), which can provide persistent SSO access to Microsoft services and make the compromise survive a normal password reset or the user's "Revoke sessions" action.
Does revoking a user's sessions invalidate a PRT issued to an already-joined device, or can that device continue using the PRT while it remains enabled? If revocation is insufficient, what actions are needed to fully cut off the session?
3 Answers
Revoking a user’s sessions should not be treated as the same thing as disabling a device. A PRT is tied to both the user and the device, and session revocation primarily invalidates refresh-token sessions. It may not immediately remove an already-issued PRT from a still-enabled device. For a suspected rogue device, disable or delete the device object so Entra can reject its PRT, then revoke the user’s sessions and reset the password and authentication methods as appropriate.
Treat this as an account-and-device compromise rather than only a stolen-token event. Disable the unauthorized device in Entra, revoke sessions, reset the password, review and re-register MFA methods if necessary, and investigate sign-in, audit, device-registration, application-consent, and mailbox activity. Also check for additional devices or persistence that the attacker may have created.
Conditional Access can reduce the risk, but it is not a substitute for incident response. Restrict who can join or register devices, require approved or compliant devices where practical, and require phishing-resistant authentication for sensitive access. Device-code authentication and device registration should be monitored carefully because a successful flow can create a trusted-looking foothold.
That distinction is what I was worried about. In this scenario I would not leave the suspicious device enabled just because the user’s sessions had been revoked.