IAM Policy Mistakes That Get You Breached (Across All Clouds)

IAM Is Your Most Important Security Control

Identity and Access Management is the first and most critical layer of cloud security. When IAM is configured correctly, every principal (user, service, application) has exactly the permissions it needs and nothing more. When IAM is misconfigured, the consequences range from data breaches and unauthorized resource modification to complete account takeover. The majority of cloud security incidents involve IAM misconfigurations — not sophisticated zero-day exploits, but simple mistakes like overly broad permissions, exposed credentials, or missing access controls.

This article catalogs the most dangerous IAM anti-patterns across AWS, Azure, GCP, and OCI. For each anti-pattern, we explain why it is dangerous, how to detect it in your environment, and the specific fix to apply. These are not theoretical risks — they are the patterns that security teams find in real cloud environments every day, and they are the patterns that attackers look for first.

Mistake 1: Using Wildcard Actions and Resources

The most common IAM mistake on AWS is policies with "Action": "*" and "Resource": "*". This grants full administrative access to every service and resource in the account. It is the equivalent of running everything as root on a Linux system. Yet it is disturbingly common because it is the fastest way to "make things work" during development, and the policy often migrates to production unchanged.

On Azure, the equivalent is assigning the Owner or Contributor role at the subscription level. On GCP, it is granting the Editor or Owner primitive role at the project level. On OCI, it is policies with Allow group AdminGroup to manage all-resources in tenancy. In every case, the result is the same: a principal that can do anything, including actions that should never be automated like deleting backups, modifying security groups, or exfiltrating data.

The fix is to use the principle of least privilege. On AWS, use the IAM Access Analyzer to generate policies based on actual usage from CloudTrail logs. Start with a broad policy, let the workload run for 30-90 days, then use Access Analyzer to create a scoped policy that includes only the actions and resources actually used. On Azure, use the Microsoft Entra ID access reviews and Azure Policy to detect over-privileged role assignments. On GCP, use IAM Recommender to identify and remove unused permissions. On OCI, use the IAM Policy Analyzer to evaluate policy statements.

Mistake 2: Long-Lived Access Keys and Service Account Keys

Long-lived credentials — AWS access keys, GCP service account keys, Azure service principal secrets — are the most frequently exploited attack vector in cloud environments. These credentials do not expire by default, are often stored in code repositories, environment variables, CI/CD configurations, and developer laptops, and are difficult to rotate without service disruption. A single leaked access key can give an attacker full access to your cloud environment.

On AWS, replace access keys with IAM roles wherever possible. EC2 instances should use instance profiles, Lambda functions should use execution roles, ECS tasks should use task roles, and EKS pods should use IRSA or Pod Identity. For CI/CD pipelines, use OIDC federation with GitHub Actions, GitLab CI, or your CI provider instead of storing AWS access keys in the pipeline configuration. For developers who need CLI access, use AWS SSO (IAM Identity Center) with temporary credentials rather than permanent access keys.

On GCP, avoid creating service account keys entirely. Use Workload Identity Federation for external workloads (CI/CD pipelines, other clouds), Workload Identity for GKE pods, and the default service account credentials for Compute Engine instances and Cloud Run services. GCP's IAM Recommender flags unused service account keys, and Organization Policy constraints can prevent key creation entirely.

On Azure, use Managed Identities instead of service principal secrets. System-assigned and user-assigned managed identities provide automatic credential rotation and eliminate the risk of credential leakage. For workloads running outside Azure, use Workload Identity Federation with OIDC tokens.

On OCI, use instance principals for compute instances and resource principals for functions and other services. Avoid creating API keys for service accounts when instance or resource principals are available.

Mistake 3: No MFA on Human Accounts

Multi-factor authentication on human cloud console and CLI access is non-negotiable. Without MFA, a compromised password (from phishing, credential stuffing, or password reuse) gives an attacker direct access to your cloud console with whatever permissions the user has. MFA adds a second factor — typically a TOTP code or hardware security key — that the attacker cannot obtain from a password breach alone.

On AWS, enforce MFA for all IAM users through an IAM policy that denies all actions unless MFA is authenticated. Enable MFA on the root account and lock it away. For SSO users through IAM Identity Center, configure MFA in the identity provider. On Azure, enable Security Defaults or Conditional Access policies that require MFA for all users accessing the Azure portal and Azure CLI. On GCP, enforce 2-Step Verification through Google Workspace or Cloud Identity settings. On OCI, enforce MFA through the Identity Domain sign-on policies.

Hardware security keys (YubiKey, Google Titan) provide the strongest MFA protection because they are resistant to phishing attacks. TOTP authenticator apps are acceptable. SMS-based MFA is better than nothing but is vulnerable to SIM swapping attacks and should be replaced with a stronger method when possible.

