Scripts still call the lock-photo account with the account key even though identities already have Storage Blob Data roles. Which end-state access-control change should the security engineer make?

When scripts still call the lock-photo account with the account key even though identities already have Storage Blob Data roles, the end-state control is to disable Allow storage account key access (shared key authorization) so data-plane calls must use Microsoft Entra ID or a user-delegation SAS. That takes the skeleton key off the wall once real badges exist. Account-key and account-key-signed SAS paths stop working after the change, so applications must be migrated first—then the municipal estate can enforce identity-only data-plane access.

Leaving shared key enabled forever and adding a second account key for every script fails by concept: proliferating keys expands standing secret risk instead of forcing Entra. Deleting all Microsoft Entra role assignments so only the account key remains valid fails by moving security backward and discarding the identity-based model already in place. Rotating Key Vault encryption keys weekly and assuming shared key authorization is thereby disabled fails because SSE CMK rotation is unrelated to the Allow storage account key access switch.

Exam caveat: disabling shared key authorization breaks account SAS and service SAS signed with the account key; migrate those callers to Entra or user-delegation SAS before flipping the switch. Operational check: inventory scripts still using account keys, move them to managed identities with Storage Blob Data roles or user-delegation SAS, disable shared key authorization on a nonproduction lock-photo account first, confirm key-based calls fail and Entra calls succeed, then apply to production with a documented rollback.