Most cloud breaches aren't sophisticated, they're misconfigurations

A field-update explainer published on this site. Sources at the bottom.

If you read enough cloud breach post-mortems, a pattern emerges. The headline is rarely a novel exploit chain. It's almost always a setting somebody forgot to flip: a public storage bucket, an IAM role with * on *, a security group that left port 22 open to the world for "just a few minutes" three years ago.

Industry telemetry from 2026 puts it bluntly: roughly 99% of cloud security breaches are caused by preventable misconfigurations. Over 80% of them involve mismanaged identity: over-privileged roles, leaked credentials, missing MFA on privileged accounts. Not zero-days. Not advanced persistent threats. Default settings nobody got around to hardening.

This post walks through the five misconfigurations cloud security audits keep finding in AWS and Azure, and the native tooling that prevents each one before a human can forget.

1. Public storage exposure

The S3 bucket left public is the canonical breach. It has been the canonical breach for a decade. AWS has added default-deny public-access blocks at the account level, and they still get disabled.

The fix is not "remember to set the right toggle." The fix is automated detection that flags the moment any bucket goes public, even briefly:

AWS: enable S3 Block Public Access at the account level. Use AWS Config rule s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited.
Azure: equivalent for Blob storage is Storage account public network access should be disabled in Azure Policy. Use deny-effects, not just audit-effects, so a misconfiguration can't reach production at all.

2. Over-permissive IAM

The most common audit finding by a wide margin: a role with Action: "*" and Resource: "*", attached to a workload that needed three specific S3 reads. Once that role's credentials leak (through SSRF, a compromised dependency, a developer laptop), the blast radius is the entire account.

Least privilege isn't a virtue. It's the only thing standing between one compromised pod and someone else's production database.

Tooling that catches this:

AWS: IAM Access Analyzer's "unused access" findings show every permission that has not been exercised in 90 days. Most over-broad policies shrink dramatically when scoped to actually-used actions.
Azure: Microsoft Entra Permissions Management (formerly CloudKnox) does the same for Azure RBAC.

3. Network rules left wide open

A security group with 0.0.0.0/0 on port 22, 3389, or 3306 is the definition of "trying to be hacked." Yet they're everywhere, left open during a debug session and never closed, attached as a default to a new VPC and never reviewed.

The fix is default-deny baselines:

AWS: VPC default security group with no inbound rules; deploy via Terraform/CloudFormation so it's reproducible.
Azure: NSGs with explicit allow rules only; the default-deny rule sits at the bottom of the priority list and is never disabled.

For SSH and RDP specifically, replace public access with session-based bastions: AWS SSM Session Manager, Azure Bastion. No open ports, full audit trail, no shared keys to manage.

4. Missing logging and audit trails

This is the failure that makes the next failure devastating. A breach you can't reconstruct turns into a forensic exercise that can take months and never produces a confident answer about what was taken.

Minimum bars:

AWS: CloudTrail enabled in all regions (including the ones you don't use; attackers will), logs delivered to a separate account that the compromised account can't tamper with, plus VPC Flow Logs and S3 access logs for high-value buckets.
Azure: Azure Monitor Activity Log, Diagnostic Settings on every resource that supports them, and a centralized Log Analytics workspace in a separate subscription.

The "separate account" part is the part teams skip. If logs live in the same account that gets compromised, they're not logs. They're evidence the attacker can edit.

5. Credential hygiene

Long-lived access keys committed to a public GitHub repo. Service principals with secrets that rotate "when we get to it." Personal access tokens shared over Slack. The 2026 reality is that credential theft is the #1 initial access vector in incident reports, past phishing, past unpatched vulns.

Defensive baseline:

Federate everything to a single identity provider (Okta, Entra ID, Workspace) so revoking access is a one-click action that works everywhere.
Replace long-lived keys with short-lived credentials: AWS IAM Roles, Azure Workload Identity, OIDC trust between GitHub Actions and your cloud.
Scan for committed secrets: GitHub's secret scanning, GitGuardian, TruffleHog. Pre-commit hooks catch them before they leave the laptop.

The continuous part

The trap most teams fall into is treating misconfiguration management as a project. "We'll do an audit, fix the findings, and move on." Three months later the same findings are back, plus new ones from new resources nobody catalogued.

What actually works is continuous posture management: CSPM tooling that watches the environment and re-checks every change against a baseline. AWS Config rules, Azure Policy with deny-effects, Wiz, Prisma Cloud, or any of the open-source equivalents. The exact tool matters less than that there is one, that its findings get triaged like alerts, and that the baseline is version-controlled so improvements stick.

Most cloud breaches are not exotic. They're a setting nobody owned. Pick an owner, automate the check, and move on to the harder problems.