CIEM — Cloud Identity & Entitlement Management

CIEM analyzes every identity in your cloud — human users, service accounts, IAM roles, federated logins, machine identities — and answers two hard questions: what can each identity actually do? and what does each identity actually need? The gap between those two answers is your excess permission risk. The platform measures it, prioritizes it, and gives you a least-privilege policy you can apply with confidence.

Why CIEM matters: the average cloud identity has been granted 80% more permissions than it ever uses. Most cloud breaches now start with a compromised low-privilege identity that is then escalated through unused permissions to admin. CIEM is the discipline of closing that gap — and it is the only practical way to enforce least privilege at cloud scale, because no human team can review a million entitlements by hand.

The identity risk problem

Modern cloud environments accumulate identities and permissions faster than security teams can review them. Every new microservice creates a new IAM role; every new SaaS integration creates a new federation; every new developer creates a new user. Permissions get added when needed but rarely removed when no longer used.

The industry baseline figure: 80% of granted permissions are never used. This is not a flaw in your design — it is a structural property of cloud IAM. Permissions are granted defensively, workloads change, and nobody goes back to clean up. CIEM is what brings that 80% back down.

Coverage: rules and identity types

CIEM rule packs

On top of the shared posture rule registry, CIEM ships its own dedicated entitlement rule packs per cloud — 1,342 CIEM-specific rules in total:

These cover entitlement-specific conditions — wildcard grants, escalation-capable permission combinations, risky trust policies, unused entitlements — that plain configuration rules cannot express.

Supported identity types

A "—" does not always mean unsupported in principle — some providers implement the identity type through a different mechanism that the platform covers under a different row.

How CIEM works

CIEM is a three-stage pipeline that runs against every identity on every scan: collect the raw IAM configuration and usage data, analyze what is actually callable vs what is actually used, and emit prioritized findings with suggested fixes.

1. Collect — what the platform reads from your cloud

Every CIEM scan reads three classes of data through your read-only credential. No agents, no policy changes, no IAM modifications.

• IAM policies — every identity-based policy, every resource-based policy (S3 bucket policies, KMS key policies, Lambda permissions), every Service Control Policy at the org level, every permission boundary, every trust relationship.
• Usage history — the last 90 days of CloudTrail (AWS), Azure Monitor activity logs, Cloud Audit Logs (GCP), or equivalent. The platform reads which identity called which API on which resource.
• Identity catalog — every user, group, role, service account, workload identity, federated identity, and cross-account trust. Federation chains and identity center mappings are followed end-to-end.

2. Analyze — what the platform calculates per identity

• Effective permissions — the resolved intersection of all policy sources. This is what the identity can actually call — different from what is attached on paper.
• Used permissions — what the identity actually called in the last 90 days.
• Unused permissions — granted but never exercised. These are the candidates for safe removal.
• Identity attack paths — multi-hop chains of sts:AssumeRole and iam:PassRole that lead from this identity to a role with privilege-escalation permissions.

3. Findings — what you see in the console

The output is severity-ranked findings, not raw data: overprivileged identities with a 0–100 gap score and a generated least-privilege policy, shadow admins, stale access, and cross-account risks.

Effective permissions — what an identity can actually do

Cloud IAM permissions do not come from a single source — on AWS they come from five overlapping policy types that interact through a precise resolution algorithm. The platform computes the resolved set for every identity automatically.

The resolution rule in plain English: an action is allowed only if there is an explicit Allow somewhere AND no explicit Deny anywhere. Explicit Deny always wins. SCPs and permission boundaries can never grant — they can only restrict.

Why this matters: "what's attached" can be wildly different from "what's actually callable". A role might appear to have s3:* in its identity policy, but a permission boundary caps it to s3:GetObject. The platform shows you the truly callable set — that is the basis for the gap score and the suggested least-privilege policy. Manual reviews of "what's attached" miss this every time.

Cross-cloud coverage: the same effective-permission resolution runs for Azure RBAC (role assignments, scope inheritance, deny assignments), GCP IAM (allow policies, deny policies, organization policies), OCI IAM (compartment hierarchy, policy statements), and the others. The mechanism varies; the goal is the same.

Least Privilege Gap Score

Each identity receives a single Least Privilege Gap Score from 0 to 100 — a direct measure of how much excess permission the identity carries. Higher is worse.

Gap Score = (unused_permissions / total_permissions) × severity_weight × exposure_weight

• unused_permissions / total_permissions is the basic ratio of granted permissions never exercised.
• severity_weight is higher for write/admin permissions than for read — deleting S3 buckets weighs more than listing them.
• exposure_weight is higher for identities reachable from the internet than for purely internal identities.

Why this is not a simple percentage: an identity with 80% of its s3:GetObject-only permissions unused is materially different from an identity with 80% of its iam:* permissions unused. The weighting captures that.

Identity attack paths

