Azure AD service principal token persists after client credential expiry

When a service principal's client credential expires, previously issued access tokens remain valid until their own intrinsic expiry, typically 60–90 minutes, because Azure AD token validation does not re-check credential status after issuance. This means the token's granted roles and permissions are fixed for its lifetime and do not reflect subsequent role revocation or credential rotation.

Credential rotation, which adds a new secret or certificate before removing the old one, creates an overlap period where both the old and new credentials can obtain new tokens, potentially widening the attack surface if the original credential is compromised. However, there is no built-in mechanism to instantly revoke all tokens issued under an expired or rotated credential, nor to enforce least-privilege constraints after token issuance.

Conditional Access policies can enforce shorter session lifetimes or re-authentication for interactive user sign-ins, but they do not apply to non-interactive service principal client-credential flows, leaving a gap in automated token lifecycle management for workload identities.

What mechanisms, if any, can reliably invalidate tokens issued under expired service principal credentials without disrupting legitimate operations? How does role-based access control interact with tokens issued before credential rotation? Can organizational policies bridge the gap between token lifetime and credential expiry for service principals?