TL;DR: 80% of cyberattacks now leverage stolen credentials or identity-based methods, while provisioning-only IAM leaves over-privilege, incomplete deprovisioning, and audit gaps untouched, according to SafePaaS. Access state changes are not enough when policy, entitlement drift, and lifecycle control are where modern identity risk accumulates.
At a glance
What this is: This is an analysis of why provisioning-only IAM fails to govern modern identity risk, with policy-based access control presented as the broader control model needed to manage privilege, lifecycle, and compliance.
Why it matters: It matters because IAM teams now have to govern not just users and passwords, but entitlement drift, non-human identities, and audit evidence across hybrid environments.
By the numbers:
- 80% of cyberattacks leverage stolen credentials or identity-based attack methods, according to SafePaaS.
- Regulatory penalties average $4.45 million per incident when identity control failures lead to breaches, according to SafePaaS.
Context
Policy-based IAM is a governance model for access decisions, not just a provisioning workflow. The problem with provisioning-only IAM is that it changes access state without continuously testing whether the resulting entitlements still match risk, role, or policy.
In hybrid estates, that gap matters because the identity surface now includes employees, contractors, bots, service accounts, and third-party accounts. When deprovisioning, segregation of duties, and entitlement review are separated from access issuance, organisations can preserve speed while still leaving privilege creep and audit exposure behind.
Key questions
Q: What fails when IAM only provisions accounts and does not govern policy?
A: Provisioning-only IAM fails when it changes access state but leaves privilege, segregation of duties, and lifecycle risk untouched. Accounts can be created and removed efficiently while excess entitlements, stale access, and inconsistent audit evidence continue to accumulate across connected systems.
Q: Why do over-privileged admin accounts create more business risk than standard account compromise?
A: Over-privileged admin accounts create outsized risk because they can bypass controls, reach sensitive systems, and damage multiple services at once. A single compromised privileged identity can disrupt change control, expose data, and trigger compliance failures. Standing access also increases the chance that reused, unrotated credentials become the easiest path for attackers to move laterally and escalate.
Q: What are the signs that manual deprovisioning is failing?
A: Warning signs include former employees or contractors still able to reach finance, ERP, or SaaS apps, inconsistent access records across systems, and repeated audit findings about stale accounts. Those symptoms usually mean the offboarding process is dependent on individual follow-up rather than policy enforcement.
Q: How should security teams govern service accounts in enterprise IAM?
A: Treat each service account as a managed non-human identity with a named owner, documented purpose, least-privilege permissions, and a retirement path. Discovery is only the first step. Governance also requires periodic review, rotation of long-lived credentials, and alerts that focus on workload-specific behaviour rather than human login patterns.
Technical breakdown
Why provisioning-only IAM leaves entitlement drift in place
Provisioning automates joiner-mover-leaver tasks, but it is still fundamentally a state-change mechanism. It can create, modify, or remove access, yet it does not on its own evaluate whether the resulting entitlement set is appropriate, mutually compatible, or still justified after business changes. That is why organisations can be technically automated and still accumulate stale access, excess privilege, and unresolved Segregation of Duties conflicts. Policy-based IAM adds decision logic above provisioning so that access is checked against rules before and after it is issued. Practical implication: treat provisioning as an execution layer, not the governance model.
Practical implication: Separate access issuance from policy enforcement so entitlement drift is blocked, not merely recorded.
How policy-based access control changes access decisions
Policy-based access control evaluates context such as role, location, time, device posture, and account type before access is granted or adjusted. The important shift is that the decision is no longer only tied to a static role mapping. Instead, policy becomes the control surface for risk-sensitive access, including privileged, third-party, and non-human identities. This is why the article frames PBAC as broader than simple automation: the control has to understand whether access should exist at all, not just whether a user can be onboarded quickly. Practical implication: define access policy around business conditions, not just directory attributes.
Practical implication: Use contextual policy to limit access to the conditions under which it remains justified.
Why audits fail when deprovisioning is manual or incomplete
Manual deprovisioning breaks because it depends on people noticing a change and then removing access across every connected application. In practice, that leaves former employees, contractors, and project users with residual access to finance, ERP, and SaaS systems long after the business relationship ends. The result is not only security exposure but also weak evidence during audits, because access records become inconsistent across systems. Policy-based IAM closes that gap by centralising approvals, logging, and lifecycle enforcement across identity types. Practical implication: map offboarding controls to policy checkpoints, not to individual administrator memory.
Practical implication: Make deprovisioning policy-driven and auditable across all connected systems, including third-party accounts.
Breaches seen in the wild
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Provisioning-only IAM is a control plane, not a governance plane. The article describes a common misconception: that onboarding and offboarding automation equals identity governance. It does not, because access state changes can happen while entitlement logic, separation of duties, and review discipline remain unresolved. The implication for practitioners is that IAM maturity has to be measured by policy enforcement, not by how fast accounts are created.
Identity risk now concentrates in entitlement drift rather than account creation. The article correctly places insider risk, privilege misuse, and incomplete deprovisioning at the centre of the problem. Those are not provisioning failures in isolation; they are lifecycle failures that accumulate when access is never re-evaluated against policy. Practitioners should read this as a signal that access governance must follow the identity after issuance, not stop at issuance.
Policy-based IAM is the bridge between human, NHI, and third-party governance. The strongest value in this model is not user convenience, it is consistency across identity types that behave differently but create the same governance burden. That matters because service accounts, bots, contractors, and employees all create audit and privilege risk when the policy layer is fragmented. The practical conclusion is that identity programmes should converge on shared policy logic, even when the subjects are different.
Granular policy is now the difference between compliance theatre and evidence. The article highlights SoD checks, monitoring, and audit trails as core capabilities because regulators care about provable control, not access optimism. A platform that can issue access but cannot explain why access existed, when it changed, and whether it violated policy leaves teams exposed. Practitioners need controls that generate defensible evidence as a byproduct of governance, not after the fact.
Continuous monitoring is the named concept that separates static IAM from policy-based IAM. Static IAM assumes the role model is enough once access is granted. That assumption fails in hybrid estates where context changes faster than manual review cycles. The implication is that identity governance must move from periodic cleanup to continuous policy evaluation if teams want access decisions to remain trustworthy.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Breaches involving stolen or compromised credentials take an average of 292 days to identify and remediate, according to IBM’s Cost of a Data Breach.
- Read next: Service Account Security Guide
What this signals
Policy-based IAM shifts the control point from account creation to entitlement decisioning. That matters because hybrid estates rarely fail at authentication alone. They fail when access remains valid after the business reason for it has disappeared, which is why policy has to sit closer to issuance and review than provisioning does.
Identity governance now has to span people and non-human identities with one control model. Contractors, bots, and service accounts all create the same problem when their access outlives context. Programmes that treat them as separate governance silos will keep missing the entitlement drift that audit teams eventually find.
For practitioners
- Align IAM with policy checkpoints Map joiner, mover, and leaver events to policy decisions so access is re-evaluated whenever role, vendor status, or business context changes.
- Enforce segregation of duties before access lands Run SoD validation before provisioning completes, especially for finance, ERP, and privileged workflows where conflicting access can create fraud or audit risk.
- Centralise offboarding evidence Record every removal, approval, and exception in a single audit trail so dormant access can be traced across SaaS, hybrid, and third-party systems.
- Extend policy to non-human identities Apply the same governance logic to bots, service accounts, and third-party accounts so machine access does not sit outside the identity programme.
- Monitor entitlement drift continuously Review privilege accumulation against active policy so access reviews capture what has changed since issuance, not just what was originally approved.
Key takeaways
- Provisioning automation is useful, but it does not solve privilege creep, incomplete deprovisioning, or policy drift on its own.
- The article frames policy-based IAM as the control layer that turns access changes into governed decisions rather than directory updates.
- For practitioners, the practical shift is to govern access continuously across users, contractors, bots, and service accounts, not only at onboarding.
Key terms
- Identity-Based Access Management: Identity-Based Access Management is the practice of granting and controlling access according to who or what is requesting it. It uses verified identities, attributes, roles, and context to decide access to systems, data, and services, and it ties authentication, authorization, lifecycle management, and auditability into one control model.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
- Deprovisioning: Deprovisioning is the removal of access when a user changes roles or leaves an organisation. For security teams, it is the point where stale accounts, tokens, and permissions should disappear. Weak deprovisioning leaves residual access that can outlive the business need that created it.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org