Azure Managed Identity randomly returns 403 and then self-recovers

I would not assume this is a permanent RBAC misconfiguration if it self-recovers without any deployment or role change, but you need logs from the exact failure window to separate transient identity/token issues from Key Vault authorization.

Things I would check:

1. Enable Key Vault diagnostic logs and look at the failed `SecretGet` or `KeyGet` events. Confirm the `caller`, `appid`/`oid`, `ResultSignature`, and whether `isRbacAuthorized` is false.

2. Check whether any role assignment, deny assignment, vault recovery, or access model change happened shortly before the outage. Azure RBAC changes can take minutes to propagate, and data-plane changes can be slower in some scopes.

3. Make sure the application uses the Azure SDK default retry policy and does not cache a failed token/secret result as a hard failure.

4. Log the managed identity token acquisition failures separately from Key Vault 403s. A token endpoint/IMDS retry problem and a Key Vault authorization problem look similar at the app layer but have different fixes.

If the log shows a stable caller object ID and no RBAC/deny changes, I would open a support case with the timestamp, vault URI, request IDs, and Key Vault audit entries.

Useful docs:

https://learn.microsoft.com/azure/key-vault/general/rbac-migration

https://learn.microsoft.com/azure/role-based-access-control/troubleshooting

Seems expected and usually falls under transient platform / control plane / token / throttling behaviors but not persistent misconfiguration.

Troubleshooting Azure Key Vault access policy issues | Microsoft Learn

microsoft-authentication-library-for-dotnet/docs/imds_retry_based_on_errors.md at main · AzureAD/microsoft-authentication-library-for-dotnet · GitHub