Cloud IAM Misconfigurations Checklist for AWS, Azure, and GCP

Overview

This article gives you a practical, cloud-agnostic framework for reviewing common cloud IAM misconfigurations across AWS, Azure, and GCP. It is not a catalog of every service-specific permission edge case. The goal is simpler and more durable: help teams identify the identity patterns that most often create risk and build a repeatable review process around them.

Across clouds, the same mistakes appear again and again:

• Permissions are granted broadly to speed up delivery and never narrowed later.
• Human and machine identities are mixed together without clear boundaries.
• Long-lived credentials remain active because rotation is inconvenient.
• Privileged roles accumulate through inheritance, nested groups, or ad hoc exceptions.
• Logging exists, but no one reviews the events that matter.
• Identity controls are defined manually rather than through Infrastructure as Code.

The names differ by platform, but the review logic is consistent:

• AWS: IAM users, roles, policies, trust relationships, access keys, cross-account access, permission boundaries, and service control layers where applicable.
• Azure: Microsoft Entra ID identities, role assignments, management groups, subscriptions, resource groups, managed identities, app registrations, and conditional access posture.
• GCP: Principals, IAM bindings, service accounts, organization and folder inheritance, workload identity options, and externally exposed service account credentials.

Think of IAM review as both a security and reliability function. Overprivileged identities increase blast radius during compromise, but they also make day-to-day operations harder to reason about. Teams struggle to answer basic questions such as who can deploy, who can read secrets, which automation can assume elevated roles, and what would break if access were tightened. That uncertainty is itself an operational risk.

If your platform team already manages Kubernetes, CI/CD, or Terraform workflows, this checklist fits naturally into those practices. Identity should be reviewed alongside cluster access, pipeline permissions, and infrastructure changes. For related reading, the managed Kubernetes tradeoffs in AWS EKS vs GKE vs AKS: Managed Kubernetes Comparison by Use Case can influence how you model cluster access, and your IaC strategy in Terraform vs OpenTofu: Feature Differences, Licensing, and Migration Considerations affects how enforceable your IAM standards will be.

What to track

Use this section as the core of your recurring review. Track these categories consistently, and compare them period over period rather than relying on memory.

1. Privileged identities and role sprawl

Start with the identities that can change infrastructure, read sensitive data, manage billing-related settings, alter network controls, or grant more access to others. In every cloud, these are the accounts that deserve the shortest review cycle.

• List all administrator-equivalent roles and who holds them.
• Separate permanent access from time-bound or emergency access.
• Identify inherited privilege from parent scopes, nested groups, or wildcard policy grants.
• Review whether CI/CD systems or automation accounts have admin-like access that exceeds deployment needs.

AWS checklist: Look for broad managed or inline policies, wildcard actions, wildcard resources where they are not necessary, roles trusted by too many principals, and cross-account trusts that no longer map to active workloads.

Azure checklist: Review high-privilege built-in roles, broad assignments at management group or subscription scope, stale group membership, and service principals with more permissions than their application lifecycle requires.

GCP checklist: Check primitive or overly broad predefined roles, IAM bindings at project or folder scope that should be narrower, and service accounts granted broad project-wide rights for one narrow task.

2. Human identities versus workload identities

One of the most common cloud identity security issues is blurring the line between people and machines. Humans should authenticate interactively with strong controls. Workloads should use short-lived, auditable identities tied to services, not shared user accounts.

• Find automation still using human-created credentials.
• Confirm that service accounts, managed identities, or assumed roles are used where supported.
• Eliminate shared admin accounts and team-wide credentials.
• Check whether contractors, temporary staff, or break-glass accounts are governed separately.

This is especially important in CI/CD. A pipeline that can deploy to production, read secrets, and modify IAM is not just a convenience tool; it is part of your privileged identity surface. Review repository-to-cloud trust relationships, runner permissions, and token lifetimes. If pipelines are central to your release process, pair this checklist with your workflow reviews and cost controls, such as those discussed in GitHub Actions Pricing and Usage Limits Explained.

