CIEM is Where IAM is Going — And Most Teams Haven't Noticed

The IAM security model you inherited is not a security model—it is a compliance checklist disguised as architecture.

The transition from identity and access management (IAM) to cloud infrastructure entitlement management (CIEM) represents not an incremental product upgrade, but an admission that the entire premise of perimeter-based identity control has collapsed. Yet the industry is marketing CIEM as a new tool in the existing arsenal, when the real insight is far more destabilising: the shift from IAM to CIEM exposes that identity was never the control plane—it was merely a checkpoint in a control plane you did not understand. Most security teams have not noticed this distinction, and those that have are doubling down on the wrong remediation.

The Industry Narrative: CIEM as IAM's Natural Evolution

The standard story is straightforward. Traditional IAM—Okta, Azure AD, Ping, Keycloak—managed who got access to what through role-based access control (RBAC), attribute-based access control (ABAC), and federation protocols like SAML 2.0 and OAuth 2.0. It answered: Does this person have the right to this resource?

That model held in a networked perimeter world. Users logged in. Firewalls guarded the edge. Applications sat behind those firewalls. Access was human-centric and relatively stable. But the cloud—AWS, GCP, Azure—introduced a catastrophic inversion. Resources are not behind a perimeter; they are the perimeter. A developer with EC2 permissions isn't just gaining access to a server instance; they're gaining the ability to read every secret stored in a linked secrets vault, to pivot to attached S3 buckets, to enumerate IAM roles, and to alter network policies. Identity alone does not constrain what a principal can do—it only gates whether they can try.

This gap became visible through a sequence of major incidents. The Synnovis/NHS ransomware attack in June 2024 revealed how an initial compromise via a third-party software flaw (MOVEit vulnerability, patched but not on every estate) allowed lateral movement through compromised service account credentials stored in plaintext. The incident exposed not a failure of authentication, but a failure to limit what authenticated accounts could access. Similarly, the Change Healthcare breach of February 2024, traced to a compromised VPN user with overprivileged service account credentials, demonstrated that even organisations with mature IAM stacks (Change Healthcare uses Okta and Azure AD) could not prevent lateral blast radius once an identity was compromised.

