Most Azure environments I review were set up by someone who knew enough to get the infrastructure running, but security defaults were either left as-is or quietly turned off because they were getting in the way. The result is a cloud environment that works fine on the surface, but provides high risks.
Here are some settings I find wrong most often, and what each one actually means for your business.
Storage accounts with public access enabled
Azure Storage accounts can, in older configurations, allow public internet access to containers. When that setting is on for a storage account holding anything sensitive — internal documents, backups, customer data — the contents are findable by anyone who knows where to look.
Two minutes to turn off. Consistently one of the most common ways sensitive data ends up exposed, often without anyone noticing it has happened.
No purge protection on Key Vault
Key Vault is where Azure stores secrets: connection strings, API keys, database passwords, certificates. Purge protection prevents anyone from permanently deleting a secret or the vault itself, even after it has been marked for soft-deletion.
Without it, a misconfigured script, a compromised account, or a contractor with the wrong access level can wipe your credentials permanently. No recovery. It is a one-click change that should be on by default in every environment that stores anything important.
Admin accounts with more access than they need
This is the one I fix first, every time.
Azure has a rich role-based access control system. Owner, Contributor, Reader, and dozens of built-in roles scoped to specific services. In practice, most environments I review assign Owner or Contributor to every admin account across the entire subscription, by default.
Owner access means you can do anything. Change any configuration. Delete any resource. Modify who has access to what. In environments where several people hold Owner access — including contractors and accounts belonging to people who have since left — there is no way to contain the damage if any of those accounts is compromised.
The principle of least privilege is not optional. A developer should have write access to their application's resource group and read access to shared services, nothing else. A contractor should get exactly what they need for the engagement, scoped to the resources they are working on, with an expiration date on that access.
Microsoft Entra ID's Privileged Identity Management can enforce this automatically: just-in-time access, time-limited elevation, approval workflows. Most SMBs have never looked at it. The result is a flat access model where everyone is either an Owner or a Reader, and the Owner accounts are where the real risk lives.
NSG rules that allow inbound traffic from anywhere
Network Security Groups control what traffic is allowed into your virtual machines and services. The problem is almost always the same: an inbound rule was added to fix a connection issue, it worked, and it was never removed.
Port 22 or port 3389 open to 0.0.0.0/0 is a common
finding. These ports get scanned continuously by automated
tools. If the account on the other end has a weak password, the
path in is not complicated. Every NSG inbound rule should
specify a source IP range, not any address.
No diagnostic logging
When something goes wrong, logging is the difference between understanding what happened and having no idea.
Azure resources can log everything: who signed in, what changed, which API calls were made, and when. Logging is not enabled by default on most resources, and it costs a small amount to store, so it often gets skipped during setup. The consequence is that when a configuration changes unexpectedly or data disappears, there is no audit trail.
Enabling diagnostic logs on Key Vault, storage accounts, and the management plane is cheap. Not having them when you actually need them is expensive in a different way.
Start with these five before spending time on anything more complex. None of them require a security consultant or a multi-week project. They require someone to sit down and check each one, which most SMB teams never do because there is always something more urgent.
The urgency changes quickly when something goes wrong.