CIEM: the over-permissioned identity problem
Permissions are granted in a hurry to unblock a deploy, and then never revisited. They accumulate for years.
Cloud Infrastructure Entitlement Management (CIEM) is the practice of analysing what every human and machine identity in your cloud accounts is allowed to do. It looks for permissions that are granted but never used, policies that are far too broad, and combinations of permissions that let an identity become something more powerful.
In an environment where the network boundary is soft and every action is an authenticated API call, identity is the boundary that matters most. A role with the wrong policy is an open door, whatever the security groups say.
How permissions drift
Almost nobody sets out to over-permission an identity. It happens in a recognisable sequence:
- A deployment fails with an access-denied error at 6pm.
- Someone widens the policy until it works, often to a wildcard, because narrowing it precisely takes an hour nobody has right then.
- The deploy succeeds. The ticket closes.
- Nothing ever narrows it again. Narrowing it risks breaking something that currently works, and no one is certain what it still needs.
Repeat that across a few dozen services and a few years. The account ends up with a permission surface far larger than anything actually in use.
The four things CIEM looks for
- UNUSED PERMISSIONS
- Actions an identity is allowed to take but has not taken in any observed window. This is the gap between granted and needed, and it is usually the largest single category.
- WILDCARD AND BROAD POLICIES
Action: "*"onResource: "*"is the extreme case. Grants across a whole service are the common one: full access to a storage service when the workload reads two specific prefixes.- ESCALATION PATHS
- Permissions that are unremarkable alone and combine into privilege escalation. The ability to attach a policy to a role, or to pass a role to a new compute resource, effectively grants whatever that role holds.
- STALE PRINCIPALS
- Access keys not rotated in years, roles left behind by a decommissioned service, human accounts belonging to people who have moved on. Nobody is watching these, which is exactly what makes them attractive.
Why escalation paths are the interesting part
The first two categories are findable with a policy linter. The third is not, because no single permission looks wrong.
Take an identity that can create a compute instance and can pass an existing role to it. Neither permission is unusual for a deployment pipeline. Together, they mean the identity can launch an instance carrying any role in the account it can name and inherit that role's access. Its effective permissions are the union of everything it can pass, which may include the administrative role nobody intended it to touch.
Finding that means evaluating identities as a graph of who can become whom. It is the same structure that makes attack path analysis work. Identity hops are usually the longest ones in a real attack path, because they cross boundaries the network never would.
What CIEM does not do
CIEM is analysis. It tells you where access is excessive. Several adjacent jobs belong to other tools.
- It does not log people in. Authentication, MFA and single sign-on are your identity provider's job. CIEM reads the result.
- It does not usually change policies for you. Most products recommend a narrower policy. Applying it, and owning the outage if a quarterly job breaks, stays with your team.
- It cannot see usage it was never shown. "Unused" means unused in the logs the tool could read. A job that runs once a year looks idle for eleven months.
- It does not end a live session. Cutting off an attacker who already holds a token is incident response, often with help from privileged access tooling.
- It often stops at the account edge. Trust that lets an outside identity into the account, such as an OIDC provider for CI or a vendor's cross-account role, is frequently out of scope. We cover that gap in who can walk into your AWS account from outside.
CIEM vs IAM vs PAM
The three names sound interchangeable. They are not, and most organisations need all three.
| Aspect | CIEM | IAM | PAM |
|---|---|---|---|
| Full name | Cloud Infrastructure Entitlement Management | Identity and Access Management | Privileged Access Management |
| Main job | Find excessive and risky permissions across cloud accounts | Define identities and grant them permissions | Control and record human use of privileged accounts |
| Covers machine identities | Yes, roles and service accounts are most of what it reads | Yes, it is where they are created | Mostly no, it is built around people |
| Typical output | "This role has used 12 of its 400 permissions" | A policy, a role, a group membership | A vaulted credential, a recorded session, a time-limited grant |
| When it acts | On each scan, informed by access logs | Every time a request is authorised | Every time a person checks out privileged access |
| Examples | Entitlement modules in CNAPP products | AWS IAM, Microsoft Entra ID, Google Cloud IAM | Credential vaults and just-in-time access tools |
Common misconceptions
"Least privilege is a one-time project." Permissions drift back within months unless something keeps measuring them.
"Admins are the risk." Admin roles are watched. The risk is usually the CI role nobody remembers that can pass any role in the account.
"Managed policies are safe because AWS wrote them." Managed policies are written for convenience across many customers. PowerUserAccess is managed, and it is enormous.
"CIEM only matters for big estates." A single account with one over-broad pipeline role is enough for a full compromise.
Acting on it without breaking production
Over-permissioning persists because people fear the revert. A sequence that works:
- Start with unused, not with broad. Removing an action the identity has never invoked carries far less risk than reshaping a policy that is in daily use.
- Cut escalation edges before trimming leaves. Removing one permission that passes roles can shrink an identity's effective reach more than a hundred individual action removals.
- Prioritise by what the identity can reach. An over-permissioned role in a sandbox is untidy. The same role in an account holding customer data is the real problem. Blast radius is the measure for this.
- Watch, then narrow. Observe real usage over a window long enough to include the monthly and quarterly jobs. Those are what break when a policy is narrowed on a week of data.
Vendors package CIEM very differently, from a standalone product to one tab in a larger platform. The Prisma Cloud comparison is a useful reference for how a large suite handles it.
FAQ
What does CIEM stand for?
Cloud Infrastructure Entitlement Management. It is the analysis of which permissions human and machine identities hold across cloud accounts, and which of those permissions are unused or risky.
Is CIEM part of CSPM?
They overlap. Many CSPM rule packs flag obvious identity problems such as a wildcard policy. CIEM goes further by comparing granted permissions with real usage and by following chains where one identity can become another.
How does CIEM know which permissions are unused?
It reads access logs, such as AWS CloudTrail or last-accessed data, and compares the actions an identity actually called with the actions it is allowed to call. The result is only as good as the time window the logs cover.
What is the most dangerous kind of over-permission?
Usually not a large policy but an escalation path, for example iam:PassRole on all roles combined with the ability to launch compute. It lets a modest identity become any role in the account.
Does CIEM cover Kubernetes service accounts?
Some products do and many do not. Kubernetes RBAC and cloud IAM are separate systems, and the link between them (a pod identity that maps to a cloud role) is a common blind spot.
Secorvia includes CIEM on its Growth and Enterprise plans, reading the same graph as its attack paths.