Cloud PAM and CIEM Guide

In the cloud, privilege is not a small set of admin accounts: it is thousands of IAM policies, role assignments, service principals and trust relationships spread across accounts, subscriptions and projects. Most human and machine identities hold far more permission than they use, and one over-permissive role is often the step from a foothold to full control of a tenant. Cloud infrastructure entitlement management (CIEM) finds and right-sizes those permissions; cloud privileged access management (cloud PAM) replaces standing admin rights with just-in-time, approved and recorded elevation. This guide explains why cloud privilege is hard, what each discipline does, how to remove permissions without breaking production, and how to measure progress. It is written for cloud security engineers, IAM and PAM owners, platform teams and the architects who design landing zones.

Key takeaways

• Cloud privilege lives in policy, not in a vault. Effective access comes from identity policies, resource policies, role assumption and organisation guardrails, much of it attached to non-human identities, so vault-centred PAM covers only part of the problem.
• CIEM measures the gap between granted and used. It computes effective permissions, compares them with activity over a look-back window and flags escalation paths, cross-account trusts and dormant identities.
• Cloud PAM removes standing admin. Humans, and increasingly workloads and AI agents, hold eligibility rather than permanent roles, and activate time-bound access with MFA, justification and approval.
• Escalation permissions matter more than admin labels. Rights such as creating policy versions, attaching policies or passing roles let a modest identity make itself an administrator, and some of them are not visible in activity data.
• Right-size in stages and lock the gains in. Start with unused high-risk permissions, test in non-production, then use guardrail policies and infrastructure-as-code checks so excess does not return.

Why cloud privilege is hard

On premises, privileged access usually meant a known list of domain admins and server accounts. In the cloud, every API call is authorised against policy, so privilege is spread across every identity that can call a sensitive API.

• Scale and granularity: each major provider exposes thousands of individual actions across hundreds of services, and new ones arrive constantly. Hand-written least-privilege policies rarely keep up.
• Many identity types: users, groups, roles, service accounts, service principals, managed identities, federated identities, agent identities and cross-account trusts, each with its own credential and lifecycle.
• Inheritance and indirection: permissions flow from organisation, folder, account, subscription and resource level, from roles that can be assumed and from resource-based policies. Google Cloud warns that a service account "can be accessed and possibly impersonated by other principals", so access to the account is itself a privilege.
• Escalation paths: Rhino Security Labs documented 21 AWS IAM privilege escalation methods, building on CyberArk's "AWS Shadow Admins" research, such as creating a new policy version or passing a role to a new Lambda function.
• Machine identities dominate: most cloud identities are workloads created by automation, often with broad default roles. Google Cloud notes that some services create a default service account with the Editor role on the project by default.

The data shows how common excess is. According to Datadog's State of Cloud Security research, 59% of AWS IAM users have an active access key older than one year, almost one in five EC2 instances (19.4%) is overprivileged, and 17% of Google Cloud VMs have project-wide editor permissions through the Compute Engine default service account.

Attackers exploit exactly this. In the 230 Million AWS Cloud Environments Campaign 2024, Unit 42 reports that keys taken from exposed .env files lacked full admin rights but could create roles, so the attackers created a role and attached the AWS-managed AdministratorAccess policy. In TruffleNet 2025, Fortinet observed more than 800 hosts testing stolen AWS credentials, and an account with enough privilege to use Amazon SES supported business email compromise. See the Identity Attack Paths Guide.

What CIEM does

CIEM is the analysis layer: it answers "who can do what, to which resource, through which path, and do they use it?"

• Inventory: every human and non-human identity, role, policy and trust relationship across all accounts, subscriptions and projects, including third-party integration roles.
• Effective permissions: resolve inherited, group, assumable and resource-based access into a single answer per identity and resource.
• Granted versus used: compare permissions with activity over a look-back window to find unused roles, keys and actions.
• Risk findings: admin and wildcard grants, escalation-capable actions, external and cross-account trusts, impersonation chains, dormant identities and long-lived keys.
• Remediation: least-privilege policy suggestions, ideally delivered as infrastructure-as-code changes to the team that owns the identity.

Native analysis in the major clouds

Native tools are a good start in a single cloud. Dedicated CIEM, ISPM or CNAPP products add multi-cloud normalisation, identity-provider context and attack path graphs. See the ISPM Guide.

What cloud PAM does

Cloud PAM is the control layer for privileged sessions. Where CIEM shrinks standing permissions, cloud PAM ensures the remaining powerful roles are held only for as long as a task needs them.

