When Removing Access Doesn't: Token Caching and the Revocation Window for Managed Identities

Imagine the moment an incident responder decides that a workload's identity must lose its access to a database, now. For a person, the playbook is familiar: disable the account, revoke sessions, and within a short, predictable time the access ends. For a managed identity in Microsoft Entra ID, the same instinct runs into a set of documented behaviours that most playbooks do not mention. The identity's tokens are cached by the platform for around a day per target. Permission changes can take hours to apply. There is no switch to force a fresh token. Even deleting the identity does not invalidate tokens already issued, and it leaves the identity's role assignments behind. None of this is a defect; each behaviour exists for reasons of reliability and scale. But together they mean that, for managed identities, removing access and access being gone are two different events separated by a window that can be measured in hours. This article maps that window precisely, using only what Microsoft and the relevant standards document, and turns the map into rules a platform team can adopt before the day they need them.

Background: how a managed identity's access is evaluated

A managed identity is a service principal of a special type in Microsoft Entra ID that Azure maintains on behalf of a resource. Code on the resource requests an access token from a local platform endpoint and presents it to a target service, such as a storage account or key vault. The token is a JSON Web Token, the signed claims format defined in IETF RFC 7519, and the flow is functionally the client-credentials grant of the OAuth 2.0 framework, RFC 6749: the workload acts for itself, with no user involved. Microsoft documents that the token response includes an expiry but that the refresh token field is not used by managed identities.

Self-contained tokens have a well-known property that matters here. A recipient validates a JWT by checking its signature, issuer, audience and expiry; it does not need to call the issuer to ask whether the token is still wanted. That is what makes such tokens fast and scalable, and it is also why revocation is hard. The OAuth working group addressed the problem with two separate standards: RFC 7009 defines a revocation endpoint through which a client can tell an authorization server that a token is no longer needed, and RFC 7662 defines introspection, through which a resource server can ask the authorization server whether a token is still active. Both require participation that a self-contained token, validated locally, does not provide by default.

Authorization for most Azure targets is evaluated against role assignments: records that grant a principal a role at a scope. What the token carries, and how the target combines the token with current role assignments, varies by service and is not something this article generalises about. What Microsoft does document, explicitly and for managed identities in particular, is the caching behaviour that sits between a permission change and its effect. That documented behaviour is the subject of this article.

NIST SP 800-207 describes zero trust access as decisions made per session on the basis of current policy, and NIST SP 800-53 expects account management to include timely removal of access when it is no longer required. Both assume that a decision to remove access can be enforced on a predictable schedule. The question is what that schedule is for a managed identity.

Problem statement: defining the revocation window

We define the revocation window of a managed identity, for a given target, as the interval between the moment an authorised person removes the identity's access to that target and the last moment at which the identity can still successfully use that access. The definition is our own; its purpose is to make a familiar but vague worry precise enough to plan for.

Four removal actions are in scope, because they are the ones teams actually take: removing a role assignment from the identity, removing the identity from a group through which it held access, deleting a user-assigned identity, and deleting the resource that owns a system-assigned identity. For each, we ask which documented behaviours stand between the action and the end of access, and what can shorten the window without depending on the behaviour that causes it.

Two things are out of scope. We do not attempt to measure the window empirically in any tenant, and we do not generalise about how individual Azure services evaluate tokens against role assignments. Both would be valuable, and both would require testing that this article does not perform. The model is built only from documented statements, which is enough to show that the window exists, that it can be long, and that it cannot be closed from the identity side on demand.

Method: the documented behaviours that hold the window open

We assemble five documented behaviours. Each is stated as Microsoft documents it; the interpretation that links them into one window is our synthesis.

First, caching. Microsoft's managed identity documentation states that the back-end services for managed identities maintain a cache per resource URI for around 24 hours. A resource URI here means the target a token is requested for, such as a particular storage service. The practical consequence is that a token, once obtained for a target, may be served from cache for a long time after the identity's permissions change.

Second, propagation. The same documentation states that it can take several hours for changes to a managed identity's permissions to take effect, and the best-practice guidance repeats the point for changes to an identity's group or role membership. It contrasts this with a person, who can acquire a new token by signing out and back in, or by waiting for the default token lifetime of one hour.

Third, no forced refresh. Microsoft states that it is not possible to force a managed identity's token to be refreshed before its expiry. There is no documented operation, for the operator or the code, that discards the cached token and obtains one reflecting current permissions.