Mistake 4: Overly Permissive Resource Policies

Resource-based policies — S3 bucket policies, KMS key policies, SNS topic policies, SQS queue policies — are often more permissive than intended. The most dangerous pattern is a resource policy with "Principal": "*" (any AWS account, any user, anyone on the internet) without appropriate conditions. This has led to countless S3 data breaches where sensitive data was publicly accessible because a bucket policy allowed anonymous access.

On AWS, use IAM Access Analyzer to identify resources with public or cross-account access. Access Analyzer continuously monitors resource policies and flags any that grant access to external principals. Enable Access Analyzer in every account and region, and treat its findings as critical security alerts. For S3 specifically, enable S3 Block Public Access at the account level to prevent any bucket from being made public, even accidentally.

On Azure, review Azure Storage account access levels and ensure that anonymous blob access is disabled unless explicitly required. Use Azure Policy to enforce the "Secure transfer required" and "Disallow shared key access" settings. On GCP, use IAM policy analysis and the Security Command Center to identify resources with overly permissive IAM bindings, particularly allUsers and allAuthenticatedUsers bindings. On OCI, review Object Storage bucket visibility settings and use Security Zones to prevent public bucket creation.

Mistake 5: No Service Control Policies or Organization-Level Guardrails

Individual account-level IAM policies are necessary but not sufficient. Without organization-level guardrails, any administrator in any account can potentially create public resources, disable logging, launch expensive instances, or deploy workloads in unauthorized regions. Service Control Policies (SCPs) on AWS, Azure Policy at the Management Group level, Organization Policies on GCP, and compartment-level policies on OCI provide the organizational guardrails that prevent these actions regardless of individual account permissions.

Essential SCPs for AWS include: denying access to regions you do not use, preventing disabling of CloudTrail, GuardDuty, and Security Hub, preventing modification of IAM roles used by security tooling, denying root account usage for non-emergency operations, and requiring encryption on S3 buckets and EBS volumes. On Azure, essential policies include: requiring diagnostic settings on all resources, enforcing encryption requirements, restricting allowed VM sizes and regions, and requiring tags on resources. On GCP, essential organization policies include: restricting resource locations, disabling service account key creation, requiring organization-level audit logging, and restricting public IP creation.

Mistake 6: Not Rotating Credentials

Even when long-lived credentials cannot be eliminated entirely, they must be rotated regularly. AWS access keys should be rotated every 90 days at minimum. Azure service principal secrets should have expiration dates set at creation and be rotated before expiry. GCP service account keys should be rotated on a 90-day cycle if they cannot be eliminated. OCI API keys should be rotated quarterly.

Automate rotation wherever possible. AWS Secrets Manager can automatically rotate database credentials, API keys, and other secrets on a schedule. Azure Key Vault supports automatic certificate rotation. For access keys and service account keys, build automation that creates a new key, updates all consumers, verifies functionality, and then deletes the old key.

Monitor for unused credentials. AWS IAM Credential Reports and Access Advisor show when credentials were last used. Disable or delete any access keys, passwords, or service account keys that have not been used in 90 days. On GCP, the IAM Recommender identifies unused service accounts and their keys. On Azure, Microsoft Entra ID provides sign-in logs and unused application credential reports.

Mistake 7: Cross-Account Access Without External ID

On AWS, when you grant cross-account access using IAM role trust policies, you must include an External ID condition to prevent the "confused deputy" attack. Without an External ID, any principal in the trusted account can assume the role — not just the specific service or application you intended. This is particularly dangerous when granting access to third-party SaaS services, because the third party's other customers could potentially assume the role in your account.

On Azure, cross-tenant access should use Azure AD (Entra ID) B2B collaboration or cross-tenant access policies rather than sharing service principal credentials. On GCP, cross-project access should use IAM bindings with specific service accounts rather than broad project-level roles. On OCI, cross-tenancy policies should specify explicit tenancy OCIDs and group names.

Mistake 8: Excessive Use of Admin and Root Accounts

The root account (AWS), Global Administrator (Azure), Organization Admin (GCP), and tenancy administrator (OCI) should be used only for initial setup and emergency break-glass scenarios. Day-to-day operations should use purpose-specific roles with limited permissions. Many organizations use root or admin accounts for routine tasks because it is convenient, but this means every routine operation is performed with the maximum possible blast radius.

Secure root and admin accounts by: enabling MFA (preferably hardware), using a dedicated email address not tied to any individual, storing credentials in a physical safe or secure vault, and monitoring usage with alerts. Any use of the root account should trigger an immediate security alert for investigation. On AWS, create an EventBridge rule that triggers an SNS notification when the root user authenticates. On Azure, configure a Conditional Access policy that blocks Global Administrator sign-in except from managed devices with MFA.