3. Long-lived credentials and unmanaged secrets

Long-lived keys are persistent risk. They are harder to rotate, easier to leak, and often remain valid long after the original use case has changed.

• Inventory access keys, client secrets, certificates, and service account keys.
• Flag credentials with no recent rotation date or no clear owner.
• Look for credentials stored in repositories, CI variables, shell profiles, tickets, or documentation.
• Prefer temporary credentials and federated identity flows over static keys.

AWS IAM security checklist: Identify IAM users with active access keys, especially if they are used for automation that could be migrated to roles. Review unused keys and remove them rather than letting them linger in a disabled-but-not-deleted state.

Azure IAM best practices: Minimize app secrets where managed identities or stronger federation models are possible. Review certificate and secret expiration before they create availability incidents.

GCP IAM mistakes: One of the most common is allowing downloadable service account keys to multiply unchecked. Treat each key as a deprecation target unless a justified exception exists.

4. Overly broad trust and federation paths

In modern cloud environments, the dangerous permission is not always direct admin access. It is often the ability to assume, impersonate, or exchange into a more privileged identity.

• Review role assumption paths and trust policies.
• Check external identity providers and federation rules.
• Map which repositories, workloads, clusters, or third-party systems can obtain cloud credentials.
• Remove trust relationships that no longer match current architecture.

This matters in multi-account and multi-project designs. Teams often improve isolation on paper while leaving permissive trust in place between environments. If development automation can still reach production roles indirectly, the environment boundary is weaker than it appears.

5. Scope inheritance and default access

Identity problems often hide in inheritance. Access granted high in the tree feels efficient until a new subscription, project, or account inherits permissions that were never intended there.

• Review assignments at organization, management group, folder, subscription, or project parent scopes.
• Document default groups and baseline roles for new resources.
• Verify that sandbox, test, and production boundaries are enforced by identity as well as naming.
• Check whether default service accounts or default roles remain more powerful than needed.

Inheritance is why IAM review should not stop at “who has this role right now.” You also need to ask “what new resources will automatically trust this assignment later?”

6. MFA, conditional access, and login hardening

Strong authentication is not a complete IAM strategy, but weak authentication undermines every other control.

• Require strong interactive authentication for privileged users.
• Review exceptions to MFA or conditional access policies.
• Check sign-in risk handling for administrative roles.
• Separate break-glass accounts, document their use, and test them under controlled conditions.

For reliability, this is also about avoiding lockout and confusion during incidents. You want strong access controls, but you also want clear, rehearsed emergency paths. Security controls that are undocumented tend to be bypassed when pressure rises.

7. Logging, alerting, and ownership

You cannot improve IAM posture if changes are invisible. Logging must be paired with reviewable signals and named owners.

• Track privileged role grants, removals, and assumption events.
• Alert on creation of new long-lived credentials or service account keys.
• Monitor policy changes that widen access scope.
• Review inactive identities that still retain permissions.
• Assign an owner to each high-risk identity class.

Useful IAM telemetry is not the same as noisy audit collection. Focus first on access grants, trust changes, failed and successful privileged logins, token issuance to automation, and any event that expands blast radius.

8. IAM in Infrastructure as Code and platform workflows

Manual IAM changes are hard to audit and easy to forget. Mature teams move identity definitions closer to versioned workflows.

• Track which IAM resources are managed through Terraform, OpenTofu, or other IaC tools.
• Flag console-only or portal-only changes that bypass review.
• Require peer review for policy changes, trust changes, and new privileged identities.
• Compare deployed permissions to intended permissions to detect drift.

If your organization is building an internal platform, IAM standards should be part of the paved road. Platform engineering succeeds when teams can self-serve safely, not when every project invents its own access model.

Cadence and checkpoints

This section helps you turn the checklist into a repeatable operating habit rather than a one-off audit.

Monthly checkpoints should focus on fast-moving risk:

