Hi Naga,
Not necessarily. The access token working only proves that the current token is still valid or that ServiceNow can obtain a new access token with the refresh token it already has. It does not prove that Azure will issue a new refresh token every time.
For Azure / Entra ID, I would check this from two sides:
- Does the token endpoint response actually include a new refresh_token during refresh?
- If it does, is ServiceNow replacing the stored managed token value with the new one?
- If it does not, then this is controlled by the Microsoft identity platform / tenant policy / consent flow, not by the ServiceNow access token logic.
Things I would ask the Azure team to verify:
- The original authorization included offline_access and admin/user consent was actually granted.
- The app registration platform type is correct for this integration, preferably Web/confidential client rather than SPA-style behavior.
- Conditional Access or sign-in frequency policies are not forcing refresh token expiry/re-authentication.
- The refresh token has not been revoked by password reset, consent revocation, app change, user risk policy, or mailbox/account policy.
- Entra sign-in logs for the token refresh attempt show success/failure details.
On the ServiceNow side, check the OAuth token/managed token record timestamps and expiry values. If the refresh token is already expired or revoked, ServiceNow cannot magically renew it; the integration has to be re-authorized. If you cannot delete the PROD token safely, the safer path is to reproduce this in a lower environment or create a parallel test OAuth profile/app registration/mailbox and validate the authorization flow there first.
So your assumption is correct: a totally wrong app configuration would often break access token generation too. But refresh-token rotation/renewal can still fail independently because it depends on offline_access consent, refresh-token lifetime/revocation policy, and whether Azure returns a replacement refresh token during the refresh flow.