CIEM does not stop at single-identity analysis. It traces multi-hop permission chains — paths an attacker could follow to escalate from a low-privileged starting identity all the way to full admin. Most real-world cloud breaches use chains exactly like the one below; almost none are visible from any single identity in isolation.

How the platform finds these chains:

1. Enumerates every reachable role from each identity — following sts:AssumeRole and iam:PassRole edges in the security graph.
2. Tags every permission that enables self-escalation — iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PutRolePolicy, iam:CreateAccessKey, iam:UpdateAssumeRolePolicy, plus equivalents in Azure, GCP, and OCI.
3. Flags any chain that ends in one of those permissions, regardless of hop count.
4. Shows which control would have prevented it — usually a permission boundary on the intermediate role, or removing an unused iam:PassRole.

Common chains the platform catches: Lambda to admin via PassRole, EC2 instance role to iam:CreatePolicyVersion, cross-account trust into a weaker account, federated SSO roles with iam:UpdateAssumeRolePolicy, and GKE service accounts mapping to GCP service accounts with iam.serviceAccountKeys.create. Each finding is mapped to MITRE T1098.001 (Additional Cloud Credentials) and T1078.004 (Valid Accounts: Cloud Accounts). These chains also feed the platform-wide Attack Path graph as identity edges.

Findings and remediation

Key CIEM findings

The ten most-encountered CIEM findings across customer environments:

Every finding includes the affected identity, the specific policy or trust at fault, the suggested fix, and the framework controls it satisfies (CIS IAM controls, NIST AC family, ISO 27001 A.5.15/A.5.18, SOC 2 CC6.1).

Remediation workflow

CIEM findings come with a generated least-privilege policy ready to apply — not just a flag. The platform synthesizes the policy from what the identity actually used in the last 90 days and never modifies your IAM without your explicit approval.

1. Detected. A finding fires on the next scan — for example "role data-pipeline-role has gap score 87/100, 12 unused services". Severity, MITRE technique, and framework citations are attached.
2. Review. The console shows a side-by-side diff of effective vs used permissions over the last 90 days, down to specific actions and resources.
3. Suggested policy. The platform generates a least-privilege policy in JSON, scoped exactly to what was actually used. You can adjust it — expand a wildcard if seasonal usage was missed, or add a deny for a sensitive action.
4. Apply. You decide how — copy to the cloud console, hand off to your IaC pipeline (Terraform or CloudFormation), or trigger an approved automation hook. The platform never auto-applies.
5. Verify. The next scan re-evaluates the identity. The gap score should drop and the finding auto-closes. If it did not improve, the platform tells you why — for example, "policy was applied but a permission boundary still allows the wildcard".

Why we never auto-apply: least-privilege errors break production. Removing a permission used only during quarterly batch jobs can cause an outage the 90-day window never saw. You get the suggested policy with full context; you make the call.

Bulk remediation is supported — review and apply a batch of suggested policies through your CI/CD pipeline with a single approval. Every approval is recorded in the audit log. Suggested policies export as Terraform aws_iam_policy blocks, CloudFormation snippets, or raw JSON; CIEM findings export as CSV.

API

CIEM endpoints are part of the unified platform API under the /api/v1/iam-security prefix. All endpoints require an authenticated session and are scoped to your tenant.

# List CIEM findings
GET /api/v1/iam-security/findings?severity=HIGH&status=OPEN

# Effective permissions for one identity
GET /api/v1/iam-security/identity/{identity_id}/permissions

# Attack paths originating from one identity
GET /api/v1/iam-security/identity/{identity_id}/attack-paths

# Suggested least-privilege policy for one identity
GET /api/v1/iam-security/identity/{identity_id}/suggested-policy

Full request/response schemas are in the API Reference. Webhook delivery on new High/Critical CIEM findings is configured under Settings, then Notifications.

FAQ

How long does CIEM analysis take per account? A typical AWS account with 200 identities and 90 days of CloudTrail history completes the CIEM stage in under 90 seconds. Larger accounts (1,000+ identities) take 3–5 minutes.

Does CIEM modify any IAM in my account? No. The platform reads IAM configuration and usage data and generates suggested policies. Applying them is always your action.

What if I don't have 90 days of audit history? The platform uses whatever history is available and notes the lookback window on every finding. With under 30 days, gap scores are more conservative.

Can I customize what counts as an escalation permission? Yes. Extend the default set with org-specific permissions under Settings, then CIEM, then Escalation Definitions.

Does CIEM cover AWS Identity Center (formerly SSO)? Yes. Permission sets, federated user assignments, and the resulting per-account roles are all enumerated; SAML and OIDC federations are followed end-to-end.

Next steps

• IAM Security — configuration posture of identities (MFA, key rotation, policy hygiene)
• Attack Path Analysis — identity chains combined with network and data exposure
• CDR — detect when an identity starts behaving abnormally
• Book a demo — see your own entitlement gap measured live