Keep SAS issuance records outside Azure Storage's token inventory

Source facts

A shared access signature is generated on the client side. Azure Storage does not track the resulting token, and Microsoft says token generation itself cannot be audited through the service. A principal with the relevant signing authority can generate a token without the storage account owner’s knowledge.

Storage also does not track how many SAS tokens were generated, and no API supplies that count. Microsoft says organizations that need the number must maintain their own tracking. Microsoft Learn.

Applicability

Identify the approved issuing applications, signing permissions and storage accounts. Keep issuance, observed use and current validity as separate questions rather than assuming one record answers all three.

DSE recommendation

DSE recommends an issuance register containing the accountable owner, intended resource scope, permissions, expiry and approval reference. Avoid placing usable bearer tokens in ordinary logs or tickets. Review identities that can bypass the approved issuer and label that limitation in any reported token count. Do not present the application’s ledger as complete evidence of every token another authorized principal might have created.

Verification

Generate a narrowly scoped test signature through the approved workflow and confirm its metadata is recorded without exposing the token. Compare the record with the intended access and expiry. Review signing authority separately to identify issuers outside that workflow. Report known issued tokens and the tracking boundary explicitly; an empty service search is not evidence that no signatures exist.

Official references

Microsoft Learn: Grant limited access to data with shared access signatures (SAS). Source retrieved September 9, 2026.