Fourth, deletion does not invalidate. Microsoft documents that tokens issued before a managed identity was deleted remain valid until their original expiry. Deleted managed identities are soft-deleted for 30 days, visible but neither restorable nor permanently deletable, and a deleted system-assigned identity continues to count towards the directory quota until it is purged.

Fifth, role assignments outlive the identity. Microsoft's guidance notes that role assignments are not removed automatically when either kind of managed identity is deleted. Those assignments then refer to a principal that no longer exists. They no longer grant anything to the deleted identity, but they remain in place as clutter that obscures reviews, and they are a reminder that deletion is not cleanup.

Microsoft draws a design recommendation directly from the second and third behaviours: group Azure resources using a user-assigned managed identity with permissions applied directly to it, instead of adding identities to or removing them from Microsoft Entra groups. The recommendation is a tacit acknowledgement that group-based changes are where the window is hardest to predict.

Where the stale state lives: a layered view

It helps to see the window not as one delay but as stale state held in several layers, each with its own owner and its own way of being bypassed. This layered view is our synthesis of the behaviours above.

The outermost layer is the decision: the role assignment or group membership that an administrator changes. That change is recorded immediately; this layer is never the problem. The next layer is propagation, where the change becomes visible to the systems that issue and evaluate tokens; Microsoft documents that this can take several hours for managed identities. Beneath that is the token cache, maintained per resource URI for around 24 hours, which can continue to supply a token minted before the change. Beneath that again is the issued token itself, which, being self-contained, remains valid until its expiry wherever it is presented, and which survives even deletion of the identity that received it.

The innermost layer is the one the identity layer cannot touch at all: the running code on the resource that requests and uses the token. If that code keeps running, it keeps presenting whatever token the layers above give it. Conversely, if that code stops, no further requests are made, no matter what the layers above still hold.

This view explains why the familiar human playbook does not transfer. For a person, signing out clears the innermost layers and forces a fresh evaluation. For a managed identity, there is no sign-out, no forced refresh and no documented revocation call, so the only layers an operator can act on immediately are the outermost one, which changes the decision but not its effect, and the innermost one, which stops the code.

Evaluation: the four removal actions on one timeline

We now apply the model to each removal action, analytically. No timings are measured; the intervals named are the documented ones, and where the documentation gives no figure we say so.

Removing a role assignment directly from the identity. The decision is recorded at once. The documentation says permission changes can take several hours to take effect, and a token already cached for the target can continue to be served for up to around 24 hours. The window is therefore bounded above by the cache and token lifetime and below by nothing the operator controls.

Removing the identity from a group. The same behaviours apply, and Microsoft singles out group membership changes as the case to avoid for access management, recommending direct assignments instead. Teams that grant managed identities access through groups should assume the longest end of the window.

Deleting a user-assigned identity. New token requests for the identity will fail once the deletion is effective, but tokens issued before deletion remain valid until their original expiry, which the documentation does not state as a fixed constant. The identity's role assignments remain until removed. Deletion therefore stops new tokens but neither ends existing ones nor cleans up grants.

Deleting the resource that owns a system-assigned identity. Azure deletes the identity with the resource, and with the resource goes the running code, which is the innermost layer. This is the only one of the four actions that acts on the layer that actually uses tokens. Issued tokens remain valid until expiry wherever they may have been copied, and role assignments still remain, but the legitimate path to presenting new requests disappears with the compute.

Design rules that bound the window

If the identity layer cannot close the window on demand, the window has to be bounded by design, before it is needed. We derive four rules from the model; each is our synthesis, and each is grounded in a documented behaviour.

Rule one: get access right at grant time. Because removal is slow and cannot be forced, the cost of an over-broad grant is not just the grant itself but the hours it takes to undo. Scope role assignments to the specific resource the workload needs and the narrowest role that works, and treat any broad grant made for convenience as a debt that will be expensive to repay in an incident.

Rule two: prefer direct role assignments on user-assigned identities over group membership. This is Microsoft's own recommendation, and the model explains it: group changes are where propagation is slowest and least predictable. Grouping resources under one user-assigned identity with roles applied directly to it keeps changes at the layer that propagates most directly.

Rule three: plan containment that does not depend on the identity layer. When access must end now, act on the innermost layer: stop, scale to zero or deallocate the compute that runs the code, or remove the deployment, so that no further requests are made. Where the target service supports controls that do not depend on the caller's token, such as network-level restrictions, those can also act immediately on the target side. Which such controls exist varies by service and should be identified in advance for each critical target, not discovered during an incident.

Rule four: treat deletion as cleanup, not containment. Delete an identity after its access has been removed and its code has stopped, then remove its leftover role assignments, so that reviews reflect reality. Remember that soft-deleted system-assigned identities count towards the directory quota for 30 days, which matters for platforms that create and delete identities at high rates.

