CIEM vs CSPM: which cloud risk to fix first

Cloud breaches usually need two things to go wrong at once, a misconfiguration that lets an attacker in and an identity with more permissions than it needs, and teams with limited budget have to decide which of those to attack first. Cloud security posture management (CSPM) finds configuration risk: public storage, open ports, disabled logging, unencrypted databases. Cloud infrastructure entitlement management (CIEM) finds entitlement risk: who and what can do what, which permissions are unused, and which identities can escalate. Both now sit inside most cloud-native application protection platforms (CNAPP), which blurs the buying decision. This guide compares the two by threat model, architecture, failure modes and controls, explains the overlap, and gives a buying and rollout sequence with a worked scenario. It is for cloud security leads, identity architects and buyers. For each category in depth, see the Cloud Security Posture Management (CSPM) Guide, the Cloud PAM and CIEM Guide and the CIEM Buyers Guide.

Key takeaways

• The short answer is settings versus permissions. CSPM asks "is this resource configured safely?"; CIEM asks "who and what can act on it, and should they?"
• CSPM is usually first for new cloud estates. Public exposure and missing logging are fast to find, easy to explain and often required by audit before anything else.
• CIEM moves first where identities dominate risk. Many accounts, heavy machine identity use, cross-account roles and multi-cloud federation make entitlement sprawl the bigger exposure.
• The categories meet in attack paths. A finding becomes urgent when a misconfiguration and an over-permissioned identity sit on the same path to sensitive data; that join is the main reason buyers consolidate into CNAPP.
• Native tools cover a lot of both. Cloud providers ship posture checks and unused-access analysis; buy a third-party product for multi-cloud coverage, correlation and workflow, not for basic checks you already have.

What each category covers

CSPM evaluates the configuration of cloud resources against policies and benchmarks. Cloud providers' native services describe the model clearly. AWS Security Hub CSPM runs security controls grouped into standards such as AWS Foundational Security Best Practices, the CIS AWS Foundations Benchmark, PCI DSS and NIST, and uses AWS Config service-linked rules for most checks, so AWS Config must be enabled and recording. Google Cloud Security Health Analytics runs detectors for misconfigurations across storage, Cloud SQL, Compute Engine, KMS, GKE and logging, mapped to the CIS Google Cloud Computing Foundations Benchmark and other standards, in batch and real-time modes. Microsoft Defender for Cloud offers Foundational CSPM, with secure score and recommendations, and the Defender CSPM plan, which adds attack path analysis, risk hunting with security explorer and agentless scanning.

CIEM analyses identities and their effective permissions. AWS IAM Access Analyzer produces unused access findings for unused roles, unused IAM user access keys and passwords, and unused service-level and action-level permissions within a configured usage window, alongside external and internal access findings. Google Cloud IAM role recommendations compare the permissions a principal holds with those it used, over a maximum observation period of 90 days, and suggest removing or replacing roles; they are never applied automatically. Microsoft Defender for Cloud includes CIEM within the Defender CSPM plan, covering Microsoft Entra ID users, groups and service principals, AWS IAM users, roles and groups, and Google Cloud users, groups and service accounts, with recommendations to right-size permissions and remove inactive accounts. Platforms are listed alphabetically; the order is not a ranking.

Availability: AWS Security Hub CSPM and IAM Access Analyzer unused access findings are charged services (AWS states a 30-day Security Hub CSPM trial and per-role, per-user pricing for unused access). Google Cloud Security Health Analytics capabilities and scan frequency depend on the Security Command Center tier. Microsoft Defender for Cloud CIEM and attack path analysis require the Defender CSPM plan.

Side-by-side comparison

Threat model: what each defends against

Configuration risk

CSPM targets the conditions that let an attacker reach a resource or that hide their activity: storage readable from the internet, databases with public endpoints, security groups open to all addresses on administrative ports, disabled audit trails, unencrypted snapshots shared publicly. Attackers find these with discovery techniques such as T1580 Cloud Infrastructure Discovery, and an exposed console or API lets them enumerate further with T1538 Cloud Service Dashboard.

Entitlement risk

