An Azure Storage shared access signature (SAS) is a bearer credential inside a URL: anyone who holds the link gets its permissions until it expires, and Azure keeps no record that it was ever created. SAS tokens are generated client-side, signed with either a storage account key or a Microsoft Entra user delegation key, and pasted into scripts, pipelines, partner emails and public repositories. This guide explains the three SAS types, who can mint them, how to cap their lifetime with SAS expiration policies, how to revoke them, how to detect their use in Azure Monitor logs, and how to move to user delegation SAS or no SAS at all. It is for cloud platform, storage and security teams responsible for Azure Blob Storage, Data Lake Storage, Azure Files, Queue and Table Storage.
Key takeaways
- Prefer user delegation SAS. Microsoft recommends it whenever a SAS is needed: it is signed with an Entra-issued key, lasts at most seven days, and its creator's role assignments are checked on every request.
- Account and service SAS inherit the account key. They are signed with Shared Key, cannot be listed or audited at creation, and an account SAS can only be revoked by rotating the key that signed it.
- Set a SAS expiration policy and move it to Block. The policy caps the validity interval; the default Log action only records violations in the SasExpiryStatus log field.
- Remove the key, not just the tokens. Setting AllowSharedKeyAccess to false makes every service and account SAS stop working, which is the only control that prevents new key-signed SAS outright.
- Usage is visible, issuance is not. StorageBlobLogs records AuthenticationType "SAS" and a SHA-256 hash of the signature, so you can only find tokens that are used, and only on accounts with diagnostic logging enabled.
How identity and access work in Azure SAS tokens
A SAS token is a set of query parameters appended to a storage resource URI. The service rebuilds a string from those parameters, checks the HMAC-SHA256 signature in sig against the key that signed it, and authorises the request if it matches, otherwise returning 403. Microsoft's documentation is explicit that the SAS token "is not tracked by Azure Storage in any way" and that you can create an unlimited number of them. There is no API that lists how many exist.
| SAS type | Signed with | Scope | Maximum lifetime | Revocation |
|---|---|---|---|---|
| User delegation SAS | User delegation key obtained with Microsoft Entra credentials | One service: Blob (including Data Lake Storage), Queue, Table or Azure Files | Seven days (bounded by the delegation key) | Revoke user delegation keys, or remove the creator's role assignments |
| Service SAS | Storage account key (Shared Key) | Resources in one service | No platform limit unless a SAS expiration policy or stored access policy applies | Stored access policy (if used), otherwise rotate the account key |
| Account SAS | Storage account key (Shared Key) | One or more services, including service-level operations | No platform limit unless a SAS expiration policy applies | Rotate the account key only |
The parameters that matter for security
sp(permissions): letters such asrread,wwrite,ddelete,llist. A user delegation SAS grants only the intersection ofspand the creator's RBAC or POSIX ACL permissions.standse(start and expiry): the validity window. Microsoft advises a start time at least 15 minutes in the past, or none, to avoid clock skew failures.sipandspr: an allowed client IP address or range, and the protocol. Setspr=https; HTTP-only is not allowed, but the default permits both.skoid,sktid,skt,ske: on a user delegation SAS, the object ID and tenant of the principal that requested the key, and the key's own start and expiry.scid(correlation ID): optional on a Blob user delegation SAS from service version 2020-02-10; a GUID that links Azure Storage logs to the issuing service's own log of who received the token.sduoid(user-bound SAS): in service versions from 2025-07-05, a user delegation SAS can name the Entra object ID of the intended end user, who must then present a bearer token with a matchingoidclaim. Storage account properties can log or block user delegation SAS that are not user-bound. Check regional availability and SDK support before relying on it.
A SAS can be ad hoc, with constraints in the URI, or a service SAS tied to a stored access policy on a container, file share, queue or table. Stored access policies are not supported for account SAS or user delegation SAS. Each resource holds at most five, and creating or changing one can take up to 30 seconds to take effect.
Admin roles and privileged access
Microsoft warns that SAS generation cannot be audited: anyone with the account key, or a role that allows them to sign a SAS, can mint one without the account owner knowing. Controlling who can sign is therefore the main preventive control.
| Capability | Azure RBAC action | Built-in roles that include it (examples) | Risk |
|---|---|---|---|
| Read account keys (mint any service or account SAS) | Microsoft.Storage/storageAccounts/listkeys/action | Owner, Contributor, Storage Account Key Operator Service Role | Full data-plane control of the account, offline and untraceable |
| Regenerate account keys | Microsoft.Storage/storageAccounts/regeneratekey/action | Owner, Contributor, Storage Account Key Operator Service Role | Revokes all key-signed SAS; outage if applications use the key |
| Request a user delegation key | Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey | Storage Blob Data Contributor, Storage Blob Delegator | Bounded: the SAS cannot exceed the creator's own data permissions or seven days |
| Change SAS and key policies, AllowSharedKeyAccess | Microsoft.Storage/storageAccounts/write | Owner, Contributor, Storage Account Contributor | Can re-enable Shared Key or remove the expiration policy |
- Treat key readers as privileged: the generic Contributor role at subscription or resource group scope includes listkeys. Engineers who only need data access should hold Storage Blob Data roles, not Contributor. See the Azure RBAC and Service Principals Guide.
- Use just-in-time elevation: put Owner, Contributor and Storage Account Key Operator assignments on storage accounts behind Privileged Identity Management or an equivalent approval process.
- Separate delegation from data: a SAS-issuing service can hold a role scoped to one container, so every SAS it signs is limited to that container whatever
spsays.
Integrations, API tokens and service accounts
Most SAS tokens exist because an application, pipeline or partner needed storage access without an Entra identity. Choose the narrowest pattern that works.
| Scenario | Recommended pattern | Avoid |
|---|---|---|
| Azure-hosted workload reading or writing storage | Managed identity with a Storage Blob Data role; no SAS at all | Connection strings with account keys in app settings |
| Browser or mobile client uploading its own files | Back-end service issues a user delegation SAS for one blob, write only, minutes of validity, HTTPS only | Long-lived container SAS embedded in the client |
| Partner or customer download | User delegation SAS for the specific blobs, read only, from a dedicated sharing account | Account SAS on the production account |
| Recurring partner integration that cannot use Entra | Service SAS bound to a stored access policy, so it can be revoked without rotating keys | Ad hoc service SAS with a far-future expiry |
| Cross-account copy or blob-to-file copy | Short-lived user delegation or service SAS on the source, created for the job | Reusing a standing SAS across jobs |
| Azure File Sync | Leave the platform-managed SAS in place; keep the expiration upper limit at three days or more | Expiry limits below three days, which break sync |
Where account keys must still exist, Microsoft recommends storing them in Azure Key Vault and rotating them, using one key in all applications so the second can be rotated in. Rotating a key revokes every service and account SAS signed with it, which is both the emergency response and the reason rotation breaks undocumented integrations. See the Azure Managed Identities Security Guide and the Secrets Rotation Runbook Template.
Revocation options
- User delegation SAS: call Revoke User Delegation Keys (
az storage account revoke-delegation-keys). All user delegation SAS on the account become invalid; issuers then request new keys. Alternatively remove the creator's role assignment. Both are cached, so allow some minutes. - Service SAS with a stored access policy: delete the policy, rename its signed identifier, or set its expiry in the past with Set Container ACL (or the queue, table or share equivalent).
- Ad hoc service SAS or account SAS: regenerate the account key that signed it. Rotate key2 first if applications use key1, then key1, so you know which key you are cutting.
- Any SAS, as a stop-gap: set AllowSharedKeyAccess to false (stops all key-signed SAS), or restrict the account's network access while you rotate.
Logging and detection
Enable a diagnostic setting for each storage service (blob, file, queue, table) that sends resource logs to a Log Analytics workspace. Without it, SAS usage leaves no queryable record. SAS tokens never appear in logs; the AuthenticationHash field holds the SHA-256 hash of the decoded signature, so you can match a known token by hashing its sig value.
| Signal | Where and how | What it indicates |
|---|---|---|
| Requests authorised by key or SAS | StorageBlobLogs | where AuthenticationType in ("AccountKey", "SAS"), summarised by CallerIpAddress, UserAgentHeader, AccountName | Which clients still depend on Shared Key or SAS before you disable it |
| Out-of-policy SAS in use | SasExpiryStatus property in storage resource logs | A SAS with no start time or an interval above the policy limit |
| Writes through SAS | OperationName == "PutBlob" with AuthenticationType == "SAS", projecting AuthenticationHash and Uri | Uploads by token holders; unexpected volume suggests leaked write SAS |
| Unknown SAS from new locations | New AuthenticationHash values or new caller IPs on sensitive accounts | A token you did not issue, or one being reused outside its purpose (ATT&CK T1530 Data from Cloud Storage) |
| Key listing | Azure Activity Log operation listKeys on storage accounts | Someone obtained the ability to mint SAS offline |
| Policy changes | Activity Log writes changing sasPolicy, keyPolicy or allowSharedKeyAccess | Controls weakened |
Issuing services should log every SAS they create with recipient, resource, permissions, expiry, the scid correlation ID where supported, and the signature hash, because Azure cannot tell you who a SAS was given to. Relevant ATT&CK techniques: T1552.001 Credentials In Files (SAS URLs in code and configs), T1528 Steal Application Access Token and T1530 Data from Cloud Storage.
Metrics that show it is working
- Shared Key disabled: percentage of storage accounts with AllowSharedKeyAccess set to false.
- Policy coverage: percentage of accounts with a SAS expiration policy in Block mode, and the configured upper limit.
- Key-signed traffic: share of requests with AuthenticationType AccountKey or SAS, trending down month on month.
- Logging coverage: percentage of accounts with diagnostic settings for every enabled service.
- Leak response: SAS URLs found by secret scanning per month and median time from detection to revocation.
Hardening baseline
| Setting | Target value | Enforce with | Framework mapping |
|---|---|---|---|
| AllowSharedKeyAccess | false wherever no client needs keys | Azure Policy "Storage accounts should prevent shared key access" (Audit, then Deny) | NIST SP 800-53 IA-5, AC-3; CSF 2.0 PR.AA-01 |
| SAS expiration policy | Enabled, upper limit sized to real need (hours for most uses), action Block | "Storage accounts should have shared access signature (SAS) policies configured"; "Storage SAS tokens should adhere to 7 day maximum validity" | SP 800-53 IA-5, AC-6; CSF 2.0 PR.AA-05 |
| Key expiration policy | Set, with keys rotated within it | "Storage account keys should not be expired" | SP 800-53 IA-5, SC-12 |
| Anonymous and public network access | Anonymous blob access disallowed; public network access disabled where possible | "Storage account public access should be disallowed"; "Storage accounts should disable public network access" | SP 800-53 AC-3; CIS Control 3 |
| Diagnostic logging | Resource logs for all services to a central workspace, with alert rules | Azure Policy diagnostic settings assignments, or landing zone automation | SP 800-53 AU-2, AU-6; CSF 2.0 DE.CM-09; CIS Control 8 |
| Who can list keys | Only break-glass and key rotation identities, through just-in-time elevation | RBAC review, PIM | SP 800-53 AC-6; CIS Control 6 |
Rollout without breaking applications
- Inventory: list accounts and their
allowSharedKeyAccessvalue with Azure Resource Graph, and enable diagnostic logging on all of them. - Observe for two to four weeks: run the AccountKey and SAS query to identify every client, and the owners behind each caller IP and user agent.
- Set SAS expiration policies in Log mode and review SasExpiryStatus entries. If the portal greys the setting out, rotate both account keys once so
keyCreationTimeis populated. - Migrate clients: managed identities for Azure workloads, user delegation SAS for external sharing, stored access policies for the remainder.
- Enforce: switch expiration policies to Block, set AllowSharedKeyAccess to false account by account, and change the Azure Policy assignments from Audit to Deny.
- Roll back a single account by setting AllowSharedKeyAccess to true or the expiration action back to Log, and record the exception with an owner and end date.
Note that the Azure portal uses Shared Key by default to browse Azure Files, so assign data roles before disabling keys on accounts with file shares. Disabling Shared Key is also a prerequisite for protecting an account with Entra Conditional Access.
Common misconfigurations
- Full-control account SAS shared publicly. In the Microsoft SAS Token Exposure 2023, an account SAS with full control over a whole storage account sat in a public GitHub repository, its expiry extended to 2051, exposing 38TB including workstation backups and Teams messages. Scope, permissions and expiry all failed at once.
- Scanner findings dismissed. The same case was flagged by secret scanning and marked a false positive. SAS URLs are credentials; triage them as such. See the Git Secret Scanning Guide.
- Sharing from production accounts. A SAS for one file on an account that holds everything turns any scoping mistake into a full exposure. Use dedicated accounts for external sharing.
- Expiration policy left in Log mode. It warns creators and writes log entries, but out-of-policy tokens keep working.
- Using both keys across applications. When key1 and key2 are both in use, no key can be rotated without an outage, so leaked SAS are never revoked.
- Write permission without validation. Microsoft notes a write SAS lets the holder upload whatever they like and bill it to you; validate written data before use and keep write SAS short-lived.
Practitioner checklist
- Enable diagnostic logging on every storage account and baseline which clients use AccountKey or SAS authorisation.
- Remove listkeys rights from everyone who does not rotate keys; use Storage Blob Data roles for data access.
- Replace account and ad hoc service SAS with managed identities or user delegation SAS scoped to single resources.
- Configure a SAS expiration policy on every account, validate in Log mode, then switch to Block.
- Set AllowSharedKeyAccess to false wherever possible and enforce it with the built-in Azure Policy in Deny mode.
- Bind any remaining long-lived service SAS to stored access policies so they can be revoked without key rotation.
- Require issuing services to log recipient, scope, expiry, correlation ID and signature hash for every SAS.
- Scan repositories, wikis and tickets for SAS URLs and write a revocation runbook for each SAS type.
Standards and references
- Microsoft Learn: Grant limited access to Azure Storage resources using shared access signatures (SAS)
- Microsoft Learn: Create a user delegation SAS
- Microsoft Learn: Configure an expiration policy for shared access signatures
- Microsoft Learn: Prevent Shared Key authorization for an Azure Storage account
- Microsoft Learn: Define a stored access policy
- Microsoft Learn: Manage storage account access keys
- Microsoft Learn: Best practices for monitoring Azure Blob Storage
- MITRE ATT&CK: Data from Cloud Storage
Related NHI Mgmt Group resources: Microsoft Azure Security Guide · Azure Managed Identities Security Guide · OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide · Cloud Storage Exposure Playbook · Kubernetes Secrets Security Guide