CIEM vs IGA: who owns cloud entitlements and how to join them up

Cloud permissions usually fall between two teams: the identity governance team certifies who has access, and the cloud security team sees what that access can actually do, and neither owns the gap. Identity Governance and Administration (IGA) answers "should this person or account hold this entitlement, and who approved it?". Cloud Infrastructure Entitlement Management (CIEM) answers "what can this identity do across the cloud estate, and which of those permissions has it actually used?". This guide is about the ownership decision between the two: who governs cloud entitlements, why certification and least privilege right sizing are different jobs, and how to wire the tools together so findings turn into removals. It is written for IAM leads, cloud security architects and audit owners. For category basics see the CIEM Buyers Guide and IAM and IGA Basics.

Key takeaways

• They answer different questions. IGA governs the grant (request, approval, certification, removal at leave); CIEM measures the effective permission and its use, then recommends a smaller one.
• Certification does not shrink a role. A reviewer can approve or revoke an assignment, but cannot sensibly judge which of 4,000 actions inside a cloud role are needed. Right sizing needs usage data, which is CIEM territory.
• Split ownership by layer, not by tool. IGA owns who holds which cloud role or group and the evidence trail; the cloud platform team owns what each role contains, driven by CIEM findings; the security team owns the risk thresholds.
• Machine identities break the IGA model first. Cloud service accounts, roles and federated workloads have no manager, no HR record and often no catalogue entry, so CIEM inventory usually has to feed IGA ownership rather than the other way round.
• Integration is the deliverable. CIEM findings should land as IGA review items or tickets with a named owner and a due date, and IGA leaver events should trigger CIEM checks for orphaned cloud access.

The short answer

Choose IGA as the system of record for who is entitled: people and accounts, their cloud role and group assignments, approvals, periodic certification and joiner, mover and leaver automation. Choose CIEM as the system of insight for what the entitlement allows and uses: effective permissions after policy evaluation, unused services and actions, toxic combinations, privilege escalation paths and cross account trust. Most organisations with a material cloud footprint need both, because the two failure modes are different. An IGA programme alone produces clean certification evidence for roles that are still far larger than the job. A CIEM tool alone produces long lists of unused permissions with no owner who is allowed to remove them.

The choice is rarely "one or the other". The real decisions are which team owns the cloud permission layer, which tool is authoritative for which attribute, and in which order to buy or build. The PAM vs IGA vs NHI Management guide covers the wider identity operating model; this page stays on cloud entitlements.

Side-by-side comparison

Certification versus least privilege right sizing

These two activities are often merged under "access review", and that is the root of most failed cloud governance programmes.

Certification asks a human to attest that an assignment is still appropriate. NIST SP 800-53 AC-2 (Account Management) and AC-6(7) (Review of User Privileges) describe this control, and NIST CSF 2.0 PR.AA-05 requires that access permissions are defined, managed, enforced and reviewed. Microsoft Entra access reviews show the shape of the control: reviews can target group membership, enterprise application assignments, access package assignments and, through Privileged Identity Management, Microsoft Entra roles and Azure resource roles, with weekly, monthly, quarterly or annual recurrence. The reviewer decides on the assignment as a whole.

Right sizing changes what the assignment contains, using evidence of use. The cloud providers expose that evidence natively:

• AWS: IAM last accessed information shows which services an identity's policies allow and when they were last used. AWS states the tracking period for service information is at least 400 days, and action level data covers management actions only, not data plane events. The IAM Access Analyzer unused access analyzer continuously monitors IAM roles and users and reports unused roles, unused access keys and passwords, and unused services and actions. See the IAM Access Analyzer Guide.
• Google Cloud: the IAM recommender compares granted permissions with used permissions over up to 90 days and proposes REMOVE_ROLE, REPLACE_ROLE or REPLACE_ROLE_CUSTOMIZABLE recommendations. Google states the recommender never applies recommendations automatically and considers only IAM allow policies, not ACLs or Kubernetes RBAC.
• Microsoft Azure: Microsoft Entra Permissions Management offered cross cloud CIEM with a Permission Creep Index and removal of permissions unused for 90 days. Microsoft announced it would stop selling the product on 1 April 2025 and retire it on 1 November 2025, so Azure estates now rely on native role assignment data, PIM and third party CIEM for this layer.

A reviewer shown "role: PowerUserAccess, last used 3 days ago" will approve it every time, and is right to: the person does use the role. The question that matters, whether 95 percent of the actions in it are idle, is not one a business reviewer can answer. That is why right sizing belongs with engineers who own the role definitions, fed by CIEM data, while certification stays with managers and resource owners. See How to Write Least-Privilege IAM Policies From Access Activity for the policy engineering side.

Who should own what: the ownership split

Ownership works when each layer of a cloud entitlement has exactly one accountable team.

Three rules keep this split stable. First, IGA never edits policy content; it grants and removes assignments to roles that the platform team defines. Second, CIEM never silently removes access in production; its output is a change request against the role definition or an assignment, with the owner taking the decision. Third, every machine identity CIEM discovers must get a human owner recorded in the governance system within a set number of days, or it is disabled. The Entitlement Catalogue Guide covers catalogue design.

Threat model, architecture and failure modes for each option

IGA governing cloud access

Threat model: stops access that outlives its purpose: leavers who keep cloud console access, movers who accumulate roles, contractors past their end date, and access granted without approval. It is weak against a correctly approved assignment to an oversized role and against attackers who add credentials or roles directly in the cloud (ATT&CK T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles), because those changes bypass the IGA workflow.

Architecture in words: the HR system drives joiner, mover and leaver events into IGA; IGA provisions users into the cloud identity layer (for example AWS IAM Identity Center, a Microsoft Entra group bound to an Azure role, or a Google group bound to a project role) through SCIM or connectors; cloud roles are modelled as entitlements in the catalogue with an owner and a description reviewers understand; campaigns certify those entitlements.

Failure modes: direct assignments made in the cloud console that IGA never sees; cloud roles catalogued with names reviewers cannot interpret; service accounts excluded because they have no manager; rubber stamp approvals on roles that are used but oversized.

CIEM governing cloud access

Threat model: reduces the blast radius of any compromised cloud identity (T1078.004 Cloud Accounts) by removing permissions that are not used, and flags privilege escalation paths such as an identity that can attach policies to itself or pass a privileged role to a new compute resource. The Capital One breach is the reference case: a firewall's cloud role could list and read S3 buckets of customer data that its function never needed. Usage based right sizing would have flagged that data access as excessive for a network appliance.

Architecture in words: read only roles in every account, subscription and project let the CIEM collect identities, policies, resource policies and activity; it computes effective permissions, compares them with use over an observation window, scores risk and generates findings or least privilege policy suggestions.

Failure modes: findings with no owner; recommendations based on too short a window that miss quarterly or annual jobs; removals that break disaster recovery or year end processes; human users analysed in the cloud but never tied back to their HR identity, so leavers still look like active cloud principals.

Decision guidance

Small organisations usually have one team owning both layers; the split still matters, but as two steps in one process. Large organisations need the written ownership table above, a shared risk threshold, and an integration contract between the IGA and cloud teams. If the plan is to buy one platform that claims both capabilities, the IGA vs ISPM comparison explains where posture tools fit.

How to integrate CIEM and IGA

1. Agree the ownership table. Sign off the layer by layer split, including who may change role content and who may remove assignments.
2. Unify identity keys. Map cloud principals to directory identities (federated user names, Identity Center user IDs, Entra object IDs) so CIEM findings resolve to a person or a machine identity owner.
3. Feed machine identities into governance. Export CIEM's inventory of roles and service accounts into IGA or the NHI inventory with an owner attribute; set a deadline for unowned identities. See the NHI lifecycle automation guide.
4. Pilot right sizing in report only mode. Pick two accounts or projects, use an observation window that covers at least one full business cycle (the Google recommender uses up to 90 days; AWS service level data reaches back at least 400 days), and review suggested policies with workload owners.
5. Route findings to owners. Send high risk CIEM findings (unused admin rights, public or cross account access, escalation paths) to IGA as targeted micro certifications or to the ticketing system with a due date.
6. Close the loop on leavers. Trigger a CIEM check on every IGA leaver event to catch cloud access that sits outside IGA, such as access keys or directly attached policies.
7. Change role content through code. Apply right sizing as pull requests to the policy repository so changes are reviewed and reversible; keep the previous policy version to roll back if a job fails.
8. Scale and enforce. Move to enforcement account by account, add preventive guardrails (service control policies, organisation policies, Azure Policy) for the patterns you keep removing, and retire manual exceptions.

Worked scenario: a retailer with three clouds

A retailer runs 140 AWS accounts, 30 Azure subscriptions and a Google Cloud data platform. Its IGA suite certifies Entra groups quarterly and audit is satisfied. A CIEM pilot shows that most human users in the AWS developer permission sets use a small fraction of the services granted, and that 600 IAM roles and Google service accounts have no owner in any system.

Under the agreed split, the IAM team keeps certifying group membership but adds the permission set name and a plain English description to each catalogue entry. The platform team takes the CIEM output, builds three smaller developer permission sets from observed use and ships them through infrastructure as code, keeping the old set for 30 days as a rollback path. Cloud security sends the 600 unowned machine identities to account owners with 30 days to claim them; unclaimed identities with no activity in the observation window are disabled, then deleted after a further holding period. Within two quarters, certification items drop because roles are smaller and fewer, and every remaining machine identity has an owner who receives its review.

Detection and measurement

• Permission gap: granted versus used permissions per identity, trended monthly, split by human and machine identities.
• Ownership coverage: percentage of cloud machine identities with a named owner in the governance system.
• Finding closure time: median days from a high risk CIEM finding to removal or approved exception.
• Out of band grants: count of cloud role assignments and access keys created outside IGA, from CloudTrail, Azure Activity Log and Cloud Audit Logs.
• Leaver residue: cloud principals still active for identities IGA has deprovisioned.
• Revocation rate in certification: a very low rate on cloud roles over several campaigns suggests rubber stamping or roles too coarse for reviewers to judge.

Alert on new role assignments and access keys created directly in the cloud, policy attachments that grant administrative actions, and trust policy changes that add external principals. The Access Reviews vs Continuous Access Monitoring guide covers the monitoring model.

Common failure patterns

• Certifying oversized roles: reviewers approve used roles because use is real, and the excess inside each role is never addressed.
• CIEM with no removal authority: the security team generates findings but cannot change role content, so the backlog grows each month.
• Short observation windows: right sizing on 30 days of data removes permissions needed for quarter end, recovery tests or annual jobs.
• Machine identities left out of both: IGA excludes them for lack of a manager, CIEM lists them without an owner, and nobody revokes them.
• Two inventories that disagree: IGA and CIEM report different identity counts with no reconciliation, so audit questions which one is true.
• Relying on a retired product: estates that built CIEM processes on Microsoft Entra Permissions Management need a replacement for that layer.

Framework mapping

Practitioner checklist

• Write a layer by layer ownership table for cloud entitlements and get IAM, platform and security leads to sign it.
• Model every cloud role, permission set and group that grants cloud access as a catalogued entitlement with an owner and a plain description.
• Turn on native analysers (IAM Access Analyzer unused access, the Google IAM recommender) before buying anything, and use their output as a baseline.
• Map every cloud principal to a directory identity or a named machine identity owner.
• Right size role content through infrastructure as code with a rollback version, never by hand in production.
• Route high risk CIEM findings to owners as targeted reviews or tickets with due dates.
• Trigger cloud access checks on every leaver and mover event.
• Track permission gap, ownership coverage and finding closure time, and report them alongside certification completion.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• AWS: What is IAM Access Analyzer?
• AWS: Refine permissions using last accessed information
• Google Cloud: Role recommendations overview
• Microsoft Learn: What are access reviews?
• Microsoft Learn: What's Microsoft Entra Permissions Management?

Related NHI Mgmt Group resources: CIEM Buyers Guide · Cloud IGA vs On-Premises IGA · PAM vs IGA vs NHI Management · Cloud PAM and CIEM Guide · CIEM vs CSPM