IAM Security
IAM Security is the identity posture engine. Where CIEM analyzes entitlements — what identities can do vs what they use — IAM Security audits the configuration hygiene of the identities themselves: MFA enrollment, access key age, password policy, root account usage, wildcard admin policies, and identities nobody has touched in months. The result is a risk-scored view of every identity in every connected cloud.
This page covers what the engine checks, how findings are classified into six IAM security modules, and how to read the identity risk table in the console.
What IAM Security covers
The engine classifies identity-relevant findings from every posture scan into six modules. Each module gets its own summary, its own pass rate, and its own contribution to the overall IAM posture score.
| Module | What it checks | Example findings |
|---|---|---|
| Least privilege | Over-permission, wildcard grants, privilege escalation | wildcard_admin policies, full-admin roles |
| Policy analysis | IAM policy structure and versioning | Inline policies, missing policy conditions |
| MFA | Multi-factor enforcement | MFA not enabled, no hardware MFA for root |
| Role management | Role trust and session settings | Overly broad trust principals, long max session duration |
| Password policy | Account password strength and rotation | Minimum length too short, passwords never expire |
| Access control | Console access, root usage, key rotation | Root account activity, access keys older than 90 days |
Coverage spans all 7 clouds. On AWS that means IAM users, roles, and policies; on Azure it includes Entra ID, service principals, managed identities, RBAC assignments, and PIM configuration; on GCP it includes service accounts, workload identity, and organization policies; equivalents apply for OCI, Alibaba Cloud, IBM Cloud, and Kubernetes RBAC.
How it works
IAM Security runs after the posture scan, as a classification and enrichment pass over the findings corpus:
- Read. The engine loads the scan's findings from the shared findings store.
- Classify. Each finding's
rule_idis matched against 15 identity patterns —.iam.,.mfa,.password,.root,.sso, plus Azure-specific patterns (.entraid.,.rbac.,.pim.,.serviceprincipal.,.managedidentity.) and GCP-specific ones (.serviceaccount.,.workloadidentity.,.orgpolicy.). - Enrich. Identity-relevant findings are tagged with the IAM modules they belong to.
- Report. The engine assembles an IAM report: per-module summaries, per-identity rollups, and a tenant-wide IAM posture score.
Because it reuses the full rule registry rather than a separate rule set, IAM Security stays automatically in sync with rule updates — a new Entra ID rule in the registry is an IAM Security finding on the next scan with zero configuration.
The identity risk table
The console presents identities the way an analyst triages them — one row per identity, risk-scored and sortable:
| Identity | Type | Cloud | Risk score | MFA | Oldest key | Open findings |
|---|---|---|---|---|---|---|
| ci-deploy-user | IAM user | AWS | 94 | No | 412 days | 7 |
| svc-backup | Service principal | Azure | 81 | — | 180 days | 5 |
| admin@corp | Entra ID user | Azure | 76 | No | — | 4 |
| etl-runner@prod | Service account | GCP | 58 | — | 97 days | 3 |
| dev-alice | IAM user | AWS | 22 | Yes | 30 days | 1 |
The risk score (0–100) weights each identity's open findings by severity, privilege level, and exposure — an admin without MFA outranks a read-only user without MFA, and an internet-reachable service identity outranks an internal one. Clicking a row opens the identity's findings, its policies, and its activity summary.
Common findings
| Finding | Severity | Why it matters |
|---|---|---|
| Root account access key exists | Critical | Root credentials should never exist as long-lived keys |
| Privileged user without MFA | Critical | One phished password away from admin |
| Console user without MFA | High | Single-factor interactive access |
Wildcard admin policy (iam:* on all resources) | High | Worst-case scope on the most-abused permissions |
| Access key not rotated in 90 days | Medium | Stale credentials accumulate exposure |
| Identity inactive 90+ days | Medium | Unused identities are unmonitored attack surface |
| Weak password policy | Medium | Short or non-expiring passwords weaken every account |
Each finding carries remediation steps, MITRE ATT&CK mapping, and the compliance controls it affects — MFA and key-rotation checks map directly to CIS IAM sections, NIST 800-53 AC/IA families, PCI-DSS requirement 8, and SOC 2 CC6.
Fixing the IAM Security layer first makes every other engine's numbers better. MFA enforcement and key rotation are the cheapest risk reduction in cloud security — most tenants can clear their Critical identity findings in a single afternoon.
IAM Security vs CIEM
The two engines are complementary and share the same identity inventory:
| IAM Security | CIEM | |
|---|---|---|
| Question answered | Is this identity configured safely? | Does this identity have more permission than it uses? |
| Data analyzed | Identity configuration (MFA, keys, policies, trust) | Effective permissions vs 90 days of usage history |
| Typical finding | User without MFA, key not rotated | Gap score 87, shadow admin path, unused entitlements |
| Output | Risk-scored identity table, module posture scores | Least-privilege policy suggestions, escalation chains |
Start with IAM Security to fix hygiene, then use CIEM to shrink entitlements toward least privilege.
Next steps
- CIEM — entitlement analysis and least-privilege remediation
- CSPM — the rule registry that feeds IAM Security's classification
- Attack Path Analysis — how identity weaknesses chain with network and data exposure
- Book a demo — see your identity risk table live