Consider the last time someone on your team changed roles, joined a temporary project, or created a new cloud resource. What happened to their access? Not what was supposed to happen, but what actually took place. If this made you pause, you’re not alone.
In most organizations, access is granted correctly when needed, and that’s where the attention usually stops. The issue is not with the granting process; it’s what happens afterward during the lifecycle. Old access rights linger, previous repositories remain accessible, temporary project permissions are often not revoked, and machine identities created for single-use workflows persist long after those workflows have ended. Nothing appears to break immediately; no alerts are triggered, and no policy violations show up on dashboards. Instead, risk accumulates slowly as operational changes occur daily. This is known as identity drift.
The challenge is that modern environments evolve faster than traditional identity models can effectively manage. Cloud infrastructure can be deployed dynamically, AI agents may appear and disappear within hours, and DevOps workflows constantly generate new identities and permissions. Static identity reviews cannot keep pace with these rapid changes.
In this post, we will explore what identity drift is, what the gradual divergence of a user’s access from their intended secure state looks like in practice, why traditional identity models struggle in constantly changing environments, how adaptive identity offers a more continuous, context-aware approach to access governance, and how we can start implementing these concepts in our own environments.
A practical example of identity drift
Consider a developer who joins the Services team and is granted the appropriate access for their role, including permissions for repositories, databases, infrastructure, and internal tools. A few months later, they are promoted to Product Engineering and receive additional permissions related to their new responsibilities. The provisioning process functions correctly, and the new access is granted. But what happens to the old access?
In many environments, the previous access is not explicitly revoked. The developer can still access earlier repositories, old infrastructure credentials remain active, and legacy project permissions persist because no technical failures occur and no alerts are triggered. A few months later, this developer starts working on a cloud-native application and is granted even more access: cloud environments, new SaaS tools, deployment credentials, and a new GitHub organization.
Each individual change may seem reasonable. However, over time, the developer’s identity becomes a collection of outdated responsibilities rather than a true reflection of their current role. This scenario illustrates identity drift in practice and static versus real-time decisioning.
Why traditional identity models struggle in modern environments
Before discussing what needs to evolve, it’s important to establish the fundamentals. Traditional identity governance is not broken; it is essential, and organizations like SailPoint have spent years refining it.
This model operates in three phases: assignment, storage, and review, and is based on six core concepts:
-
Identity Data Sources: Authoritative records, such as HR systems or directories, that serve as the source of truth for user identities.
-
Accounts: Individual logins used.
-
Correlation: The process of linking those accounts back to a unified identity.
-
Entitlements: Specific permissions granted to users.
-
Access Profiles: Policies that determine what is granted or denied.
-
Roles: Collections of entitlements and access profiles tied to job functions.
This model provides auditable, defensible compliance with standards such as SOX and GDPR. It works exceptionally well in stable environments where organizational changes occur predictably. The key phrase here is “stable and predictable,” but as we introduced, this is not the modern environment. Developers can quickly create AI agents, give them access to sensitive production data for short tasks, and decommission them before anyone conducting a quarterly review even realizes they existed. When this scenario plays across an entire organization, it exposes the limits of traditional identity governance in fast-paced settings.
This leads to a growing disconnect between the pace of environmental change and the pace at which identity systems can adapt. This manifests in several ways:
-
Between review cycles: there is a gap between when a role changes and when access is revoked.
-
During team transitions: when an employee moves to a different team, their old access often remains unchanged.
-
In machine identities: these identities may be created for specific tasks but are never explicitly removed afterward.
-
In ephemeral resources: some resources are intended to be temporary but end up being used permanently.
The issue isn’t that traditional identity governance is obsolete; rather, modern operational environments evolve constantly, while many identity processes still follow static timelines. While the static model remains essential and serves as a foundation, it must be paired with a system that operates continuously rather than calendar time.
Identity as a continuously evolving system
Given this widening gap, addressing identity drift means treating identity as a continuously evolving system rather than a static snapshot, one where access is re-evaluated as context changes, not just at the next review cycle. Adaptive identity is a dynamic, risk-aware approach that adjusts access based on real-time context. Instead of waiting for the next review cycle to surface issues, it continuously evaluates whether a user’s access still makes sense given who they are, what they’re doing, and what’s changing around them.
There are four key pillars to understand:
-
Context-driven: access decisions incorporate real-time signals, such as team changes, role shifts, and usage patterns, rather than relying solely on historical data.
-
Continuous feedback: instead of relying on periodic checkpoints, entitlements are continuously reassessed.
-
Risk-aware: anomalies and misalignments are identified before they become incidents.
-
Augments existing foundations: certifications, compliance reports, and entitlement reviews remain important. Adaptive identity fills in the gaps between these processes.
The beauty of this approach is that it doesn’t reinvent the wheel. The same foundational elements (data sources, accounts, correlation, entitlements, roles, and access decisions) are still in place. What changes is their behavior over time: updates trigger immediate re-evaluation instead of sitting dormant, and entitlements are continuously reassessed rather than assumed valid until the next review. For example, when a developer moves to Product Engineering, the adaptive model treats that HR update as a signal to reassess whether their current access still makes sense, rather than waiting for the next review cycle to catch the leftover Services team access.
What this means for developers
At its core, adaptive identity is programmable, and it’s here that we, as developers, play a crucial role. It’s not a black box that you simply turn on; rather, it consists of a set of building blocks that you can assemble to suit your environment. SailPoint offers several capabilities that make this approach practical:
-
SDKs for custom connectors and event triggers: these allow identity to respond to changes from any system within your ecosystem.
-
APIs for real-time access decisions: this ensures that policy is not confined to quarterly reviews and can support immediate needs.
-
SailPoint Agentic Fabric: SailPoint Agentic Fabric provides comprehensive visibility, governance, and real-time response to the agentic workforce, designed for managing non-human and agent accounts, including workloads, scripts, and AI agents that traditional identity models were never intended to accommodate.
-
Just-in-Time (JIT) provisioning: this approach is particularly relevant to managing identity drift. It grants access only when necessary and revokes it automatically after the task is completed. This way, there’s no accumulation of access rights, no drift, just access that exists for as long as it is needed.
When applied to developer scenarios, this approach significantly changes outcomes. Instead of access quietly piling up with each role change and project, every transition acts as a trigger. Each project’s completion ensures that the system cleans up automatically. The system can respond to real events in real time, following a straightforward pattern: detection, response, and audit. This process is triggered by real events rather than relying on a calendar.
Let’s review:
Modern environments don’t slow down for review cycles, and our identity strategies shouldn’t either. As infrastructure, teams, and machine identities evolve faster than ever, the gap between what access looks like on paper and in practice keeps widening. This gap is where risk emerges.
Here are a few key takeaways:
-
Identity drift is subtle: it accumulates quietly through reasonable decisions that are individually correct but never resolved as needs evolved.
-
Static identity models are insufficient: while static models still have value, they were not designed for dynamic environments. They must be complemented with continuous evaluation to remain effective.
-
Adaptive identity: this approach treats access like a living system. Context, role, and behavior are crucial factors in determining whether access remains appropriate, not just whether it was initially approved.
As developers, we play a pivotal role in addressing this issue. Utilizing SDKs, APIs, Agentic Security Fabric, and Just-In-Time provisioning are key strategies. The more we leverage these tools, the less identity drift we will experience.
If you’re interested in assessing identity drift in your own environment, a practical starting point is to examine recent role transitions. Ask yourself: what access has been added, and what access hasn’t been removed? You may notice patterns more quickly than you think.
For more information on adaptive identity, the identity foundational model, and how to use developer tools, check out:
At our recent Developer Days 2025, we also covered these topics in detail as we chart the future of adaptive identity. Check out our video library for on-demand viewing.
Are you encountering identity drift within your environment? What strategies have been effective (or ineffective) for you? Share your ideas and experiences down below!