• New privileged role assignments
• New or unrotated long-lived credentials
• Changes to trust policies, federation, or external identity providers
• Inactive users or service principals still holding access
• Recent IAM changes made outside IaC workflows

Quarterly checkpoints should focus on structural cleanup:

• Role and policy right-sizing for teams and automation
• Scope inheritance review across accounts, subscriptions, folders, and projects
• Break-glass account testing and documentation review
• Exception review for MFA, conditional access, or static credentials
• Ownership validation for service accounts, app registrations, and cross-account roles

Event-driven checkpoints are just as important as scheduled ones. Revisit IAM when:

• A team launches a new platform, cluster, or shared service
• A merger, reorganization, or contractor onboarding changes access patterns
• A CI/CD workflow gains new deployment privileges
• An incident, near miss, or penetration test reveals unexpected access paths
• You migrate infrastructure management patterns, such as adopting or restructuring Terraform or OpenTofu

A practical way to keep this sustainable is to maintain a short IAM scorecard with a few recurring variables: count of privileged identities, count of long-lived credentials, count of stale service accounts, count of unmanaged IAM changes, and count of exceptions awaiting removal. The exact numbers matter less than the trend. If the line keeps moving upward, complexity is getting ahead of governance.

How to interpret changes

Changes in IAM posture are not automatically good or bad. The value comes from interpreting them in context.

If privileged identities increase, ask whether the business actually added new operational responsibilities or whether convenience is replacing role design. A temporary spike during a migration may be reasonable; a steady upward trend without cleanup is not.

If long-lived credentials remain flat, do not assume the problem is solved. Flat numbers may mean old keys are not being retired even if new federation options exist. Review age and usage, not just count.

If audit logs show frequent policy edits, distinguish between controlled change and access thrash. Frequent adjustments often point to poor role design, weak onboarding, or teams shipping around missing platform abstractions.

If inherited access expands after org changes, treat that as a design signal. New accounts, subscriptions, or projects should not silently absorb privileges from old assumptions. Revisit parent-scope assignments before the next rollout wave.

If break-glass accounts are untouched, that may be healthy, but only if they are still usable and monitored. Untested emergency access is a reliability risk hiding inside a security control.

If your IAM review repeatedly finds the same exceptions, the issue is probably process rather than policy. Either the paved road is too hard to use, or the review has no enforcement point. In that case, improving developer workflow may reduce risk more effectively than writing stricter rules. This is where security and platform engineering overlap.

When to revisit

Use this checklist on a recurring schedule, but do not wait for the calendar if your environment changes faster than your policy documents.

Revisit the article and your internal checklist when any of the following happens:

• You adopt a new cloud service that introduces a fresh identity model or trust path.
• Your organization changes how workloads authenticate, such as moving from static secrets to workload identity or federation.
• You restructure accounts, subscriptions, projects, or management groups.
• You onboard a new CI/CD system, runner model, or deployment pattern.
• You tighten compliance requirements or start preparing for external audits.
• You experience an incident involving secrets, privilege escalation, or unclear ownership.

For most teams, the most useful next step is not another policy document. It is a practical operating loop:

1. Create a cross-cloud IAM inventory of privileged roles, service identities, and long-lived credentials.
2. Mark each item with an owner, intended purpose, and review date.
3. Separate monthly checks from quarterly cleanup so the process stays lightweight.
4. Move high-risk IAM resources into reviewed, versioned infrastructure workflows.
5. Track exceptions publicly inside the engineering organization until they are removed.

If you want this to stay evergreen, treat it as a tracker rather than a tutorial you read once. Review it on a monthly or quarterly cadence, update your internal checklist as cloud defaults and platform patterns evolve, and pay attention to the variables that keep recurring: privilege, trust, credential lifetime, inheritance, and ownership. Those are the fault lines where cloud IAM mistakes tend to return.

In practice, the best IAM program is the one your team can maintain without drama. Keep the checklist short, review the same signals consistently, and make identity changes visible in the same places where you already manage infrastructure and deployments. That will do more for real-world security than an exhaustive standard no one revisits.