The Snowflake data warehouse compromise cascade (2023-2024) further crystallised the pattern. Attackers used compromised Snowflake credentials—obtained through legitimate accounts whose users had reused passwords across personal and corporate systems—to access customer databases. The entitlement model in Snowflake is not role-based authentication (which Snowflake's IAM handled correctly); it is what that role can query and access. IAM proved a red herring. The real vulnerability was entitlement creep—roles had been granted dataset read permissions far beyond what their job function required, and no mechanism existed to detect or contain that creep in real time.

From this pattern emerged CIEM: tools by Ermetic (now Wiz), Palo Alto (Prisma Cloud), CrowdStrike (Falcon Entitlement Management, recently acquired by Wiz), and others that index cloud entitlements at scale, map them to actual job functions, and flag overprovisioned identities. The regulatory push is real. NIST CSF v1.2 (January 2024) introduced explicit language around "asset inventory and management" and "limiting access based on need to know." SEC 4-day breach notification rule (effective October 2024) now requires disclosure of material access by external threat actors, which de facto demands proof that you know what was accessible and why. The FCA's SM&CR regime and APRA's CPS 234 in the Asia-Pacific region both now expect auditable entitlement justification for financial system operators.

So vendors began shipping CIEM modules: Terraform state analysis, AWS IAM simulator correlation, Azure RBAC role inheritance mapping, GCP identity graph flattening. The narrative became: IAM authenticates; CIEM manages. Organisations bought the tools. Consultants retrained on Zscaler/Deception Technology Alliance (now merged into Okta) and Ilantus/Ermetic workflows. Aws Config rules were written to flag excessive S3 permissions. It was, ostensibly, the right direction.

The Structural Trap: CIEM Within the Legacy IAM Paradigm

But CIEM, as currently deployed, is not a security control—it is a visibility layer that strengthens the illusion of control while doing nothing to prevent the blast radius once visibility fails.

Consider the architecture. A typical CIEM deployment:

1. Ingests entitlements from cloud account APIs (AWS IAM API, Azure Graph, GCP Admin API) via read-only service accounts.
2. Maps them against job function via fuzzy matching against organisational charts, Jira tickets, or machine learning models trained on normal access patterns.
3. Flags overprovisioned identities and generates remediation recommendations: "Remove S3:* permission from role X."
4. Waits for a human remediation workflow — a ticket in ServiceNow, a change request approved by a manager, a Terraform PR code review, a 48-hour grace period.

At nearly every practitioner conference in 2024 — SecurityWeek's CyberEd, AWS re:Inforce, Gartner IAM Summit — the same truth emerged in private conversations: CIEM implementations are generating remediation backlogs of thousands of findings, with median time-to-remediation exceeding 90 days. In environments undergoing rapid infrastructure-as-code (IaC) churn (which is every modern cloud estate), by the time a human approves the removal of an excessive permission, fifteen new excessive permissions have been provisioned downstream.

Why? Because the remediation is reactive and manual. And because CIEM, like IAM before it, sits outside the data plane. It observes entitlements but does not enforce them at the point of decision. A developer provisions an EC2 instance with admin IAM role, and CIEM flags it seventeen days later. By then, the instance has already been logged into by the developer (documented), by an automated job (documented), by the attacker who stole the role credential (not documented).

The root problem is architectural. CIEM assumes that knowing what is overprovided is functionally equivalent to preventing overprovisioning. It is not. Knowledge is a prerequisite for control, not a substitute. And in a dynamic infrastructure environment where code is deployed multiple times per day—where Terraform runs against live state every few hours—the lag between observation and remediation is the actual blast radius.

Where CIEM Reveals IAM's True Failure Mode

The deeper vulnerability is not technical; it is epistemological. IAM and CIEM both assume that identity is the unit of control. That assumption is wrong.

Identity is the unit of authentication. A certificate is valid or invalid. A token is signed correctly or it is not. But identity is not the unit of data access. A user identity may have multiple job functions over its lifetime. A service identity may be bound to multiple code repositories, multiple infrastructure stacks, multiple deployment contexts. The moment you ask "Should user X have access to dataset Y?" you have already left the realm where identity answers the question. You have entered the realm of capability-based access.

The Optus 2022 breach exposed this inversion directly. Attackers compromised an AWS API key associated with a service account used by Optus's backup infrastructure. The key itself was legitimate (provisioned by Optus, not stolen from a third party). The authentication worked. What failed was entitlement justification: no one had asked, "Why does this backup process need to read every customer record across the entire Optus customer database?" By the time that question was asked, 9.8 million records had been exfiltrated.

CIEM would have flagged that service account as overprovided—perhaps on day two or day eight, depending on deployment maturity. The attacker already had what they came for. CIEM would have been a very expensive forensics assistant.

Architectural Reorientation: The PULSE Reading

The structural failure mode that CIEM exposes is this: in a cloud environment, control must be encoded into the infrastructure itself, not enforced through a discovery and remediation loop. This requires a complete inversion of the model.

Instead of:

• Authenticate identity → Grant role → Grant role permissions → Observe entitlements → Recommend removal → Wait for approval → Remediate

The architecture must be:

• Define the control as code — every entitlement flows from explicit, versioned infrastructure-as-policy (not infrastructure-as-code, but policy-as-code with machine-readable justification).
• Make the default zero — assume no principal has any entitlement. Require affirmative grant with expiration, audit trail, and technical justification.
• Bind entitlements to context, not identity — access rights are not properties of the identity; they are properties of the transaction. Does this user, running this code, at this time, from this network context, accessing this specific resource instance, still satisfy the original grant justification? If the answer changes, the transaction is denied in-line, not logged for later review.
• Separate the control plane from the data plane — entitlement rules live in the control plane (versioned, auditable, immutable); the data plane receives only the minimal capability required for the specific transaction.
• Implement adaptive posture — the entitlement rules themselves drift continuously based on observed access patterns and threat intelligence. If a service account begins making queries it has never made before, the capability is not denied (that would break legitimate operational continuity); instead, the access is redirected through a higher-friction path: a secondary authentication gate, a transaction-specific cryptographic proof, or a real-time human assertion.

This is what PULSE calls a zero-knowledge substrate: the infrastructure itself never holds the complete entitlement graph in any single place. Each component knows only what it needs to execute its function. An S3 bucket does not know why a principal is accessing it; it knows only that the principal has presented a valid, time-bound, context-specific capability token that was issued by the control plane and has not been revoked.

Implementing the Architectural Shift

In practice, this means:

At the control plane: Entitlements are defined in a domain-specific policy language (not Terraform, not JSON IAM policies, but a language that can express temporal, contextual, and capability-based constraints). Every grant includes:

• Principal class (human user, service account, temporary role)
• Resource class and instance (S3 bucket name, not S3:*)
• Action class (read, write, delete — mapped to the data plane, not the IAM API)
• Justification (Jira ticket, business process, security exception approval)
• Expiration (absolute, or revocable by the issuer)
• Context constraints (only from this CIDR range, only during 09:00–17:00 UTC, only when this flag is set)

At the data plane: The resource itself (S3 bucket, RDS instance, secrets vault) validates the capability token before executing the operation. The token is cryptographically signed by the control plane, includes context headers (timestamp, requestor network, intermediate service identity), and can be revoked at any point in the chain without re-authentication.

In between: A capability broker (distinct from the IAM service) issues short-lived, context-aware capability tokens on request. The broker verifies that the requestor's current context still satisfies the original grant justification. If context has drifted—the user is now in a different department, the service account is being invoked from a different network, the code artifact invoking it has changed—the broker either denies the request, escalates it for real-time assertion, or issues a token with reduced scope.

This architecture has a profound side effect: compliance becomes structural, not procedural. An auditor does not ask, "What is the remediation backlog?" They ask, "Show me the control plane." The control plane is immutable, versioned, and self-documenting. Every entitlement grant is justified, time-bound, and revocable. Every denial is logged with the reason (context violation, expired grant, revoked justification). The entire access control system is deterministic and auditable at cryptographic granularity.

Why This Matters Now

DORA (Digital Operational Resilience Act) in the EU, NIS2 and its transposition into national law, NYDFS Part 500 (Cybersecurity Requirements for Financial Services Companies) in New York, and similar frameworks globally now all contain language around "controls commensurate with risk" and "management of critical third-party service dependencies." These regulations increasingly demand not just documentation of access, but proof of justified access — that every active entitlement was necessary, and that unnecessary entitlements were actively revoked.

The old IAM + CIEM stack cannot provide that proof at scale. A CIEM tool can tell you that a role is overprovided. It cannot prove that the role is overprovided, tell you when it became overprovided, or guarantee that a newly deployed service won't be overprovided from day one.

The organisations that will survive the next decade of regulation and breach risk are those that are now building the capability-based, context-aware, control-plane/data-plane separation that CIEM implicitly admits is necessary.

---

Qualified organisations undertaking architectural re-evaluation of identity and entitlement systems are invited to request a PULSE briefing under executed Mutual NDA.