We’ve audited environments ranging from three-person startups to multi-account enterprise setups, and one pattern holds regardless of size: the same handful of misconfigurations show up almost every time. None of them require a sophisticated attacker to exploit — they just require someone to notice they exist. Here are the five we see most often, and why they keep happening.
1. Root Account Without Hardware MFA
The AWS root account has unrestricted power over the entire account — billing, IAM, every resource. Despite that, we routinely find root accounts protected only by a password, or by SMS-based MFA rather than a hardware key or authenticator app. Given how routinely SMS is intercepted through SIM-swapping, this is functionally close to no MFA at all.
Quick check: In IAM, look at “Security Status” — it will explicitly flag whether root MFA is enabled and what type.
2. Publicly Readable S3 Buckets
This one makes headlines every few months because it keeps happening. A bucket gets created for a legitimate reason — sharing files with a contractor, staging a website — and the public access setting never gets reverted. Combine that with customer data landing in the wrong bucket, and you’ve got a reportable breach waiting to be discovered by a security researcher instead of by you.
Quick check: Turn on “Block Public Access” at the account level as a default posture, then deliberately allow exceptions only where genuinely required (and document why).
3. Wildcard IAM Policies
"Action": "*" and "Resource": "*" show up far more often than they should, usually because it was faster to grant broad access during initial setup and nobody circled back to scope it down. The problem: if any single credential with that policy attached is compromised, the blast radius is the entire account.
Quick check: AWS IAM Access Analyzer will show you what permissions are actually being used versus granted — the gap between the two is your remediation list.
4. CloudTrail Not Enabled Across All Regions
Multi-region CloudTrail coverage is easy to overlook because most day-to-day activity happens in one or two primary regions. But attackers know this too, and will sometimes deliberately operate in an unmonitored region specifically because logging isn’t there to catch them.
Quick check: CloudTrail should show a trail applied to “all regions,” with log file validation enabled so logs can’t be silently altered after the fact.
5. Security Groups Open to the World on Management Ports
Port 22 (SSH) or 3389 (RDP) open to 0.0.0.0/0 is one of the first things any automated scanner — friendly or hostile — will find. It’s frequently left over from initial setup or troubleshooting and never tightened back down.
Quick check: Management ports should only be reachable from a VPN, bastion host, or a specific known IP range — never the open internet.
Why These Keep Showing Up
None of these are exotic. They’re all “good enough for now” decisions made under time pressure that never got revisited. That’s exactly why a periodic third-party audit matters — not because your team doesn’t know better, but because nobody has the bandwidth to re-check every setting on a recurring basis while also shipping product.
If you want a sense of how these get documented and prioritized in a real engagement, we’ve published a redacted sample cloud security audit report showing the same structure we use for clients.