Most engineers think…
Most people assume cloud IAM is 'just roles and policies — read the JSON and you know the access'. That works for a single flat AWS account with three roles. It does not work for a 200-account AWS Organisation with SCPs, permission boundaries, resource-based policies, role chaining and ABAC tags all interacting at the same time.
Wiz CIEM solves a different, harder problem: it computes the effective permission set — what an identity can actually do after every policy layer is resolved — then flags where that effective access is excessive, unused or exposes a cross-account or external trust boundary. That is the answer interviewers want when they ask about cloud identity risk.
① The CIEM problem — assigned vs effective permissions and permission sprawl
In a cloud environment an identity rarely has a single attached policy. A developer in AWS might hold a role with an inline policy, an AWS-managed policy, an SCP from the organisation root, a permission boundary and resource-based policies on the S3 buckets they touch. The effective permission set is the intersection of all those layers — not the union. Wiz CIEM resolves that intersection automatically, across every account and every identity.
The scale of the problem is striking: research consistently shows that over 95% of cloud identities use fewer than 5% of the permissions they hold. That unused 95% is open blast radius — a compromised credential can pivot far beyond what the operator intended. Blast radius is why CIEM matters even in organisations with mature IAM practices.
Wiz ingests policy data from AWS, Azure and GCP without agents and builds a graph of every identity, every permission layer and every resource. Security teams can query: which identities can delete production S3 buckets? or who has write access to this secret? — and get the real answer, not the paper answer.
In any cloud security interview, always distinguish effective permissions (what an identity can actually do after all policy layers resolve) from assigned permissions (what policies are attached). Wiz CIEM is valuable precisely because it computes the former, which no manual review can do reliably at scale.
What does 'effective permissions' mean in a Wiz CIEM context?
② The identity attack surface — every identity Wiz maps
Wiz CIEM maps a wider set of identities than most teams track manually. Human IAM users (active and stale), service accounts and workload identities (EC2 instance profiles, Lambda execution roles, GCP service accounts, Azure managed identities), federated identities from external IdPs (Okta, Azure AD, GitHub Actions OIDC), cross-account roles that allow one account to assume permissions in another, and external principals — third-party vendor roles and AWS partner accounts — are all surfaced in a single graph.
For each identity Wiz surfaces its effective permissions, its last-used timestamp, and any identity misconfiguration signals: no MFA on a privileged user, no activity in 90 days, wildcard resource on a write action, admin or sensitive-data access with no justification. These signals feed directly into the Wiz Security Graph and can appear on attack paths.
Why federated and workload identities are the hardest
Human users get reviewed in quarterly access reviews. CI/CD roles and GitHub Actions OIDC tokens are created by developers, often with wide permissions, and rarely reviewed. Wiz surfaces these with the same effective-permission analysis so the security team can right-size workload identities alongside human ones.
What an identity can actually do after all policy layers (SCPs, permission boundaries, inline, managed, resource-based) are resolved — the real blast radius, not the paper one.
The gap between permissions granted and permissions used. Research shows 95%+ of cloud identities use under 5% of granted permissions — the unused 95% is open attack surface.
A role in one AWS account that trusts a principal in another account to assume it. Dangerous when the trust policy uses wildcards or has no external-ID or MFA condition.
Non-human identities that power code: EC2 instance profiles, Lambda execution roles, GCP service accounts, Azure managed identities, GitHub Actions OIDC tokens. Often over-privileged and rarely reviewed.
Most access reviews focus on human accounts. In a cloud environment, CI/CD roles, Lambda execution roles, and GitHub Actions OIDC tokens often hold broader permissions than any human user — and are almost never in the quarterly review cycle. Always map workload identities alongside human ones.
Which of these identity types does Wiz CIEM include in the attack surface map?
③ The least privilege engine — activity analysis and right-sizing
Wiz analyses cloud-provider activity logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) to determine which actions an identity has actually used over a configurable lookback window (commonly 90 days). It then computes the delta: granted permissions minus used permissions = excess. From that delta, Wiz auto-generates a least privilege policy that retains only what was used.
Right-sizing is not a one-click deploy. Wiz surfaces the generated policy for review; the security or platform team validates edge cases (quarterly batch jobs that run outside the observation window, break-glass scenarios), then exports the policy to AWS IAM, Azure RBAC or GCP IAM. The workflow keeps humans in the loop while eliminating the manual guesswork that makes most least-privilege projects stall.
Beyond right-sizing, Wiz also detects privilege escalation paths — an identity that cannot do something directly but can assume a role or modify a policy to grant itself that ability. These lateral and escalation risks are surfaced as findings with remediation steps, not just raw policy diffs.
Priya at a Pune fintech faces this
An AWS Lambda function used for payment-status checks is flagged by Wiz with a critical finding: it holds an IAM policy with s3:* and dynamodb:* on all resources, but activity logs show it has only ever called dynamodb:GetItem on one table.
A developer copy-pasted a broad policy template during a hackathon sprint and it was never reviewed. The Lambda role has been in production for eight months with massive unused permissions.
Wiz CIEM shows effective permissions vs used permissions: granted includes s3:DeleteBucket on *, used is only dynamodb:GetItem on one table ARN. Blast radius if the function is compromised is the entire S3 estate and DynamoDB.
Wiz ▸ CIEM ▸ Identities ▸ Lambda role ▸ Effective permissions ▸ Usage analysisAccept Wiz auto-generated least privilege policy: allow dynamodb:GetItem on the specific table ARN only. Remove s3:* and dynamodb:* entirely. Export the new policy to AWS IAM and re-deploy.
Re-check in Wiz: the Lambda role now shows effective permissions matching its actual usage — finding resolves. Run a DynamoDB GetItem in staging to confirm the function still works.
▶ Watch Wiz detect and remediate a wildcard permission on a CI/CD role
Step through how a GitHub Actions role with s3:* gets detected, scoped and fixed. Press Play for the detection path, then Break it to see what happens without CIEM.
A Lambda function has been assigned an S3 full-access policy but only ever calls s3:GetObject. What should Wiz recommend?
④ Cross-account & external identity risk — trust boundaries and detection
Multi-account architectures are the norm in AWS Organizations and GCP folders. Cross-account roles let one account assume a role in another — powerful for automation, dangerous when the trust policy is too permissive. Wiz maps every cross-account trust relationship and flags cases where the trusted principal is an overly broad account ID, a wildcard (*), or a third-party account with no MFA condition.
External identity risk is the next category: vendor or partner roles that federate into your cloud from outside your organisation. Wiz surfaces these external principals in the same graph, showing what they can do inside your environment, whether their access has been used recently, and whether any conditions (IP, MFA, external ID) constrain the trust. A vendor role with admin permissions and no external-ID condition is a critical finding.
Detection signals Wiz raises
- Cross-account role with no external-ID condition (third-party access risk)
- Resource policy with a wildcard principal (
*) on a sensitive resource - External identity with permissions unused for over 90 days
- Role that can be assumed from outside the organisation boundary
- Federated identity with admin rights and no MFA requirement
A cross-account or external-vendor finding is not closed by disabling the role — verify the trust policy conditions. Wiz shows whether an external-ID, MFA or IP condition is present. If none exist, any principal that knows the role ARN can assume it. Fix is to add conditions to the trust document, not just deactivate the role.
A third-party vendor role can assume a role in your AWS production account with no external-ID condition and no MFA. What risk does Wiz flag?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the difference between assigned permissions and effective permissions, and why does it matter for cloud security? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Effective permissions
- The actual access an identity holds after every policy layer — SCPs, permission boundaries, inline, managed and resource-based policies — is resolved and intersected.
- CIEM
- Cloud Infrastructure Entitlement Management — the discipline of discovering, analysing and right-sizing cloud identity permissions across multi-cloud environments.
- Permission sprawl
- The accumulated gap between permissions granted and permissions used across an organisation's cloud identities — each unused permission is potential blast radius.
- Least privilege policy
- A policy scoped to only the actions and resources an identity has actually used, derived from activity-log analysis rather than guesswork.
- Cross-account role
- An IAM role in one AWS account whose trust policy allows a principal in another account to assume it — powerful for automation, risky if the trust is too permissive.
- Confused deputy
- An attack where a malicious actor tricks a trusted third party into using its privileged cross-account role on the attacker's behalf — prevented by an external-ID condition on the trust policy.
- Workload identity
- Non-human identities that power code: EC2 instance profiles, Lambda execution roles, GCP service accounts, Azure managed identities and CI/CD OIDC tokens.
- Blast radius
- The set of resources and actions an attacker can reach if a given cloud identity is compromised — determined by effective permissions, not assigned ones.
📚 Sources
- Wiz — Cloud Infrastructure Entitlement Management (CIEM) solution page. wiz.io/solutions/ciem
- Wiz Academy — What Is CIEM? Use Cases, Challenges and Benefits. wiz.io/academy/cloud-security/cloud-infrastructure-entitlement-management-ciem
- Wiz Academy — Cloud Entitlement Management: How To Reduce Identity Risk. wiz.io/academy/cloud-security/cloud-entitlement-management
- Wiz Academy — CIEM vs. IAM: How Do They Compare?. wiz.io/academy/cloud-security/ciem-vs-iam
- Wiz Blog — CIEM and Secure Cloud Access: Best Practices from Wiz and CyberArk. wiz.io/blog/best-practices-from-wiz-and-cyberark
- AWS — AWS IAM policy evaluation logic — effective permissions resolution. docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
What's next?
Understood entitlements? Next, go deep on Wiz Attack Paths — how the graph engine chains identity risks with misconfigurations and exposed secrets to find the routes an attacker would actually take to your crown jewels.