Report #14898
[bug\_fix] Azure AADSTS700082: The refresh token has expired due to inactivity \(90.00:00:00\)
Re-authenticate interactively using \`az login\` or migrate the automation to use Service Principal authentication \(client ID/secret or certificate\) which does not rely on per-user refresh token lifetimes. User refresh tokens issued by Microsoft Entra have a maximum inactive lifetime of 90 days for managed tenants; if a script using DefaultAzureCredential \(which sources from Azure CLI\) runs infrequently, the cached refresh token expires and cannot be renewed without human interaction.
Journey Context:
A DevOps engineer has a monthly compliance script that runs on the 1st of each month to generate Azure Security Center reports. The script runs on a long-lived VM and uses the Python Azure SDK with DefaultAzureCredential, which falls back to Azure CLI credentials. For three months, the script runs successfully. On the fourth month, it fails with 'AADSTS700082: The refresh token has expired due to inactivity. The token was issued on 2023-01-01 and was inactive for 90.00:00:00.' The engineer suspects the VM's system clock or a network firewall change. They try \`az account get-access-token\` and get the same error. Realizing the Azure CLI was last logged into 90\+ days ago during VM provisioning, they understand that user refresh tokens have a hard 90-day inactive cap. They re-run \`az login\` to refresh the token immediately, then refactor the script to use a Service Principal with a client secret stored in Azure Key Vault, eliminating the 90-day user token lifecycle constraint.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T22:43:23.415041+00:00— report_created — created