We audit a lot of Azure tenants. The findings that worry us most aren’t clever. They’re the same handful of basic mistakes, on roughly every other tenant we look at, year after year. None require a sophisticated attacker. Most are one toggle or one policy away from fixed.
Here are the five we still find in 2026.
What it is. A storage account configured to allow anonymous public read on blob containers. Anyone with the URL, or anyone who guesses it, reads the data.
How it happens. A developer needs to serve a file quickly, flips public access on to make it work, and never reverts it. Or an infrastructure template ships with public access enabled by default and nobody overrides it. The container fills with documents, backups, or customer data over time.
What it enables. Direct data exfiltration with no authentication and no alert. Public blob exposure is the single most common cause of Azure data leaks, and the data usually surfaces when a researcher or an attacker finds the open container, not when you notice.
How to fix. Disable public blob access at the account level and enforce it tenant-wide with an Azure Policy that denies storage accounts with public access enabled. Serve files that genuinely need to be public through a CDN or signed URLs instead.
What it is. An app registration or service principal holding Owner or Contributor at the subscription scope, with a client secret that never expires and has never been rotated. Frequently the secret is also sitting in a repository or a pipeline variable in plaintext.
How it happens. A CI/CD pipeline needs to deploy, so someone grants the service principal broad rights to make it work, sets a long-lived secret, and moves on. The over-permissioned identity outlives the project that created it.
What it enables. Full control of the subscription for anyone who obtains the secret. A leaked credential with subscription Owner is game over: create resources, read every data store, delete the backups, pivot wherever they like. The lack of rotation means a leak from years ago may still be live.
How to fix. Use managed identities for anything running in Azure, and workload identity federation for CI/CD so there’s no static secret at all. Where a secret is unavoidable, store it in Key Vault, scope the principal to the specific resource groups it needs, and rotate on a schedule.
What it is. A network security group rule permitting inbound RDP (3389) or SSH (22) from the entire internet to a VM.
How it happens. Someone needs to reach a server during setup, opens the management port to “anywhere” to unblock themselves, and the temporary rule becomes permanent. It’s the most quietly common gap we find.
What it enables. Internet-wide brute-force and credential-stuffing against your management plane. Automated scanners find an open 3389 or 22 within hours of it appearing. From a compromised VM, an attacker moves laterally into the rest of the environment.
How to fix. Never expose management ports to the internet. Use Azure Bastion or just-in-time VM access so ports open only on request, for a limited window, from a known identity. Enforce with an Azure Policy that denies NSG rules allowing 0.0.0.0/0 on 22 or 3389.
What it is. Resources with diagnostic settings switched off, or logs shipped only to a storage account with default retention that nobody queries and nothing alerts on.
How it happens. Logging isn’t on by default for every resource, and enabling it properly takes deliberate setup. Under delivery pressure it gets skipped, or half-done by pointing logs at a storage account and calling it finished.
What it enables. Blindness. When an incident happens, you can’t reconstruct what occurred because the evidence was never captured, or it expired, or it’s in a write-only bucket nobody can search. You can’t detect an attack in progress and you can’t investigate one after the fact.
How to fix. Send diagnostics from every resource to a central Log Analytics workspace, retain logs for at least the period your compliance regime requires, and alert on high-signal events like privileged role activation and firewall changes. Logs you can’t query aren’t monitoring.
What it is. A tenant running real production workloads with Defender for Cloud left on the free tier, which gives you posture scoring but none of the active threat detection.
How it happens. The paid plans cost money, the free tier looks like it’s “on,” and nobody makes the case to upgrade. The security dashboard shows a score, which creates a false sense that protection is active.
What it enables. Threats that go undetected. The paid Defender plans catch anomalous access, malware in storage, SQL injection attempts, suspicious container activity, and the access patterns that precede a breach. On the free tier, those detections simply don’t run. You find out about the compromise some other way, later, and worse.
How to fix. Enable the paid Defender plans on the workloads that matter: Servers, Storage, SQL, Containers, Key Vault. Route the alerts to someone who acts on them, with response times tied to severity.
None of these are advanced. They’re the controls that get skipped when a deadline is close and revisited never. The encouraging part is that the paid Defender for Cloud will flag most of them for you, which is a good reason to turn it on as step one. It pays for itself the first time it catches an open storage container before someone else does.
If you’d like these checked on your tenant, our cybersecurity team runs a full audit that surfaces these and a lot more, with a ranked remediation plan rather than a raw scanner dump. Book a consultation and we’ll tell you, before we start, roughly where we expect to find the gaps.