IAM Mistakes That Cost Companies Millions (And the Fixes)

Quickstart

If you only have 30–60 minutes, do these in order. They deliver the biggest risk reduction per unit of effort and reduce the most common “million-dollar” failure modes: over-privileged identities and long-lived credentials.

Overview

Most “cloud breaches” are not about zero-days. They’re about identity and access: an attacker finds a credential, a token, or a misconfigured trust relationship, then uses it to move laterally and escalate privileges. That’s why IAM mistakes can cost companies millions—sometimes from direct fraud and data loss, sometimes from incident response, regulatory obligations, downtime, and reputational damage.

Core concepts

IAM is easier when you think in a simple sentence: “Which principal can do what action on which resource under what conditions?” Every policy system is a variation of this.

Identity vs credentials vs permissions

Roles and session-based access (the “golden path”)

In mature cloud setups, humans and workloads rarely hold long-lived secrets. Instead they assume roles and receive a time-limited session that carries permissions. This dramatically reduces the blast radius of a leaked credential and makes offboarding simpler.

Least privilege (and why teams struggle with it)

Least privilege means granting the minimum permissions needed to perform a task. Teams often fail here because it’s tempting to “just attach admin” to get unblocked. The trick is to create developer-friendly roles that are still bounded: narrow resource scopes, time-limited elevation, and safe self-service.

Guardrails: “deny the truly dangerous stuff”

Guardrails (Org policies / SCPs / conditional access / permission boundaries) enforce global rules even if a team accidentally grants too much. This is how you prevent “never events” like disabling audit logs or making sensitive storage public.

Step-by-step

Here’s a practical hardening path you can run as a lightweight “IAM sprint.” It’s designed to be realistic: you’ll improve posture while keeping teams productive. Each step includes what to do, why it works, and what to watch out for.

Step 1 — Inventory principals and entry points

You can’t fix IAM if you don’t know who exists. Start with an inventory you can review monthly.

Step 2 — Fix login posture and break-glass access

Before you chase fine-grained permissions, close the obvious doors: missing MFA, shared admin users, and unmanaged “root”/tenant owner access.

Step 3 — Replace long-lived keys with role/session identity

The fastest way to reduce credential-leak risk is to stop minting permanent access keys. Use SSO for humans and workload identity for automation. This makes secrets scanning less stressful because fewer secrets exist.

Example 1: A minimal policy (least privilege) for a specific bucket prefix