• Eligibility, not assignment: Microsoft Entra Privileged Identity Management (PIM) distinguishes eligible assignments, which must be activated, from active ones, and notes there is "no difference in the access given" once activated; the difference is that people do not hold it all the time. See the JIT Access Guide.
• Conditions on activation: MFA, a business justification and, for high-risk roles, approval. Google Cloud Privileged Access Manager adds multi-level and multi-party approvals, which support separation of duties.
• Time limits: each entitlement has a maximum duration, after which the role is revoked automatically.
• Evidence: who elevated, why, for how long and what they did, logged to the provider's audit service and to your SIEM.
• Brokered sessions: access to cloud VMs, Kubernetes clusters and databases through recorded sessions rather than direct keys. See the Privileged Session Management Guide.

CIEM and cloud PAM compared

For the provider specifics, see the Privileged Identity Management (PIM) Guide and the Privileged Access Management Guide.

Privilege escalation paths to close first

Admin labels mislead: an identity without AdministratorAccess may still be one API call from it. Treat these permission families as privileged wherever they appear.

Right-sizing safely

Right-sizing fails when it breaks a quarterly batch job and the change is rolled back with broader rights than before. A staged method avoids that.

1. Collect enough activity data. Cover periodic jobs: quarter-end, annual and disaster recovery tasks may not appear in a 90-day window. Google Cloud's recommender uses at most 90 days; AWS service-level last accessed data covers at least 400 days.
2. Start with high-risk, unused permissions: IAM write, role assignment, key creation, KMS and data deletion rights that are never used.
3. Remove dormant identities and keys. Google Cloud advises disabling unused service accounts before deleting them, so a missed dependency can be restored quickly.
4. Replace wildcards (* actions or resources) with specific actions, resources and conditions.
5. Handle blind spots by hand. Because iam:PassRole is not in last accessed data or generated policies, review PassRole grants against deployment pipelines separately.
6. Stage changes: apply in non-production, watch for access denied errors, then promote. Keep the previous policy version for quick fallback.
7. Prevent regression: service control policies, permissions boundaries, organisation constraints and infrastructure-as-code checks. AWS notes that SCPs never grant permissions and do not affect the management account, so keep workloads out of that account. See the Infrastructure as Code Security Guide.

Where a permission is used rarely but legitimately, move it to a just-in-time entitlement rather than keeping it standing; Google Cloud describes exactly this pattern for remediating recommender findings with Privileged Access Manager.

Non-human identities in the cloud

OWASP's Non-Human Identities Top 10 lists Overprivileged NHI (NHI5), Insecure Cloud Deployment Configurations (NHI6) and Long-Lived Secrets (NHI7), and all three are cloud privilege problems.

• Use platform identities, not keys: AWS recommends that workloads use temporary credentials with IAM roles; Azure managed identities and attached Google Cloud service accounts do the same. Google Cloud recommends avoiding service account keys "whenever possible". See the Cloud Workload Identity Guide and the Workload Identity Federation Guide.
• One workload, one identity: reuse (NHI9) means a compromise of one service exposes every other service sharing the credential.
• Constrain who can pass roles and create keys for service accounts; these are the levers attackers use to borrow workload privilege.
• Pin trust policies for federation and cross-account roles to specific principals, audiences and conditions. Datadog found that 12.2% of third-party integration roles are dangerously overprivileged and 2.25% do not enforce an external ID.
• Fix defaults: enable the Google Cloud constraint iam.automaticIamGrantsForDefaultServiceAccounts so default service accounts are not granted Editor, and avoid domain-wide delegation, which lets a service account impersonate any user, including super-admins.
• Least privilege on workload identity contains incidents. In the Storm-2949 Azure Attack 2026, Microsoft reports the attacker used a VM's managed identity to try to read a production Key Vault, but failed because "the managed identity lacked the required permissions".

See the AWS IAM Policies and Roles Guide, the Azure RBAC and Service Principals Guide and the Google Cloud IAM and Service Accounts Guide.

AI agents and cloud privilege

AI agents that call cloud APIs are a new class of privileged non-human identity. They act on natural-language goals, can be steered by injected content and often run with the credentials of the developer or pipeline that launched them. Apply the same model as for workloads, with tighter limits:

