The organizations building defensible identity governance programs today are not running better quarterly access reviews. They are replacing periodic attestation with continuous validation informed by real usage, dependency mapping, and ownership derived from behavior. That requires a data layer that knows what every identity is doing right now, not what it was provisioned to do six months ago.
Most enterprise identity programs are not there yet. Many are still running the same review cycle they ran five years ago, against an identity estate that has fundamentally changed beneath them.
The Access Review of Yore
The access review was built to answer one question: does this person still need this access?
That question assumes identities are human, persistent, and provisioned through known workflows. A person joins the organization, accumulates entitlements over time, moves roles, and eventually leaves. The governance model maps cleanly onto that lifecycle. Review their access quarterly, certify what is appropriate, revoke what is not, and the program is defensible.
The majority of active identities in a large enterprise today are non-human. Service accounts, cloud service principals, pipeline credentials, OAuth tokens, and AI agent service principals operating on short-lived tokens that expire before the next sync runs. These identities are created dynamically, authenticate using secrets rather than passwords, and change with every deployment rather than every quarter. There is no HR record that anchors them. And ownership is frequently unclear because they were created outside any provisioning workflow.
The access review applied to these identities does not produce governance. It produces a compliance artifact.
The Questions the Access Review Cannot Answer
For a human identity, a reviewer can reason about access with organizational context. The question "does this person still need this?" is answerable.
For a non-human identity, the relevant questions are entirely different. Is this identity still in use? What depends on it? What would break if it were changed or removed? Who actually owns it, and why does it exist? What damage could it do if its credential were compromised?
None of those questions are answerable from a static access record. They require runtime context: what the identity is actually doing in production, which systems call it, how frequently it authenticates, and whether its behavior has changed. That contextual data does not live in the governance platform. It lives in noisy logs, cloud provider APIs, and service dependency maps that were never captured in any system of record.
The instinct is to point existing tools at the problem: feed more logs into the SIEM, build more dashboards, write more queries. Security teams have spent years learning that approach does not produce governance. Legacy IGA and SIEMs analyze what happened. They do not maintain a current model of what exists, who owns it, and what it should be doing. Governing non-human identities requires a platform designed for continuous discovery from the start, so that every identity is known before something goes wrong, not reconstructed from noisy logs after the fact.
A Data Infrastructure Problem, Not a Process Problem
The failure of access reviews for non-human identities is usually described as a process problem. The cadence is too slow. The certification workflow is too manual. The ownership fields are blank. These observations are accurate but they describe symptoms of a deeper structural issue.
Traditional IAM was built on a core assumption: identity context lives in authoritative source systems. HR feeds IGA. AD feeds PAM. The governance platform pulls from those systems on a scheduled batch sync and builds a picture of the estate from what those systems report.
For non-human identities, that assumption breaks down. There is no authoritative source for a service account created by an automation framework during a deployment. There is no ownership field populated for an AI agent that authenticated ephemerally and expired before the nightly sync ran. Context for these identities must be derived from runtime behavior events, not from static records. The identity exists in what it does, like which systems it calls, which resources it accesses, and whether its behavior is consistent with its stated purpose. A governance model that cannot observe behavioral events cannot govern these identities.
What Continuous Validation Requires
Replacing periodic attestation with continuous validation is a data infrastructure change, not a process redesign. It requires a complete and current picture of the identity estate: every account, every service principal, every credential, every AI agent, mapped to ownership derived from behavioral context when no explicit owner exists, and updated in real time as the estate changes.
When that foundation exists, governance stops being a quarterly scramble. Attestation becomes continuous validation against known identity events. Automation built on complete, current identity data scales with the environment, catches drift in real time, and removes the operational ceiling that manual review cycles impose on every program trying to keep pace with a modern identity estate.
The threat model changed when non-human identities became the majority of the privileged access estate. The governance model has to change with it, and that change starts with the data layer.