Shortly after Cascade's central IT rotated a storage account's access keys, several outstation applications using recently issued service SAS tokens for a container suddenly began receiving authorization failures, while everything else kept working. What's the most likely cause, and what fixes it going forward?
Select an answer to reveal the explanation.
Short Explanation
A service SAS is only as valid as the key that signed it — rotate that key, and every SAS built from it instantly stops working, even though nothing else about the account changed. That's exactly the pattern here: one key swap, and only the SAS-dependent apps broke. Reissue SAS after rotation, or switch future ones to a user delegation SAS, which Microsoft Entra ID backs instead of the account key.
Full Explanation
A service SAS signed with the account key derives its validity directly from that key's cryptographic material, so regenerating the key breaks the signature on every SAS previously generated with it — explaining why only the SAS-dependent applications failed while credentials using other authentication methods kept working. Going forward, either regenerate and redistribute SAS tokens immediately after any key rotation, or switch to a user delegation SAS, which is signed with a key requested from Microsoft Entra ID rather than from the account key, so an account key rotation never touches it. The claim that SAS tokens always expire after 24 hours is false — expiry is a configurable field set at creation time and can range from minutes to days depending on the SAS type, so a fixed 24-hour rule doesn't explain a failure that coincided precisely with a key rotation event. The notion that rotating one key invalidates the other is a common misconception: the two account keys are deliberately independent, which is exactly what makes a zero-downtime rotation possible — you move clients to one key, rotate the other, then swap back. A change in public access level would surface as anonymous requests failing, not as signed SAS requests failing, and rotating a key does not alter a container's access level at all. A caveat worth being precise about: a stored access policy does not solve this. A service SAS that references one is still signed with the account key, so rotation invalidates it just the same — a policy buys server-side revocation, not independence from the key. To confirm the diagnosis, check the storage account's activity log for a key regeneration event that lines up with the timestamp the SAS failures began.