TL;DR: As organisations shift to remote work, expand contractor access, and rely more on bots using service accounts, static entitlements and manual requests no longer keep pace with changing access patterns, according to SailPoint. The governance problem is now about real-time identity control across workforce, machine, and data access, not separate compliance checkpoints.
At a glance
What this is: SailPoint argues that identity security must move beyond static access governance as remote work, service accounts, and data sprawl make manual control models obsolete.
Why it matters: This matters because IAM, NHI, and privileged access teams now have to govern access that changes in real time across people and machines, not just certify it after the fact.
By the numbers:
- We are seeing 87% growth in access requested and more than 50% growth in monthly active users YoY for customers the world over.
- 80-90% of enterprise data is now outside the traditional confines of enterprise applications.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
👉 Read SailPoint's blog on identity security journey and autonomous governance
Context
Identity security breaks down when access moves faster than the governance model. Remote work, contractor access, machine-to-machine service accounts, and real-time privilege changes all push organisations beyond static entitlements and slow access request workflows.
The primary issue is not just more users or more data. It is that workforce identities, bot identities, and sensitive data now interact in ways that make manual certification and binary privilege models too blunt for day-to-day control.
SailPoint’s framing is that the next phase of identity security has to connect visibility, control, and lifecycle governance across human and non-human access patterns at the same time, which is now a typical enterprise condition rather than an edge case.
Key questions
Q: How should security teams govern service accounts that behave like business-critical access paths?
A: Treat service accounts as governed identities with owners, lifecycle states, and scoped entitlements, not as background technical objects. Review them by business function, system dependency, and data reach. The key is to make machine access visible enough for recertification, incident response, and privilege reduction without relying on human-centric assumptions about how access is used.
Q: Why do static roles fail when access changes during the task?
A: Static roles fail because they describe intended access at a point in time, not the access required to complete a task under changing conditions. When posture, geography, or data sensitivity affects privilege, the role can become either too broad or too narrow. That creates governance blind spots and forces teams to manage exceptions instead of actual access behaviour.
Q: What do security teams get wrong about contractor and bot access?
A: They often treat contractor and bot access as narrower versions of employee access, when in practice both can be broader, more time-sensitive, and harder to review. Contractor and machine identities usually need explicit ownership, scoped entitlements, and clear offboarding rules. Without that, the access model accumulates risk faster than certification processes can remove it.
Q: How can organisations tell whether identity governance is keeping pace with data sprawl?
A: Look for whether the programme can connect identities to the data they actually reach, across file stores, SaaS platforms, and shared repositories. If access reviews only cover application login rights, governance is lagging. A working model can answer who can reach sensitive data now, not just who was approved last quarter.
Technical breakdown
Why static entitlements fail in real-time access environments
Static entitlements assume that access can be assigned once and reviewed later. That assumption breaks when employees, contractors, and service accounts need privileges to change during the task, based on posture, geography, data sensitivity, or time of day. In that model, the problem is not only overprovisioning. It is that entitlement state no longer describes actual usage. Identity security has to account for runtime context, not just provisioned roles, because the same identity may act under very different risk conditions across a single workday.
Practical implication: teams should map where real-time privilege changes already occur and stop treating static role design as a complete governance control.
How service accounts and bots complicate identity governance
Bots using service accounts create access patterns that look operational but carry the same governance weight as workforce access. These identities often touch multiple systems, act at machine speed, and are granted broad permissions so automation does not break. That makes them hard to review with human-centric access models. Once machine-to-machine access becomes a major share of enterprise activity, the boundary between application access, infrastructure access, and identity governance blurs, and teams need lifecycle controls that follow the machine identity rather than the application alone.
Practical implication: inventory service accounts by owning system, business function, and entitlement scope before attempting access recertification.
Why data sprawl changes the identity control problem
When most enterprise data sits in unstructured repositories, file stores, and SaaS platforms, identity governance can no longer assume a small set of protected application boundaries. Access decisions now depend on where the data lives, how it is shared, and which regulatory constraints apply across departments and geographies. That shifts identity security from simple user-to-app provisioning toward data-aware governance. In practice, the control plane must understand which identities can reach which data sets, not just which applications they can log into.
Practical implication: align identity governance reviews with sensitive-data locations so access decisions reflect where the data actually resides.
Threat narrative
Attacker objective: The objective is to reach high-value data or systems through access that appears legitimate but is broader and less constrained than governance teams assume.
- Entry occurs through broad workforce, contractor, or service-account access that is already available for normal business operations.
- Escalation happens when real-time business needs or automation patterns expand privileges beyond what static access models were designed to govern.
- Impact follows when excessive or poorly governed access reaches unstructured data stores, SaaS platforms, or machine-to-machine workflows at scale.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static identity governance is losing relevance because access is now task-shaped, not role-shaped. SailPoint’s own description reflects a wider shift: the enterprise no longer has a single access pattern per identity type. Employees, contractors, and service accounts all need context-sensitive access that changes during execution. That means old compliance-centred certification models miss the live risk surface. Practitioners should treat role stability as an assumption that has already eroded.
Service accounts are no longer a back-office exception. When bots using service accounts account for most enterprise access in some environments, machine identity governance becomes a core control plane issue rather than an infrastructure side topic. The discipline now has to cover ownership, lifecycle, privilege scope, and reviewability for identities that never behave like humans. That puts OWASP-NHI style governance and lifecycle discipline at the centre of enterprise access management.
Identity blast radius: the practical limit of how far one identity can reach before access becomes ungovernable. As unstructured data spreads across hundreds of stores and SaaS platforms, the blast radius of a single broad entitlement expands faster than manual review cycles can contain it. The implication is that practitioners must rethink where governance begins, because the boundary is now defined by reachable data, not by application labels.
Autonomous identity governance is only credible if it can see across human, machine, and data boundaries. SailPoint’s framing points to a market shift toward unified control rather than separate tools for workforce access, privileged access, and machine identities. That consolidation matters because the risk is now relational: one identity can expose many datasets and one dataset can be reached by many identity types. Practitioners should prioritise governance models that can trace those relationships end to end.
The next governance failure mode is not missing access requests, but unseen access dependencies. When access can change in real time and data sits outside traditional application boundaries, the failure is often invisible until an audit or incident forces discovery. That changes the identity programme’s job from periodic approval to continuous relationship management across identities, entitlements, and data locations. Teams should measure whether they can explain who or what can reach sensitive data right now.
From our research:
- We are seeing 87% growth in access requested and more than 50% growth in monthly active users YoY for customers the world over, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why access and secret sprawl tend to grow together.
- For a broader lifecycle view, see NHI Lifecycle Management Guide for how governance changes when access must be owned, reviewed, and offboarded continuously.
What this signals
Identity governance is moving from approval workflow to relationship management. When access can change in real time, the programme has to track how identities, entitlements, and data sets relate to one another at the moment of use. That is a materially different operating model from periodic certification, and it is why the control surface now spans workforce IAM, NHI governance, and privileged access in one view.
More automation will not fix a model built on static access assumptions. The issue is not simply volume, but mismatch between how access is granted and how work is actually done across remote employees, contractors, and machine identities. Teams should expect pressure to unify governance across applications, data stores, and lifecycle controls, because those boundaries no longer line up cleanly.
The shift is already visible in the data. With 80-90% of enterprise data now outside traditional application boundaries, practitioners should expect identity programmes to be judged on whether they can explain access to sensitive data in context, not just certify a role catalogue after the fact.
For practitioners
- Map real-time entitlement changes Identify where privileges change during the task instead of at provisioning time, then flag those paths for stronger policy and monitoring. Focus on roles that vary by posture, time of day, geography, or data sensitivity.
- Inventory machine identities separately from users Create a distinct catalog for bots and service accounts that records owner, system dependency, permissions, and lifecycle state. Do not bury these identities inside application inventories.
- Rebuild access reviews around actual usage Use review workflows that reflect who or what is actively using access, rather than certifying broad role bundles that may no longer match runtime behaviour. Prioritise entitlements tied to sensitive data and automation.
- Tie governance to sensitive data locations Overlay identity entitlements with the repositories, file stores, and SaaS platforms where sensitive data actually sits. This makes access review outcomes easier to validate and exposes hidden overreach.
Key takeaways
- Identity security now has to govern task-shaped access, because static entitlements no longer describe how people, contractors, and machines actually use privilege.
- Service accounts and bots are becoming central governance objects, which means machine identity lifecycle and ownership can no longer sit outside IAM strategy.
- The practical test for mature governance is whether the programme can connect identities to the data they reach, in real time and across fragmented storage estates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static entitlements and service account sprawl map directly to NHI lifecycle and rotation gaps. |
| NIST CSF 2.0 | PR.AC-4 | Identity permissions management fits the article's focus on real-time access control. |
| NIST Zero Trust (SP 800-207) | Context-aware access changes mirror zero trust principles for dynamic authorisation. |
Review non-human access regularly and reduce broad entitlements before they become permanent.
Key terms
- Static Entitlement: An access grant that is defined ahead of time and expected to remain valid until a manual change occurs. In practice, static entitlements often lag real work, which makes them easy to overstate in reviews and hard to align with actual privilege use across changing tasks.
- Service Account: A non-human identity used by software, automation, or integration workflows to access systems and data. These accounts need owners, lifecycle controls, and scope limits because they can accumulate broad permissions and operate at machine speed without the natural review signals that human access creates.
- Identity Blast Radius: The amount of data, systems, or workflows that one identity can reach if its permissions are too broad or poorly governed. The larger the blast radius, the harder it is to contain mistakes, automation errors, or compromise, especially when access spans multiple applications and storage layers.
- Real-Time Privilege Change: A pattern where access expands or contracts during execution based on conditions such as context, posture, location, or task state. This creates governance pressure because approval at provisioning time no longer describes the effective permissions in use when the work is actually happening.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by SailPoint: Our identity security journey: Transforming opportunity to impact. Read the original.
Published by the NHIMG editorial team on 2025-12-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org