Why the window matters more for AI agents

AI agents, programs that use a large language model to plan and invoke tools, are increasingly given managed identities so that they can reach data and services without holding a secret. That is sound practice. It also means that the moment an agent misbehaves, whether through a prompt injection, crafted input that steers the model, or simply an unexpected chain of tool calls, is exactly the moment the revocation window becomes operationally important.

Three properties of agents make the window more consequential. Agents act quickly and repeatedly, so hours of residual access can mean many more actions than the same hours for a conventional batch job. Agents are often granted access iteratively, with permissions added as new tools are connected, which tends to produce broader grants than a carefully designed service would have. And agents are frequently changed and redeployed, which makes a plan to stop the code feel disruptive, and therefore tempting to skip in favour of removing a role and hoping.

The design rules translate directly. Grant each agent its own identity with narrow roles from the start, because trimming later is slow. Apply roles directly to that identity rather than through groups. And make stopping the agent a rehearsed, low-friction operation, so that containment in an incident means halting the agent's compute or deployment immediately while identity-side changes catch up. An agent's kill switch, in other words, belongs to its runtime, not to its identity.

Limitations and threats to validity

Every interval in this article comes from documentation, not measurement, and the documentation is deliberately approximate: around 24 hours, several hours. Actual behaviour may vary by target service, region and platform change over time, and Microsoft describes how managed identities authenticate as an internal implementation detail subject to change. The model should be read as describing what a team must be prepared for, not what it will observe in every case.

The documentation does not state a fixed lifetime for managed identity access tokens, so the end of the window after deletion is described only as the token's original expiry. We also do not generalise about how individual Azure services combine tokens with current role assignments at evaluation time; a service that re-evaluates authorization per request against fresh data may shorten the window for that service, and teams should verify the behaviour of their critical targets.

The containment rules mention target-side controls only generically, because their availability differs by service. Finally, this article does not address revocation for federated identity credentials or for secrets and certificates on applications, which follow different mechanisms.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

procedure contain(identity, incident):
    # 1. Immediate: act on the innermost layer
    for resource in attached_resources(identity):
        stop_or_scale_to_zero(resource)          # no new token requests or uses
    # 2. Immediate where available: act on the target
    for target in critical_targets(identity):
        if target.has_token_independent_control():
            apply_restriction(target)
    # 3. Durable: change the decision (expect hours to take effect)
    remove_role_assignments(identity)
    record(incident, 'identity-side removal issued; window may remain open for hours')
    # 4. Cleanup, after the window
    schedule_after(incident.window_end, delete_identity, identity)
    schedule_after(incident.window_end, remove_orphaned_assignments, identity)

STANDARD managed-identity-grants
  1. Grants are scoped to a specific resource; subscription-wide grants need written justification.
  2. Managed identities receive roles directly; group-based access for managed identities is not used.
  3. Every identity with access to a critical target has a documented stop procedure for its compute.
  4. Removal of access is followed by verification after the documented propagation and cache periods.
  5. Identities are deleted only after access removal and stop; leftover role assignments are removed the same day.

Glossary

Revocation window

This article's term for the interval between removing an identity's access and the last moment that access can still be used.

Resource URI

The identifier of the target service a managed identity token is requested for, used as the key of the platform's token cache.

Self-contained token

A token, such as a JWT, that a recipient validates locally from its signature and claims without contacting the issuer.

Token revocation

Telling an authorization server that a token should no longer be honoured, as standardised for OAuth in RFC 7009.

Token introspection

A resource server asking the authorization server whether a token is still active, as standardised in RFC 7662.

Role assignment

A record granting a principal a role at a particular scope, used to authorize access to Azure resources.

Soft delete

A retained, non-restorable state in which a deleted managed identity remains visible for 30 days.

Containment

Actions that stop harm immediately during an incident, as distinct from cleanup that restores a correct long-term state.

References

1. Microsoft Learn: Managed identities for Azure resources frequently asked questions
2. Microsoft Learn: Managed identity best practice recommendations
3. Microsoft Learn: How to use managed identities on an Azure VM to acquire an access token
4. IETF RFC 6749: The OAuth 2.0 Authorization Framework
5. IETF RFC 7519: JSON Web Token (JWT)
6. IETF RFC 7009: OAuth 2.0 Token Revocation
7. IETF RFC 7662: OAuth 2.0 Token Introspection
8. NIST SP 800-207: Zero Trust Architecture
9. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations