CIEM in 2026: Fixing the Cloud Entitlement Explosion

Q: What is CIEM (Cloud Infrastructure Entitlement Management)?

CIEM is the discipline and product category that continuously manages who and what can do which actions on which resources across cloud environments. It does three things a raw policy listing cannot. First, it computes effective permissions: for each human or workload identity it evaluates every applicable layer — identity policies, resource policies, service control policies, permission boundaries, group inheritance and transitive role-assumption chains — to determine what the identity can actually do, which routinely differs from what any single attached policy suggests. Second, it baselines real usage from audit logs such as CloudTrail over a trailing window, typically 90 days. Third, it drives remediation of the gap between granted and used: quarantining inactive identities, generating right-sized least-privilege policies from observed activity, and moving occasional-use privileges behind just-in-time elevation. The reason the category exists is scale: Microsoft research tracked more than 40,000 distinct permissions across AWS, Azure and GCP, with identities exercising roughly 1% of what they hold. No quarterly human review process can govern that space; CIEM turns entitlement hygiene into a continuous, automated loop rather than a periodic certification exercise.

Q: Why did Microsoft retire Entra Permissions Management, and what does it mean for CIEM?

Microsoft stopped new sales of Entra Permissions Management on April 1, 2025 and retired the product fully on November 1, 2025, folding selected CIEM capabilities into Microsoft Defender for Cloud and partnering with Delinea for customers who needed a dedicated replacement. The retirement of a hyperscaler-backed standalone CIEM product is widely read as the end of CIEM as an independent product category — but not of CIEM as a capability, which is more necessary than ever. What actually happened is consolidation: entitlement management is becoming a module inside platforms that already observe your cloud, chiefly cloud-native application protection platforms (CNAPPs) like Wiz, Palo Alto Cortex Cloud and Defender for Cloud itself, and identity-governance platforms like SailPoint, Delinea and Saviynt. For buyers the practical consequence is that the 2026 decision is no longer which specialist CIEM tool to purchase, but which platform that already has visibility into your environment should own entitlements — and whether the gaps in your cloud provider’s native tooling (AWS IAM Access Analyzer, Google Cloud role recommendations, Azure access reviews) actually justify buying anything at all before you have operationalised what is free.

Q: What are effective permissions, and why are they different from attached policies?

Effective permissions are what an identity can actually do after every applicable policy layer is evaluated together — as opposed to what any individual attached policy says. In AWS, a single principal’s effective access is the result of combining identity-based policies, resource-based policies on the targets, permission boundaries, service control policies at the organisation level, and session policies, with explicit denies overriding allows. Crucially, the analysis must also be transitive: if a principal can call sts:AssumeRole into another role, it effectively holds that role’s permissions too, and role chains can pass through several hops before reaching something admin-equivalent. This is why scoring identities by their directly attached policies systematically understates risk — a developer role that looks harmless on paper may sit two assumptions away from an administrator role. An entitlement graph makes this computable: identities, roles, policies and resources become nodes, grants and assumption edges connect them, and questions like “which identities have any path to IAM mutation on production” become graph traversals. Native single-cloud tools compute parts of this; the differentiating value of dedicated CIEM tooling is doing it continuously, transitively, and across multiple clouds with correlated identities.

Q: How much of their granted cloud permissions do identities actually use?

Around 1%, according to Microsoft’s State of Cloud Permissions Risks research, which analysed permission usage across AWS, Azure and Google Cloud. The same research found that more than half of identities were “super identities” with access to effectively all permissions and resources, that super identities used less than 2% of what they held, that roughly 80% of workload identities were completely inactive, and that of the more than 40,000 permissions tracked across the three clouds, over half were classified as high-risk — capable of causing catastrophic damage if misused. The granted-versus-used gap matters because every unused permission is pure downside: it contributes nothing to productivity, but it is fully available to an attacker the moment the identity’s credential is phished, stolen by an infostealer, or leaked from CI. The practical takeaway is that most organisations can remove enormous amounts of standing risk without impacting a single workflow, because the permissions being removed were never exercised. The reason it does not happen is not disagreement about the risk — it is that without usage evidence, nobody can prove a given grant is safe to remove, so the rational move for every individual engineer is to leave it. Usage baselining is what breaks that deadlock.

Q: Are the native cloud tools (IAM Access Analyzer, GCP role recommendations) enough, or do I need a CIEM product?

