A SAS URL was sent to the wrong person, a partner contract ended early, or a link turned up in a ticket. You want to stop it working now. Revoking a SAS token in Azure Blob Storage is possible, but how you do it depends on how the token was created, and some methods also cut access for everyone else.
Short answer: You cannot revoke one SAS token by itself, because Azure Storage does not track issued tokens. You revoke what it depends on: delete its stored access policy (service SAS), revoke user delegation keys (user delegation SAS), or regenerate the account key that signed it (service or account SAS without a policy). Only the stored access policy method is targeted; the other two also break every other SAS signed the same way.
First, identify the SAS type
Open the SAS URL and look at its query parameters. The SAS overview describes three types:
| What you see in the URL | SAS type | Signed with |
|---|---|---|
si=<policy-name> |
Service SAS with a stored access policy | Account key |
skoid=, sktid=, ske= |
User delegation SAS | Microsoft Entra credentials |
ss= and srt= |
Account SAS | Account key |
sr=c or sr=b, no si, no skoid |
Ad hoc service SAS | Account key |
The sig value tells you nothing useful. The type decides your revocation options.
Revoke a SAS token, method by method
Service SAS with a stored access policy: delete or edit the policy
This is the only targeted revocation. A stored access policy is defined on a container, and every SAS that references it (si=) inherits its start time, expiry and permissions.
- In the Azure portal, open the storage account, then the container.
- Select Settings > Access policy.
- Delete the policy, or set its expiry time in the past.
- Save. The change can take up to 30 seconds to apply.
Other SAS tokens on the container keep working if they use a different policy. The limit is five stored access policies per container, so plan one policy per partner or per use, not per file.
User delegation SAS: revoke the keys or the role
A user delegation SAS is signed with a key obtained through Microsoft Entra ID. The user delegation SAS reference gives two options:
- Revoke user delegation keys on the storage account (Azure CLI:
az storage account revoke-delegation-keys). Every user delegation SAS of the account stops working, not just the leaked one. - Remove the role assignment of the identity that generated the SAS. The SAS can never do more than that identity is allowed to do. Role assignment changes can take up to 10 minutes to apply.
The user delegation key is valid for at most seven days, so a user delegation SAS also stops working when its key expires, whatever its own expiry says.
Account SAS or ad hoc service SAS: regenerate the key
These tokens are signed with one of the two storage account keys. The only way to revoke them before expiry is to regenerate that key:
- Find out which key (key1 or key2) was used to sign the SAS. If you do not know, plan to rotate both.
- Move applications that use the connection string to the other key.
- In Security + networking > Access keys, select Regenerate on the key.
- Recreate the SAS tokens that legitimate users still need.
Every SAS signed with that key stops working, and every application, script or tool that stores the key loses access until it is updated.
What does not revoke a SAS
| Action | Revokes the SAS? |
|---|---|
| Deleting the email or chat message that contained the link | No |
| Changing the container's public access level | No |
| Rotating the key that did not sign the SAS | No |
| Rotating account keys, for a user delegation SAS | No |
| Deleting the blob or container | The data is gone, but a recreated blob with the same name is reachable again |
| Adding a storage firewall rule | Blocks requests from outside the allowed networks, for all callers, not only this SAS |
Disabling Allow storage account key access on the account blocks all SAS signed with an account key at once. It is a strong emergency switch, but check first which applications still rely on the key; see prevent Shared Key authorization.
Prevent the next emergency
Based on Microsoft's SAS best practices:
- Prefer user delegation SAS. No account key is involved, and access is tied to an Entra identity.
- Short expiry times. A token that lives one day limits the damage if it leaks.
- Least privilege. Read only, on one container or one blob, when that is enough.
- One stored access policy per partner for service SAS that must live longer.
- A SAS expiration policy on the storage account, so that long-lived tokens raise a warning.
- A revocation plan written down before you need it: which key, which policy, who can act.
Also keep in mind that Azure Storage cannot audit SAS generation: anyone with the right role or the key can create tokens without the account owner knowing.
When SAS tokens are the right tool
SAS tokens are a good fit for applications: a backend that hands a short-lived upload URL to a browser, a copy job between two accounts, or a pipeline that runs for an hour. In these cases the token is generated by code, lives minutes or hours, and nobody needs to revoke it by hand.
They are a poor fit for giving people ongoing access. A link can be forwarded, it does not say who used it, and stopping it means one of the methods above.
A simpler option for people: named access that you can stop
Blob Web Explorer, a web file explorer for Azure Blob Storage, gives partners and colleagues access to a container through their own sign-in instead of a shared link:
- Share by email with Read or Write access and an end date; access stops automatically at the end date.
- Revoke one person without touching keys, policies or other users.
- No SAS URL or key to send: the container connection is configured once by its owner.
- Activity log per user: who uploaded, downloaded or deleted what, and when.
- Works on your existing containers. See how access is protected on the security page.
If you are moving away from links for partner exchanges, our guide on sharing an Azure Blob container with an external partner compares the options.
Bottom line
To revoke a SAS token in Azure Blob Storage, act on what signed it: the stored access policy, the user delegation key or role, or the account key. Only the stored access policy is a targeted switch; the other methods cut every token of the same kind. For partners and business users, named access with an end date avoids the problem altogether.
Start free with Blob Web Explorer and share your first container without a SAS URL.
Frequently asked questions
Can I revoke a single SAS token in Azure Blob Storage?
Not directly. Azure Storage does not keep a list of the SAS tokens you issue. You can only revoke what the token depends on, such as the stored access policy, the user delegation key or the account key that signed it. Only a service SAS bound to its own stored access policy can be revoked on its own.
Does rotating the storage account key revoke SAS tokens?
Yes, for service SAS and account SAS signed with that key. Regenerating the key invalidates every SAS signed with it, so legitimate applications and partners using those tokens lose access too. User delegation SAS tokens are not affected by key rotation.
How do I revoke a user delegation SAS?
Call the Revoke User Delegation Keys operation on the storage account, or remove the role assignment of the identity that created the SAS. Revoking the keys invalidates all user delegation SAS tokens of the account. Both are cached, so the effect is not instant.
How long does it take for a revoked SAS to stop working?
Changes to a stored access policy can take up to 30 seconds to apply. Revoking user delegation keys or role assignments is also subject to caching, and role assignment changes can take up to 10 minutes. Key regeneration takes effect when the key changes.
How can I see who used a SAS token?
Azure Storage does not identify the person behind a SAS. Enable Azure Storage resource logs to see requests and the authorization type used. To know which person did what, give people named accounts instead of shared links.