Don’t hand out “S3:* on *” for a service that only reads from one prefix. Scope actions and resources. Add conditions when you can (tags, prefixes, VPC endpoints, source identity).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlyFromAppPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::my-company-data/app-a/*"
    },
    {
      "Sid": "ListOnlyWithinAppPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-company-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "app-a/*"
          ]
        }
      }
    }
  ]
}

Step 4 — Lock down trust policies (who can assume roles)

Permission policies get a lot of attention, but trust policies are where attackers slip in. A role with great least-privilege permissions is still dangerous if anyone can assume it.

Example 2: Terraform sketch for CI/CD using OIDC (no stored access keys)

This pattern avoids long-lived secrets in CI by letting the workflow exchange an OIDC token for a time-limited role session. The critical part is the trust policy conditions that scope assumption to a specific repo/branch/workflow.

resource "aws_iam_role" "github_actions_deploy" {
  name = "github-actions-deploy-prod"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = aws_iam_openid_connect_provider.github.arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
          StringLike = {
            # Lock to a repo and branch (tighten further to workflow if you can)
            "token.actions.githubusercontent.com:sub" = "repo:my-org/my-repo:ref:refs/heads/main"
          }
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "deploy_permissions" {
  role = aws_iam_role.github_actions_deploy.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowDeployToSpecificResources"
        Effect = "Allow"
        Action = [
          "ecs:UpdateService",
          "ecs:DescribeServices",
          "iam:PassRole"
        ]
        Resource = [
          "arn:aws:ecs:us-east-1:123456789012:service/prod/*",
          "arn:aws:iam::123456789012:role/prod-ecs-task-role"
        ]
      }
    ]
  })
}

Step 5 — Implement permission boundaries and “just-in-time” elevation

The best way to avoid chaos is to make the secure thing the easy thing. Instead of forcing every team to become IAM experts, provide: pre-approved roles, permission boundaries, and a temporary elevation path for rare admin tasks.

Step 6 — Kill key sprawl with rotation, detection, and automation

Some keys will still exist (vendor integrations, legacy systems). Make them safe: reduce scope, rotate regularly, and monitor for abnormal use. “Set and forget” is what turns a small leak into a big incident.

Example 3: Find old access keys and disable unused ones (AWS CLI)

This is a simple starting point for cleanup. In production, pair this with approvals and a safe rollback plan (disable first, then delete). Always coordinate with service owners to avoid breaking workloads.

# List access keys and their creation dates for all IAM users
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r user; do
  aws iam list-access-keys --user-name "$user" \
    --query 'AccessKeyMetadata[].{User:UserName,KeyId:AccessKeyId,Status:Status,Created:CreateDate}' \
    --output table
done

# Check last-used date for a specific key (helps find stale keys)
aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEKEYID

# Disable a key (safer first step than deleting)
aws iam update-access-key --user-name some-user --access-key-id AKIAEXAMPLEKEYID --status Inactive

Step 7 — Log, alert, and rehearse response

Even with good policies, you need detection. The IAM events you alert on should map to “attack progress” steps: new credentials, privilege escalation, persistence, and log tampering.

Common mistakes

These are the IAM mistakes that repeatedly show up in real incidents. For each one, the fix aims to reduce blast radius while keeping teams moving. If you’re doing a quarterly review, start here.

FAQ

What does “least privilege” mean in practice?

Least privilege means granting only the actions and resource scope needed for a specific task, ideally with conditions (tags, prefixes, time, network location). In practice, teams implement it iteratively: start with a bounded role, measure actual usage via audit logs, then shrink permissions and add guardrails.

Are long-lived access keys always bad?

They’re high-risk and should be minimized. Some legacy systems and vendor integrations still require long-lived keys, but they should be tightly scoped, rotated routinely, monitored for anomalous use, and stored in a proper secrets manager. For humans and CI/CD, prefer short-lived sessions.

What’s the difference between a permission policy and a trust policy?

A permission policy says what actions are allowed on what resources. A trust policy says who is allowed to assume a role (become that identity). Both matter: a least-privilege role is still dangerous if its trust policy allows unexpected principals to assume it.

How do we secure CI/CD without slowing deployments?

Use workload identity (OIDC) + role assumption instead of stored credentials, create per-repo/per-environment roles, and scope permissions to deployment actions only. This usually improves speed because developers stop requesting manual keys and the pipeline becomes easier to reason about.

What IAM changes should trigger alerts?

Prioritize high-signal events: new access keys, policy changes (especially broad grants), role trust updates, MFA disabled, and any attempt to disable or modify audit logging. These map to attacker workflows and reduce mean time to detect.

How often should we review IAM?

A solid baseline is: continuous checks in CI for IaC, monthly cleanup for keys and unused roles, and quarterly access attestation for privileged roles. If you’ve had an incident, increase cadence temporarily until hygiene is restored.

What’s the best “break-glass” approach?

Keep a small number of emergency accounts/roles with strong MFA, limited access paths, and heavy monitoring. They should not be used for daily operations, and every use should create an incident-style audit trail with explicit approval and post-use review.

Cheatsheet

Use this during design reviews, IaC PRs, vendor onboarding, and incident cleanup. It’s deliberately short and opinionated.

Wrap-up

IAM mistakes are expensive because they multiply risk: one leaked credential becomes access to many systems, and weak trust policies create invisible back doors. The fixes aren’t glamorous—roles, conditions, guardrails, key hygiene, and logging—but they’re the controls that consistently prevent “million-dollar” incidents.

Want to go deeper? The related posts below cover how apps get hacked, threat modeling templates, and DevSecOps practices that make IAM hygiene part of your delivery pipeline—without chaos.

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App