A ground-handling contractor at an outstation needs to upload a batch of ramp-inspection photos into one virtual folder in a Blob container for a single afternoon. An IT technician suggests just giving the contractor the storage account access key since it's quick to hand over. Why is that the wrong call?

The storage account key is a symmetric secret that authorizes every operation across every service in the account — blobs, queues, tables, files — with no built-in expiry, so handing it to a contractor for an afternoon task leaves standing, unmonitored, full access long after the task ends. A SAS, by contrast, can be scoped to exactly the container the contractor needs, restricted to the write permission the upload requires, and set to expire once the afternoon is over, which matches the actual business need instead of over-granting. Treating the account key as merely 'simpler to type' ignores that the risk isn't typing effort — it's the blast radius if that credential is ever copied, logged, or reused after the engagement ends. Spinning up a brand-new storage account per contractor is operational overkill: it multiplies accounts to manage, doesn't scope permissions any better within that account, and does nothing to add an expiry. Rotation on a 90-day timer doesn't help either, since the key remains fully valid and usable by the contractor for the entire 90 days regardless of task duration. One caveat: a SAS still needs its own expiry and permission set chosen carefully, since an overly generous SAS repeats the same mistake at a smaller scale. To confirm the fix, check that the credential given to the contractor stops working automatically once its expiry passes.