An outstation office issued several SAS tokens against the same container to a rotating cast of ground-handling contractors over the past month. Security now wants the ability to instantly invalidate every one of those already-issued tokens at once, without rotating the storage account keys that other production apps depend on. What should have been used when the tokens were created?

A stored access policy is defined on the container itself and referenced by ID when each SAS is generated, so the token's validity depends on that server-side policy rather than only on its own signed expiry. Deleting or modifying the policy immediately invalidates every SAS that points to it, which is exactly the bulk, instant revocation the scenario asks for. Regenerating the storage account keys would indeed invalidate SAS tokens signed with the old key, but it is a blunt instrument that also breaks every unrelated application, service, or SAS elsewhere in the account still relying on that key — collateral damage the scenario explicitly rules out. Asking contractors to delete a link relies on their cooperation and does nothing technically; the token itself remains valid on the server side regardless of who still has a copy of the URL. Issuing account SAS tokens with short expiries only limits future exposure per token — it does not help with the batch of tokens already handed out, since each one still runs its own timer until it naturally expires. One caveat: a stored access policy can also grant its own permissions and expiry, so a SAS built against it inherits those settings automatically. To confirm revocation worked, retry one of the previously issued SAS URLs and verify it now returns an authorization error.