Your Identity Governance Is Lying to You

There's a specific kind of compliance theater that anyone who's worked in enterprise security will recognize. It's quarterly access review season. A manager opens their inbox, sees 400 certification tasks due by Friday, and starts clicking "Approve" — not because they've reviewed anything, but because the deadline is real and the access list is incomprehensible. By Friday afternoon, the IGA platform shows 100% completion. The audit passes.

Nothing about that process made the environment more secure. But it generated artifacts that look like governance.

This is the foundational failure of how most organizations handle Identity Governance and Administration today. The tooling was designed for a different era — on-prem applications, predictable org structures, IT teams that controlled the full provisioning lifecycle. That world is gone. What replaced it is a mesh of SaaS applications, cloud-native services, contractor identities, service accounts, CI/CD pipelines, and increasingly AI agents — all accumulating entitlements faster than any static governance model can track or reason about.

The gap between what legacy IGA platforms were built to handle and what modern environments actually look like is not a product gap. It is an architectural one. And closing it requires rethinking governance from first principles, not upgrading software.

The Role Explosion Nobody Designed For

Role-based access control (RBAC) made sense when you had a dozen applications and a manageable org chart. The model is intuitive: define roles, assign users, and enforce access through role membership. Clean in theory.

Then reality happened.

The deeper issue isn't that engineers make bad role decisions — most of the time, they make reasonable ones given the information they have. The problem is structural: the incentive architecture of most IGA programs rewards provisioning speed over governance hygiene. Approving a cloned role takes ten minutes. Refactoring a broken one takes a project plan, a stakeholder sign-off, a change window, and someone willing to own the regression risk. Over five years, the math resolves predictably — thousands of roles, most of them wrong in some dimension, almost none of them with a current, accountable owner.

This is not a failure of RBAC as a concept. It is a failure of applying a static model to a system that never stops moving. Every re-org, every SaaS contract renewal, every architectural shift toward microservices changes the underlying access landscape — and the role catalog almost never keeps pace.

In distributed, service-oriented architectures, the model breaks further. Service identities, short-lived workload credentials, scoped tokens for CI/CD pipelines — none of this maps onto traditional role management. Most IGA platforms were architected to govern a human employee's access to an enterprise application. They were not designed to govern a Kubernetes service account, a GitHub Actions runner, or an LLM agent operating on delegated authority.

Multi-cloud compounds the problem. AWS IAM, Azure RBAC, and GCP IAM each express permission models differently. Layered with Okta, Snowflake, Salesforce, and GitHub, the entitlement surface becomes effectively ungovernable through manual processes alone. Shadow access multiplies. Audit coverage degrades. The risk is real, but invisible in most governance dashboards.

What Genuine Modernization Requires

The industry has a habit of rebranding old problems with new terminology. "Zero Trust" and "shift left" are now so overloaded as to be nearly meaningless in vendor conversations. So it's worth being specific about what structural changes actually matter.

Moving from role assignment to policy evaluation. Policy-based access control (PBAC) expresses access as intent rather than membership. Consider a policy like: "A third-party auditor engaged for the Q3 close may read general ledger entries for their assigned business unit, from a corporate-managed device, between 8 AM and 6 PM in their local timezone — and that access expires automatically at engagement end." Every component of that policy is live and dynamic. The same identity, presenting at 2 AM from an unmanaged endpoint flagged by EDR, gets a different answer — or gets challenged to re-establish assurance before proceeding. The access decision tracks the risk context, not just the initial provisioning record.

Moving from batch processing to event-driven governance. A nightly deprovisioning job is a 24-hour attack window. When an employee is terminated in an HR system, that event should immediately propagate: IAM revokes SSO sessions, IGA revokes entitlements across connected applications, PAM closes open privileged sessions. Governance that operates on a schedule is governance that accepts known lag as a design parameter. That is no longer defensible.

Moving from perimeter trust to continuous evaluation. A session established under clean conditions can become high-risk mid-flight — the device gets compromised, the user's risk score spikes, geolocation changes. Identity assurance is not a property of authentication. It is a property of the ongoing session. Systems need to re-evaluate continuously, not just at the front door.

These are not enhancements to legacy IGA. They represent a different model of what governance is — one that treats identity as a live, context-bearing signal rather than a static record.