CIEM targets what an attacker can do after obtaining any identity: a compromised workload role with read access to every bucket, a CI pipeline role that can attach administrator policies, a dormant access key that still works. The relevant techniques are T1078.004 Cloud Accounts for valid account abuse and T1098.003 Additional Cloud Roles for privilege escalation by granting roles. Machine identities usually dominate this surface because they are numerous, rarely reviewed and often granted broad roles to "make it work". See Cloud Entitlement Statistics.

Where they meet

The Capital One Breach 2019 is the standard illustration. A misconfigured web application firewall let an attacker obtain temporary credentials for the role it ran under, a configuration problem. That role could read far more customer storage than a firewall needs, an entitlement problem, and that is what turned an entry point into a breach of about 106 million people's data. CSPM alone might flag the firewall setting among thousands of findings; CIEM alone might flag the role among thousands of identities. The value is in seeing both on one path.

Architecture in words

CSPM: read-only connectors (cross-account roles, service principals or service accounts) pull resource configuration from cloud APIs on a schedule, and increasingly on change events. A policy engine evaluates each resource against rules, scores findings and routes them to tickets or chat. Mature deployments add preventive checks in the pipeline, scanning infrastructure as code before deployment, and guardrails such as organisation policies that block certain configurations outright. See the Infrastructure as Code Security Guide.

CIEM: connectors read identity data (users, roles, groups, policies, trust policies, permission boundaries, organisation-level controls) and activity logs such as AWS CloudTrail, Google Cloud Audit Logs or Azure activity and sign-in logs. The engine computes effective permissions by resolving inheritance and denies, compares granted with used over an observation window, models escalation and cross-account paths, and proposes right-sized policies. Activity-based analysis is why CIEM takes longer to produce trustworthy recommendations: Google Cloud, for example, by default waits for a minimum observation period before issuing role recommendations, which can be shortened at project level with possibly lower accuracy.

Inside a CNAPP: both feed a shared graph of resources, identities, network reachability and data sensitivity. Attack path analysis walks that graph to find routes from internet exposure to sensitive data, which is where combined value appears. See the CNAPP Guide.

Failure modes

Controls each category drives

• CSPM controls: organisation-wide block on public storage access, no administrative ports open to the internet, audit logging on in every account and region, encryption at rest with managed keys where required, metadata service hardening on compute (for example requiring session-based metadata access), and pipeline checks that stop misconfigurations before deployment.
• CIEM controls: remove unused roles and keys, replace broad predefined roles with narrower or custom roles, constrain trust policies on cross-account and federated roles, apply permission boundaries or organisation-level guardrails to cap what delegated admins can grant, move workloads from static keys to federated workload identity, and put human cloud admin access behind just-in-time elevation. See Least Privilege Techniques and the IAM Access Analyzer Guide.

Decision criteria: which to fix first

• Start with CSPM when: the estate is new or growing fast, there is no consistent view of public exposure or logging, an audit needs benchmark evidence, or accounts number in the tens rather than hundreds.
• Start with CIEM when: posture basics are already enforced by guardrails, identities (especially service accounts, roles and pipeline identities) outnumber people many times over, you run cross-account or multi-cloud federation, or incident history involves leaked keys or abused roles.
• Use native tools first when: you run mainly in one cloud. Native posture checks and unused-access analysis cover the essentials at lower cost; spend on remediation capacity instead.
• Buy a CNAPP or third-party pair when: you are multi-cloud, need one policy language and one queue, or need attack path correlation across configuration, identity, network and data.
• Small organisations: turn on native CSPM, enforce a handful of preventive guardrails, then run native unused-access analysis quarterly. Large organisations: run both continuously with clear ownership: platform owns configuration, identity owns entitlements, and a shared prioritisation rule decides what comes first.

Evaluation questions for each category are in the CIEM Buyers Guide and the CNAPP Buyer's Guide.

Worked scenario: one budget, two first steps

A retailer runs 120 cloud accounts across two providers. It has 600 human cloud users and about 4,000 machine identities (roles, service accounts, service principals and CI identities). It has budget for one initiative this year.

