Articles / IAM Misconfiguration: The Root Cause of Most Cloud Breaches
Cloud · IAM

IAM Misconfiguration: The Root Cause of Most Cloud Breaches

When a cloud breach gets written up, the headline usually names a leaked bucket or an exposed server. Read the post-mortem and you find the same quieter culprit underneath almost every one: identity and access management that was configured wrong. In the cloud there is no network cable to unplug and no server room to lock. Access is the perimeter, and IAM is where that perimeter is defined — or quietly dismantled.

Every action in AWS, Azure, or Google Cloud is an API call, and every API call is allowed or denied by an identity policy. That makes IAM the single most powerful control plane you own. It also makes it the largest and most error-prone surface you manage. A policy is just text: a JSON document, a role assignment, a group membership. Nothing about it looks dangerous, which is exactly why over-broad grants accumulate for years without anyone noticing.

What 'misconfiguration' actually looks like

phish / leaked keylooks legitimateAttacker withvalid credentialsOver-scoped identitywildcard / unused / no MFACloud APIglobal endpointYour data & resourcesOver-broad grant →attacker looks likea valid user
With over-scoped credentials, an attacker's API calls look entirely legitimate.

IAM misconfiguration is rarely one dramatic mistake. It is an accretion of small, reasonable-at-the-time decisions that never got walked back. The classic patterns repeat across every provider:

  • Wildcard permissions. An AWS policy with "Action": "*" on "Resource": "*", or an Azure Owner role handed out because Contributor "wasn't quite enough." The grant solves today's ticket and becomes tomorrow's escalation path.
  • Trust relationships that trust too much. A role whose trust policy allows any principal in the account to assume it, or a cross-account role assumable without an external ID, turns one foothold into many.
  • Long-lived static keys. Access keys embedded in code, CI systems, and laptops, never rotated, often over-privileged — the credential that shows up in the breach report.
  • Human accounts without MFA. A console login protected by a password alone is one phishing email away from being the attacker's login too.
  • Unused identities left enabled. The contractor role, the decommissioned service account, the key for a project that shipped last year — all still valid, all still trusted.
Why it matters: You cannot firewall your way out of an identity problem. An attacker holding valid, over-scoped credentials looks exactly like a legitimate user — because to the cloud, they are one.

Why the cloud makes it worse

On-prem, a stolen credential still had to traverse a network someone had segmented. In the cloud, a set of keys is a global API endpoint away from acting. Permissions also compose in ways that are hard to reason about: an identity that can create roles can grant itself anything; an identity that can update a Lambda function or attach a policy can escalate without ever touching an admin account directly. Provider defaults do not save you either — a freshly created service account or managed identity often has more reach than its owner assumes, and least privilege is a thing you build, never a thing you inherit.

An over-broad policy that should never ship{ "Effect": "Allow", "Action": "*", "Resource": "*" }

Closing the gap

The goal is not a perfect policy on day one; it is a system that trends toward least privilege and surfaces drift before an attacker does.

  • Start from deny, grant narrowly. Scope actions and resources to what a workload actually calls. Use access analyzers and last-accessed data to prune permissions that were never exercised.
  • Prefer short-lived, federated credentials. Assume-role and workload identity federation replace static keys with tokens that expire, shrinking the value of anything stolen.
  • Enforce MFA on every human, everywhere. Especially on the root or global-admin accounts, which should be locked away and almost never used.
  • Guardrail with boundaries. Permission boundaries, service control policies, and Azure/GCP org policies cap what any identity can do regardless of its attached grants.
  • Review continuously, not annually. Alert on new wildcard grants, new trust relationships, and dormant identities. IAM drifts the moment you stop watching.

IAM misconfiguration is boring, which is precisely why it wins. It does not exploit a flaw in the cloud; it uses the cloud exactly as designed, with permissions someone granted and forgot. The first step is the same one every cloud security program keeps relearning: you cannot right-size access you have never inventoried — you can't defend what you haven't discovered.

Test for it — in practice
  • Search your IAM policies for "Action": "*" on "Resource": "*" (or an Azure Owner / GCP Owner grant) and ask whether each one truly needs it.
  • Spot-check for human accounts without MFA and access keys that have not been rotated in months — both are routine breach starting points.

Grepping for wildcards is a start; right-sizing every identity against what it actually uses, continuously, is what our assessment runs for you.

Keep reading
Over-Permissioned Roles and Privilege Escalation Paths