• A dedicated identity per agent, never a shared developer profile or a long-lived key in the agent's configuration.
• Read-only by default; write, delete and IAM actions only through just-in-time entitlements. Google Cloud Privileged Access Manager supports agent identities and lets service accounts or agent identities self-elevate only when needed for automated tasks.
• Human approval for destructive or privilege-changing actions, enforced in the cloud control plane, not just in the agent's prompt.
• Separate logs so agent actions can be told apart from human and pipeline actions.

See the AI Agent Authorisation Guide and the Zero Trust for AI Agents Guide.

Detection and monitoring

Right-sizing lowers the impact of a compromise; monitoring shortens it. MITRE ATT&CK's detection strategy for Additional Cloud Roles looks for new IAM roles or policies attached to a user or service "outside normal patterns or hours", and its Cloud Accounts analytics include API calls that exceed an account's normal scope, such as IAM changes or services never used before.

• IAM change events: CreateRole, AttachRolePolicy, CreatePolicyVersion, CreateAccessKey, UpdateLoginProfile and their Azure and Google Cloud equivalents (role assignment writes, service account key creation).
• Reconnaissance from new sources: GetCallerIdentity, the first call in both the Unit 42 and Fortinet reports, followed by enumeration such as ListUsers and ListBuckets (Unit 42) or SES GetSendQuota (Fortinet).
• Elevation outside the PAM path: privileged role use without a matching activation or approval record.
• Workload identity used from an unexpected place: instance or managed identity tokens used outside the compute resource they belong to.
• Secrets store access spikes: Microsoft reports Storm-2949 changed Key Vault access configuration and read dozens of secrets within four minutes.

See the Cloud Logging and Audit Trail Guide and the Cloud Credential Compromise Playbook.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official mapping by any framework owner. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 OSCAL catalogue, the CIS Controls assessment specification and a published ISO/IEC 27001:2022 Annex A list.

For cloud-specific controls, the CSA Cloud Controls Matrix (197 control objectives in 17 domains) and the CIS Foundations Benchmarks for each provider add detail.

Common failure patterns

• Counting admins instead of escalation paths: the admin list looks short while dozens of roles can create policies or pass roles. The Unit 42 campaign escalated from a non-admin key that could create roles.
• Trusting activity data blindly: generated policies omit iam:PassRole, and short windows miss quarterly jobs, so automated right-sizing either breaks things or is quietly reverted.
• JIT for humans, standing admin for pipelines: the console is locked down, but the deployment role and the Terraform runner keep permanent organisation-wide admin.
• Old keys nobody owns: keys older than a year and unused for 90 days stay active because no one is sure what uses them. See the NHI Ownership Guide.
• Help desk and recovery bypass PAM: Storm-2949 took over privileged users through social engineering of self-service password reset, then used the privileged custom Azure RBAC roles already assigned to them on several subscriptions.
• Guardrails with gaps: SCPs that exempt the management account (by design) while workloads run there, or exceptions added during an incident and never removed.
• Findings without owners: CIEM dashboards with thousands of findings and no route to the team that owns each identity.

Metrics that show progress

Implementation roadmap

Keep a tested break-glass path while you remove standing admin. See the Break-Glass Account Guide.

Practitioner checklist

• Inventory cloud identities, keys, roles and trusts across every account, subscription and project.
• Flag admin, wildcard, escalation-capable, impersonation and cross-account permissions as privileged.
• Right-size with granted-versus-used analysis, starting with high-risk unused permissions.
• Review iam:PassRole and similar blind spots by hand.
• Move human admin roles to eligible, time-bound activation with MFA, justification and approval.
• Remove standing organisation-wide admin from pipelines; use JIT entitlements for rare tasks.
• Replace workload keys with platform identities and pin trust policies.
• Give every AI agent its own identity, read-only by default, with approval for destructive actions.
• Deploy guardrail policies and infrastructure-as-code checks to stop regression.
• Alert on IAM changes, credential creation and privileged use without activation records.
• Track the metrics above and report them by account owner.

Standards and references

• OWASP: Non-Human Identities Top 10 (2025)
• NIST: Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• Cloud Security Alliance: Cloud Controls Matrix
• Center for Internet Security: CIS Benchmarks
• MITRE ATT&CK: Cloud Matrix
• MITRE ATT&CK: T1098.003 Account Manipulation: Additional Cloud Roles
• AWS: Security best practices in IAM
• AWS: IAM Access Analyzer findings
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Google Cloud: Privileged Access Manager overview
• Google Cloud: Overview of role recommendations

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Privileged Access Management Guide · PAM Buyer's Guide · Kubernetes NHI Security Guide · Multi-Cloud Identity Guide