Option A, CSPM first. In two weeks native posture tools across both clouds show 38 publicly readable storage locations, logging disabled in 11 accounts and 200 security groups open to the internet on administrative ports. The team enforces organisation-level blocks on public storage and turns on logging everywhere. Exposure drops quickly and audit is satisfied. The machine identities are untouched: 900 of them still hold administrator or broad editor roles.

Option B, CIEM first. After a 90-day observation window, unused-access analysis shows most machine identities use a small fraction of their permissions, 300 roles are unused and 140 access keys have not been used in the window. Right-sizing cuts standing admin rights sharply, but public storage stays exposed for the whole quarter.

What the retailer did. Preventive CSPM guardrails first (weeks one to four), because exposure fixes were cheap and quick, then CIEM observation started in parallel on day one so the window was complete by month three. Right-sizing began with machine identities that had both write access and a path from an internet-exposed resource, identified by joining the two outputs. That sequencing is the usual answer: CSPM for fast exposure reduction, CIEM started early because it needs time to observe.

Rollout sequence

1. Connect everything read-only: onboard all accounts, subscriptions and projects at organisation level for both posture and identity data; alert on any account not enrolled.
2. Turn on audit logging everywhere: CIEM depends on activity data, and CSPM should flag any gap.
3. Start the CIEM observation window now: it costs little and saves months later.
4. Enforce a short posture baseline: public storage, administrative ports, logging, encryption. Test guardrails in audit or dry-run mode on a pilot set of accounts, then enforce; keep an exception process and a documented rollback of each guardrail.
5. Right-size machine identities by risk: those with admin or write rights on sensitive data first. Apply changes through IAM as code, keep the previous policy version for rollback, and watch for access-denied spikes for two weeks.
6. Join the outputs: rank findings that share an attack path above standalone ones, whether in a CNAPP graph or a simple join on resource and identity.
7. Shift left: add posture and IAM policy checks to pipelines so new findings stop at review.

Where identity fits

CIEM is identity security applied to cloud control planes, and the largest population it covers is non-human: workload roles, service accounts, service principals, pipeline identities and, increasingly, AI agents. Treat CIEM output as input to your NHI inventory and lifecycle, not as a separate list. Static keys found by either tool should move to federated workload identity. See the Cloud Identity and CIEM Maturity Model and the CIEM Health Check.

Detection and measurement

• Monitor: new public exposure events, logging disabled, new cross-account trusts, role or policy attachments that grant admin, use of long-dormant keys, and identities using permissions for the first time after long inactivity.
• Critical exposure mean time to remediate: for public data and open administrative access, in days.
• Account coverage: percentage of accounts, subscriptions and projects enrolled in both posture and entitlement analysis. Target 100%.
• Unused permission ratio: permissions granted but not used in the window, for machine identities, trending down.
• Standing admin count: identities with administrator-equivalent rights, split human and machine.
• Toxic combination count: attack paths where an exposed resource leads to an over-permissioned identity with access to sensitive data. Target zero open beyond the agreed fix time.

Framework mapping

Practitioner checklist

• Every account, subscription and project is enrolled in posture and entitlement analysis.
• Audit logging is on everywhere, so CIEM has activity data.
• A short preventive posture baseline is enforced by organisation-level guardrails.
• The CIEM observation window started early and covers periodic jobs.
• Machine identities are in scope, prioritised by write and admin rights.
• Right-sizing is applied through IAM as code, with rollback to the previous policy.
• Findings that share an attack path are prioritised above standalone findings.
• Configuration and entitlement owners are named, with agreed fix times.
• Native tools are used before buying overlapping third-party checks.

Standards and references

• Amazon Web Services: What is AWS Security Hub CSPM?
• Amazon Web Services: IAM Access Analyzer findings
• Google Cloud: Security Health Analytics overview
• Google Cloud: Role recommendations overview
• Microsoft Learn: Cloud security posture management in Defender for Cloud
• Microsoft Learn: Cloud infrastructure entitlement management in Defender for Cloud

Related NHI Mgmt Group resources: CNAPP Guide · Cloud PAM and CIEM Guide · CWPP vs CSPM · CSPM vs DSPM