A stored access policy is a reusable access rule kept on a storage container, queue, table, or file share. Instead of putting every permission and expiry directly inside each service SAS token, you bind the SAS to a named policy. Then you can change or revoke the policy on the server side. It is useful when many clients need temporary access but operations still need emergency control. It is not the same as RBAC, and it does not make an over-broad SAS safe by magic.
stored access policy for SAS, SAS stored policy, storage access policy, service SAS policy
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-26
Microsoft Learn
A stored access policy is a server-side rule attached to a storage container, queue, table, or share that can control service SAS permissions, start time, and expiry. SAS tokens bound to the policy can be changed or revoked by updating the stored policy instead of every token.
In Azure architecture, stored access policies sit in the storage data-plane authorization model for service SAS. A policy defines permissions, start time, and expiry for a resource such as a blob container, queue, table, or share. SAS tokens can reference the policy identifier, letting operators adjust the policy after tokens have been issued. The concept interacts with account keys, user delegation SAS limitations, storage firewalls, private endpoints, client distribution, rotation processes, audit evidence, and service-specific limits on how many stored access policies can exist for a resource.
Why it matters
Stored access policy matters because SAS tokens are often copied into scripts, partner integrations, device configurations, and temporary workflows. When those tokens are created with all permissions embedded, revocation can be messy unless the account key is rotated, which may break unrelated clients. A stored access policy gives teams a narrower control point for service SAS tokens tied to the policy. That improves emergency response, planned permission changes, and evidence for auditors asking how temporary access is governed. It also forces teams to think about duration, least privilege, and policy ownership before handing data-plane access to a user, vendor, batch process, or device.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In a blob container, queue, table, or file share access policy screen, operators see policy identifiers, permissions, start times, and expiry settings before approval reviews.
Signal 02
In SAS creation workflows, the policy identifier shows whether a token is controlled by a stored policy or carries permissions directly inside the token for governance.
Signal 03
In incident records, a stored access policy often appears when teams revoke partner access without rotating the entire storage account key set during urgent cleanup.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Issue service SAS tokens for partners or devices while keeping a server-side way to shorten or revoke access.
Avoid account key rotation as the first response when policy-bound SAS access must be disabled quickly.
Separate temporary upload, read-only download, and maintenance access into different named policies with clear owners.
Audit old delegated access by listing stored policies and matching policy IDs to issued SAS workflows.
Reduce blast radius when a single external integration needs permission changes without disrupting unrelated clients.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Film festival controls sponsor uploads
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A film festival accepted promotional clips from dozens of sponsors before opening week. The first upload process used standalone SAS URLs, and operations had no quick way to revoke one sponsor without rotating broader storage keys.
🎯Business/Technical Objectives
Give each sponsor temporary upload access to one container.
Revoke access quickly if a sponsor finishes early or misuses the link.
Avoid disrupting other sponsors during permission changes.
Create an audit trail for delegated access approvals.
✅Solution Using Stored access policy
The media team created a blob container for sponsor uploads and issued service SAS tokens tied to sponsor-specific stored access policies. Each policy carried write and list permissions with a short opening-week expiry. The team documented policy identifiers in the sponsor approval tracker and used CLI to list policies before issuing links. When one sponsor accidentally shared an upload URL externally, operators updated that sponsor's stored access policy to expire immediately instead of rotating account keys. The container remained behind approved network controls, and completed clips were moved to a separate review container after ingestion.
📈Results & Business Impact
Revoked the leaked sponsor upload URL in under six minutes.
Kept 41 other sponsor upload links working during the incident.
Reduced delegated access review time from one day to two hours.
Prevented account key rotation from interrupting the clip review pipeline.
💡Key Takeaway for Glossary Readers
Stored access policies give teams a practical revocation handle for service SAS workflows that involve many external contributors.
Case study 02
Logistics broker limits carrier downloads
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A logistics broker shared daily route manifests with independent carriers through Blob Storage. Some carriers kept old SAS links active for months, leading to unexpected download traffic after contracts ended.
🎯Business/Technical Objectives
Limit carrier downloads to approved contract windows.
Separate access by carrier and manifest container.
Stop stale SAS links without affecting active carriers.
Reduce unexplained bandwidth and transaction charges.
✅Solution Using Stored access policy
Architects replaced ad hoc SAS links with service SAS tokens bound to carrier-specific stored access policies on the manifest container. Each policy used read-only permissions and expiry dates aligned to the carrier contract. Operations kept a register of policy IDs, carrier owners, and renewal dates. Azure CLI listed policies during monthly access reviews, and expired policies were deleted after final invoice reconciliation. When a contract ended early, the team shortened that carrier's policy expiry and watched storage logs for failed access attempts. Active carriers received new policy-bound SAS tokens only after business approval.
📈Results & Business Impact
Reduced stale carrier download traffic by 73 percent over two months.
Cut unexplained storage egress charges by 28 percent.
Disabled early-terminated carrier access without changing active carrier links.
Completed monthly access review in 40 minutes instead of half a day.
💡Key Takeaway for Glossary Readers
Stored access policies turn temporary partner download links into governable access records instead of forgotten URLs.
Case study 03
Education program cleans up device SAS access
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A national education program distributed tablets that uploaded offline lesson results to Azure Queue Storage. Devices used SAS tokens created before the operations team had a revocation process.
🎯Business/Technical Objectives
Group device upload access by school term.
Disable tokens for retired or lost devices quickly.
Avoid rotating account keys across thousands of tablets.
Keep uploads working for active classrooms with poor connectivity.
✅Solution Using Stored access policy
The platform team created queue-level stored access policies for each school term and issued policy-bound service SAS tokens to tablet provisioning packages. Permissions were limited to adding messages, with expiry aligned to the academic calendar. Lost-device incidents triggered a policy review rather than immediate account key rotation. For high-risk batches, operators issued a new policy to active devices during the next management window and expired the old policy. CLI checks listed queue policies and confirmed permissions before provisioning. Storage logs were sampled to verify that retired tokens stopped producing successful message writes.
📈Results & Business Impact
Cut lost-device revocation time from several days to under one hour.
Avoided account key rotation across 18,000 tablets during the school year.
Reduced unauthorized post-term upload attempts by 89 percent.
Kept lesson-result upload success above 97 percent for active classrooms.
💡Key Takeaway for Glossary Readers
Stored access policies are useful when distributed clients need limited SAS access but operations still needs a server-side kill switch.
Why use Azure CLI for this?
I use Azure CLI for stored access policy work because revocation and evidence must be precise. The portal can help for one container, but CLI lets me list policies, create a narrow test policy, update expiry, and prove what changed in a ticket. During an incident, I do not want to guess which access rule exists or whether a policy was deleted. CLI also supports scripted audits across containers, queues, tables, and shares. That matters when old SAS links keep appearing in partner systems and the team needs a controlled cleanup rather than blunt account key rotation. It keeps revocation deliberate.
CLI use cases
List stored access policies on a container before issuing or revoking service SAS tokens.
Create a short-lived policy for a partner upload window without sharing account keys.
Update a policy expiry during an incident to disable bound SAS access quickly.
Delete stale policies after confirming no active integration still references their identifiers.
Before you run CLI
Confirm the storage account, resource type, container or share name, and policy identifier.
Know whether the SAS is policy-bound or carries permissions directly inside the token.
Review active clients before changing permissions or expiry because one policy can affect many tokens.
Use least privilege and short expiry rather than broad policies that remain active indefinitely.
What output tells you
Policy listings show identifiers, permissions, start times, and expiry for delegated access control.
Update output confirms whether the server-side policy changed for future validation of bound SAS tokens.
Delete results indicate the policy no longer exists, which should revoke policy-bound SAS access.
Errors often reveal wrong resource type, missing account permissions, or confusion between SAS types.
Mapped Azure CLI commands
Stored access policy operations
secures
az storage container policy list --container-name <container-name> --account-name <storage-account> --auth-mode login
az storage table policy list --table-name <table-name> --account-name <storage-account> --auth-mode login
az storage table policydiscoverStorage
Architecture context
An Azure architect uses stored access policies when service SAS must be operationally revocable without treating account key rotation as the first response. The design starts with resource scope: container, queue, table, or share. The policy then represents a named access envelope that clients can reference through SAS. This works best when token issuance is centralized, policy names are documented, and emergency revocation is rehearsed. It does not replace Microsoft Entra authorization or managed identities for first-party applications. It is most valuable for constrained delegation scenarios where clients cannot use Entra ID but access still needs accountable server-side governance. Governance matters because policy-bound SAS becomes part of the application contract.
Security
Security impact is direct because the policy controls delegated data access. A stored access policy can reduce blast radius by allowing SAS permissions, start time, or expiry to be changed for tokens bound to that policy. It cannot rescue a token that was created with excessive scope, leaked publicly, or issued outside policy governance. Teams should avoid long-lived broad policies, document who can update them, and monitor SAS usage through storage logs where available. Account keys used to create service SAS remain highly sensitive. Security reviews should check least privilege, expiry, resource scope, emergency revocation, and whether managed identity would be safer.
Cost
The policy itself has no direct billing meter, but it influences cost through access patterns and operational risk. A broad SAS tied to a permissive policy can allow unexpected reads, writes, deletes, or bandwidth consumption. Long-lived policies keep integrations alive after projects end, causing storage, transaction, and egress charges to continue unnoticed. Emergency account key rotation can create expensive engineering work and downtime if many clients depend on shared keys. FinOps and operations should review policies with data owners, remove stale delegated access, and correlate heavy transaction spikes with the clients or workflows that received policy-bound SAS tokens. Removing stale policies is a small FinOps control with real payoff.
Reliability
Reliability impact is mostly operational. A stored access policy can keep integrations running during planned token changes because clients reference a stable policy identifier, but a careless policy update can break every bound SAS immediately. Expiry mistakes, time zone confusion, or permission removal can look like sudden application failure. Reliable designs separate policies by client or workflow, avoid sharing one policy across unrelated systems, and test changes with representative tokens before production updates. Runbooks should describe how to revoke access quickly and how to restore required permissions without rotating account keys or issuing uncontrolled replacement tokens. The rollback path should be written before the policy is tightened.
Performance
Performance impact is indirect because stored access policies do not accelerate storage operations. The practical performance value is operational speed: teams can revoke or adjust a group of service SAS tokens faster than hunting down every distributed token. Misconfigured policies can also create performance incidents when clients suddenly lose permissions and retry aggressively. For high-volume workflows, the policy should be stable, scoped, and tested before rollout so access failures do not amplify into retry storms. Performance monitoring should focus on request errors, throttling, retries, and bandwidth after policy changes, especially when external clients or devices use the affected SAS. Access failures are performance problems when clients respond with uncontrolled retries.
Operations
Operators use stored access policies to inspect delegated access, adjust permissions, shorten expiry, and revoke service SAS tokens tied to a resource. Practical work includes listing policies on containers, queues, tables, or shares; comparing policy IDs with issued SAS records; and documenting which external clients depend on each policy. Change management matters because one policy edit can affect many users. Operators should keep issuance logs, expiry calendars, ownership labels, and emergency procedures. During incidents, they verify whether a failing client uses a policy-bound SAS, whether the policy still exists, and whether account key rotation is actually required. Clean records prevent emergency changes from becoming guesswork.
Common mistakes
Creating long-lived broad policies and assuming the policy name alone makes access safe.
Issuing SAS tokens without recording which stored access policy each token references.
Editing one shared policy and unexpectedly breaking several unrelated partner integrations.
Trying to use stored access policies for user delegation SAS scenarios where they do not apply.