AADSTS70008 and AADSTS700082: the refresh token expired or was revoked

Fix it now

The long-lived grant an application used to obtain new access tokens is no longer accepted, so somebody has to sign in again. This is not evidence of compromise and not a fault to repair: grants age out when unused and are deliberately destroyed by a password change or a session revocation. What you control is how often it happens.

Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId user@contoso.com

1. For a single person, have them sign in interactively once. That is the whole fix, and no configuration change is needed.
2. If a group was hit at the same moment, look at Entra ID then Monitoring & health then Audit logs for a password reset, a session revocation or a policy change at that timestamp.
3. For an application or script, acquire a fresh authorisation interactively rather than retrying the dead grant. Retrying will fail every time.
4. For anything unattended, stop using a delegated grant and move to application-only authentication with a certificate, or a managed identity where the workload runs in Azure. Those do not expire this way.
5. If users say the prompts are too frequent, check the Conditional Access session controls before assuming a defect. Sign-in frequency and persistent browser session are what set the cadence.

Revoke-MgUserSignInSession invalidates all refresh tokens issued to applications for that user and the session cookies in their browser, by resetting the sign-in sessions valid-from timestamp. It is the right tool for a lost or stolen device and the wrong one for a routine prompt.

If the user signs in and the application gets a token, you are done. If the prompts keep arriving on a schedule, the next section explains what is setting it.

Why it happens

An access token is short-lived on purpose. To avoid asking for credentials every hour, the client also holds a refresh token and exchanges it for new access tokens in the background. That refresh token is tied to a specific user and a specific client application, and it keeps working as long as it is used regularly. Leave it unused past the inactivity window and it stops being accepted, which is what AADSTS700082 describes: an expected part of the token lifecycle, where the user went an extended period without using the application.

Several events destroy the grant immediately rather than letting it age. A password change or reset revokes it. An administrator revoking a user’s sessions revokes it. Disabling the account revokes it. AADSTS50173 is the code for that case, and it is helpfully specific: it names the date the grant was issued and the date before which tokens for this user are no longer valid, so you can line the failure up against the audit log entry that caused it. AADSTS70043 is different again, and means a Conditional Access sign-in frequency check judged the existing token too old to reuse.

Single-page applications are their own case. Because a token held in a browser is more exposed, refresh tokens issued to them carry a short fixed lifetime that cannot be extended, and AADSTS700084 is that limit being reached. There is no configuration that changes it, which makes it the one code on this page where the correct response is to stop looking for a setting. The application has to send a new sign-in request, and silent renewal against the session cookie is what makes that invisible to the user.

Full reference

Reading who was affected, and when

Moving unattended work off a human’s session

The single most common version of this problem is a script that authenticated once, interactively, years ago, and has been quietly refreshing ever since. It is fragile in three ways at once: it dies when the person leaves, it dies when their password changes, and it dies if it simply does not run for long enough. None of those is a defect to fix. They are the token lifecycle working as designed on a credential that was never meant to be unattended.

1. Register the job as its own application rather than borrowing a person’s identity.
2. Give it a certificate credential and use application-only authentication.
3. Grant it only the application permissions the job actually needs, and record why each was granted.
4. Where the workload runs in Azure, use a managed identity so there is no credential to rotate at all.
5. Retire the delegated grant once the new path is proven, rather than leaving both in place.

What the session controls actually govern

These are the levers that exist. If a prompt cadence is wrong, it is one of the first two. Nothing in this list makes a refresh token survive a password change, and nothing should.

When to treat it as an incident rather than a prompt

• The revocation was not expected and cannot be tied to an administrative action in the audit log.
• The failure timestamps cluster around a change to the account’s registered authentication methods.
• A group of users lost their sessions at once and nobody owns the change.
• The account’s recent sign-ins show locations or clients nobody recognises.
• In any of those cases, review the account before you have the user sign in again, because signing in again is exactly what an attacker with a foothold also wants.

Every code this article covers

Confirm the fix worked

1. The affected user completes an interactive sign-in and the application obtains a token without error.
2. The audit log entry behind a mass revocation is identified and understood rather than left unexplained.
3. Any unattended job now runs on application-only authentication or a managed identity, and has completed a full cycle without a human signing in.
4. Prompts that remain line up with a session control interval you set deliberately.
5. For a single-page application, silent renewal succeeds after the fixed lifetime is reached rather than showing the user a sign-in page.

Questions people ask about this