Where AI Contributes Meaningfully — and Where Vendors Oversell It

AI capabilities in IGA are real and, in specific applications, genuinely transformative. They are also consistently oversold. The distinction matters because implementations built on inflated expectations tend to fail quietly and expensively.

Role mining is one of the most defensible applications. Unsupervised clustering algorithms applied to entitlement data can surface natural access groupings — cohorts of users who share the same permissions across the same applications, regardless of whether a formal role has ever been defined for them. This capability turns role rationalization from a multi-year consulting engagement into a data analysis problem. It doesn't eliminate human judgment in role design, but it provides an analytically grounded starting point. SailPoint's AI Services and Saviynt's analytics layer both do this with reasonable reliability when the underlying data is clean.

Peer-group provisioning recommendations are a high-ROI, low-risk entry point. Rather than provisioners manually determining what a new engineer on the payments team needs, the system can identify that 90% of similar engineers hold a specific set of entitlements and recommend accordingly. Access request volume drops. Time-to-productivity shortens. The provisioning decision is traceable and defensible because it is grounded in observed organizational norms rather than individual judgment.

Anomaly detection is where AI starts to behave like a genuine security control, not just an operational efficiency tool. Behavioral baselines built on access telemetry can surface patterns that signature-based rules miss entirely. A deployment pipeline with read-only access to a secrets manager suddenly attempts a write operation at 3 AM with no associated CI job. A senior engineer with standard developer permissions begins querying the entitlement management API — a tool they have never touched — two weeks after being passed over for a promotion. A privileged identity authenticates from a jurisdiction it has no established history in, during a regional holiday. None of these patterns match known attack signatures. All of them represent meaningful deviation from an established behavioral baseline, which is a fundamentally different detection model than rule-matching. These signals, routed to a SIEM or directly into a policy engine, create the possibility of automated, real-time response rather than retrospective forensics.

Automated certifications represent the most significant reduction in governance overhead. When an ML model can determine with high confidence that a given entitlement is low-risk, stable, and consistent with peer access patterns, it should be auto-certified without human review. What remains in the certification queue should be genuinely anomalous: the administrative rights acquired with no associated ticket, the cross-department data access that predates the current ownership model. Human attention is a scarce resource. Governance systems should allocate it accordingly.

The prerequisite for all of this is data quality. ML models trained on inaccurate, incomplete, or inconsistently structured entitlement data will produce confident, wrong recommendations. Role rationalization and orphaned account remediation are unglamorous prerequisites. They are also non-negotiable.

Identity Fabric: An Architectural Pattern Worth Taking Seriously

"Identity fabric" has been absorbed into vendor marketing to the point of near-meaninglessness. The underlying architectural concept, however, is sound and worth articulating precisely.

An identity fabric is a connected governance layer in which IAM, IGA, PAM, and CIAM systems share context, risk signals, and entitlement state through common APIs and an event infrastructure, behaving as a coherent system rather than isolated functional silos.

The operational difference is material. When a privileged session in a PAM platform exhibits anomalous behavior, an event fires. The IGA platform receives that event and updates the associated identity's risk profile. The next authentication attempt through the IdP triggers step-up verification — automatically, without a human in the loop, in seconds rather than hours. When a user is terminated in HR, the termination event cascades: SSO is revoked, entitlements are suspended, privileged access is closed.

Without this fabric, each system makes decisions in isolation using stale information. With it, the security posture of the entire environment can respond to a single signal. That is not a theoretical benefit. It is the architectural difference between detecting a compromise in real time and discovering it in a log review three weeks later.

Identity Fabrication: The Governance Problem AI Is Creating

Most IGA discourse focuses on how AI can improve governance. Less discussed — and more urgent — is how AI is actively undermining the identity signals that governance systems depend on.

Synthetic identity fraud has been a known problem in financial services for years: AI-constructed personas with plausible documentation used to pass KYC checks or open fraudulent accounts. The same capability is now relevant to enterprise identity environments. Deepfake technology has matured to the point where biometric authentication factors — facial recognition, voice verification — can be spoofed with accessible tools. More subtly, AI can be used to construct realistic behavioral patterns designed to evade anomaly detection or to manipulate the contextual signals that PBAC policies evaluate.