For a single-cloud organisation with hundreds rather than thousands of identities, the native tools are genuinely enough to capture most of the value, and they are free or nearly so with the platform. AWS IAM Access Analyzer produces findings for unused roles, unused permissions, unused access keys and unused passwords against a configurable tracking window, and can generate a least-privilege policy directly from CloudTrail activity for you to review and ship. Google Cloud’s role recommendations apply machine learning over 90 days of permission usage and suggest concrete revocations and role downgrades per principal. What the native tools do not do is correlate identities across clouds and your IdP, score entitlement risk against workload exposure (is this over-permissioned identity also on an internet-reachable path?), provide certification workflows auditors accept, or push remediation beyond recommendations. Those are the gaps CIEM modules inside CNAPPs and identity platforms fill, and they start to justify their cost when you run two or more clouds, when workload identities number in the thousands, or when compliance requires evidence of periodic access certification. The honest sequencing: operationalise the native findings first — if those findings sit unactioned, a purchased dashboard will change nothing.

Q: How do you remove excess permissions without breaking production?

Run it as a staged loop ordered by risk, with reversibility built into each stage. Stage one removes the provably dead: identities, roles and access keys with zero recorded activity over the tracking window. Even here, quarantine before deletion — attach a deny-all policy or disable the credential, wait a full business cycle including month-end and quarter-end batch jobs, and delete only when nothing screams. This is what saves you from the yearly billing reconciliation job that runs once in January. Stage two right-sizes the living: identities that are active but use a small fraction of their grants get replacement policies generated from their actual usage history, shipped through the same pipeline as any other infrastructure change — pull request, review, staged rollout, fast rollback. Automation drafts the policy; a human reviews the diff, which typically takes minutes instead of the hours a from-scratch least-privilege policy costs. Stage three converts what remains: privileges that are genuinely needed occasionally, like production database access or break-glass admin, move behind just-in-time elevation with automatic expiry, so standing privilege trends toward zero. The loop then repeats continuously, because entitlements regrow with every deadline — least privilege is a process property, not an achievable end state.

Q: Why are non-human and workload identities the biggest part of the entitlement problem?

Because they outnumber humans by an order of magnitude, they are provisioned programmatically at deadline speed, and they are structurally invisible to the traditional access-review process — a service account never responds to a quarterly certification email, and its owner often left the company two reorgs ago. Microsoft’s research found roughly 80% of workload identities completely inactive, a figure that had doubled over two years, and 40% of super-admin identities were workload identities rather than people. The dynamics are worse than for humans: a CI runner granted broad rights to unblock one release keeps them forever; a service account created for a proof of concept outlives the project; a Lambda role accumulates policies with every feature. And the population is now growing again as AI agents join CI runners and microservices as autonomous credential holders — each one an identity whose permissions were guessed at creation and never revisited. A CIEM programme that starts with employee access is starting with the minority of the problem. The workable pattern for non-humans is aggressive: inventory with named owners, usage baselining from day one, automatic quarantine on inactivity, short-lived credentials over static keys, and capability-scoped tokens for agents rather than broad role inheritance.

Q: What is the difference between CIEM and IGA or access reviews?

Identity governance and administration (IGA) manages the lifecycle and certification of identities — joiner-mover-leaver flows, role assignment, periodic access reviews, segregation-of-duties checks — and it grew up in the world of enterprise applications, where an identity might hold dozens of entitlements. CIEM addresses the cloud-infrastructure layer, where the permission space is four to five orders of magnitude larger and mostly held by non-human identities: more than 40,000 distinct actions across the major clouds, composed through policies, inheritance, boundaries and role chains into effective permissions no human reviewer can evaluate by inspection. Access reviews illustrate the difference sharply. In an IGA context a manager certifying that their report still needs access to twelve applications is plausible; in a cloud context, asking a manager to certify three thousand permission grants produces rubber-stamping at roughly the cost of $60,000 per quarterly cycle for a 3,000-identity estate at fifteen minutes and $80 of engineer time per identity — and no risk reduction. The mature posture treats them as layers: CIEM’s automated granted-versus-used loop is the actual control that shrinks entitlements, while IGA-style reviews consume CIEM’s evidence as certification artefacts for auditors. Buying either one and expecting it to do the other’s job is a common and expensive category error.

Satyam Kumar

ブログに戻る

security

Your Cloud Has 40,000 Effective Permissions. CIEM and the Entitlement Explosion

By Satyam KumarAugust 11, 202611 min read

ciem cloud entitlements least privilege iam access analyzer effective permissions cloud security entra permissions management cnapp workload identity just-in-time access permission sprawl identity security gcp role recommendations non-human identity blast radius 2026

Your Cloud Has 40,000 Effective Permissions. CIEM and the Entitlement Explosion

Frequently Asked Questions

この記事を共有する

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI＆クラウドアーキテクト。数百万人にスケールするシステム構築を支援。

LinkedIn GitHub

Your Cloud Has 40,000 Effective Permissions. CIEM and the Entitlement Explosion

Frequently Asked Questions

この記事を共有する

Comments

Leave a comment