This threat has no complete solution today. But it has a defensible mitigation architecture: corroborate signals rather than trusting any single factor; require hardware-rooted attestation (FIDO2, TPM-backed device certificates) for high-assurance decisions, since these are significantly harder to fabricate than software-layer signals; apply passive liveness detection to biometric factors; and design policies that require multiple independent, high-assurance signals for privileged access decisions.

The deeper point is this: as AI lowers the cost of constructing convincing false identity contexts, governance systems that were built to trust well-formed inputs become structurally vulnerable. Adversarial robustness is becoming a design requirement for identity governance — not just a threat modeling exercise.

Shared Signals: The Infrastructure Layer Governance Has Been Missing

The OpenID Foundation's Shared Signals Framework (SSF), along with the Continuous Access Evaluation Protocol (CAEP), represents a meaningful maturation in how security systems can share risk intelligence.

The premise is straightforward: security decisions should be informed by signals from across the entire environment, not just from the system making the decision. An endpoint detection platform identifies device compromise. An HR system records a termination. A UEBA platform flags anomalous data access. These are identity-relevant events. They should be consumable by every system with a governance stake in the affected identity — immediately, not at the next sync cycle.

The sequence matters less than what it replaces. In the conventional model, a compromised device generates a helpdesk ticket on Monday morning. The ticket gets escalated on Tuesday. Someone acts on Wednesday, while the session that was established under now-invalid conditions has remained fully active for 60 hours. CAEP doesn't just compress that timeline. It eliminates the human handoff entirely. Risk signal and access revocation become a single automated event with no workflow step in between.

For engineers building on this stack, the implementation question is not whether to adopt SSF, but whether the systems you already operate are instrumented to emit and consume compliant events. Okta, Microsoft Entra, and SailPoint have all introduced varying degrees of CAE support. An IGA platform that cannot participate in shared signal exchange is a governance system making decisions with yesterday's information. In the current threat environment, that is not an acceptable design.

Implementation: Where to Actually Start

A few things that are genuinely worth doing, roughly in order of practicality:

Remediate data before introducing intelligence. Audit orphaned accounts, consolidate or retire redundant roles, and validate that application connectors are reporting entitlements accurately. This is the work that precedes everything else. ML models trained on incomplete data will confidently encode your existing governance failures into automated decisions.

Choose a single, measurable AI use case first. Peer-group provisioning recommendations offer a visible impact, low implementation risk, and a before/after comparison that is straightforward to present to stakeholders. Build the operational case before expanding the scope.

Build event infrastructure as a foundation. Instrumenting existing systems to publish identity events — terminations from Workday, session events from Okta, risk signals from endpoint platforms — to a shared event bus (Kafka, Azure Event Grid, AWS EventBridge) is not glamorous work. It is the architectural prerequisite for everything else: real-time governance, shared signals, automated response.

Treat identity policy as code. Access policies should live in version control, be subject to peer review, and have automated validation. If your IGA configuration exists only inside the platform UI and in institutional memory, you have a governance fragility that will surface at the worst possible time — during an incident, or during an audit.

Design for explainability from the start. Before any AI recommendation is acted upon automatically, there should be an immutable, human-readable log of what the model recommended, on what basis, and what action was taken. Regulators increasingly require this. So does sound engineering.

The State of the Field — and Where It's Heading

Identity governance is in the middle of a structural transition. The compliance-oriented, batch-processed, human-certified model that characterized IGA for the past two decades is being replaced — not because vendors built better products, but because the environments being governed have changed so fundamentally that the old model can no longer produce meaningful security outcomes.

What is emerging is a model of identity governance that is continuous, context-aware, event-driven, and increasingly augmented by machine intelligence. It treats every entitlement as a live relationship between an identity and a resource — one that should be evaluated continuously against the current risk context, not certified annually against a static role model.

The organizations that will govern identity effectively in this environment are not necessarily the ones with the largest IGA budgets. They are the ones that have invested in clean data, connected their systems architecturally, and started building the event-driven reflexes that turn governance from a quarterly ritual into a real-time capability.

The tools are ready. The standards are mature. The remaining variable is organizational commitment to treating identity governance as engineering, not as compliance paperwork with a technology layer on top.