TL;DR: ITSM platforms can route tickets and automate service work, but they do not decide whether access is appropriate, least-privileged, or time-bound, according to Zluri’s comparison of ITSM tools and access governance. That distinction matters because access control needs policy, entitlement logic, and auditability, not just faster ticket handling.
At a glance
What this is: This is a comparison of ITSM workflows and access governance, arguing that ticketing systems can move requests but cannot make entitlement decisions.
Why it matters: It matters because IAM teams need policy, scope, and expiry control for access requests, while ITSM alone tends to create approval flow without actual governance.
Context
IT service management tools are designed to log, route, and track work. Access governance is different: it has to decide whether a request is appropriate, what level of access should be granted, and whether that access should expire after a task or project ends.
Zluri’s article argues that treating access requests as ordinary tickets produces over-provisioning, standing permissions, and audit gaps. The identity governance problem is not request handling speed. It is whether the approval workflow actually evaluates entitlement, policy, and revocation in a controlled way.
Key questions
Q: What breaks when ITSM handles access requests without a governance layer?
A: The request may be approved and closed, but the organisation still has no assurance that the access is properly scoped, time-limited, or compatible with segregation-of-duties rules. ITSM can move work efficiently, yet it does not evaluate entitlement appropriateness. That is why ticket closure can coexist with over-permissioning and audit gaps.
Q: Why does access request automation still create risk in enterprise IAM?
A: Automation speeds up the handoff, but it does not decide the right entitlement. If the workflow lacks policy checks for role, sensitivity, segregation, and expiry, automation can simply approve bad access faster. The risk comes from converting a request into a permission without validating scope or business need.
Q: How can teams tell whether access governance is actually working?
A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.
Q: Should organisations use ITSM or IGA for access governance?
A: Use both, but for different jobs. ITSM should route and record the request, while IGA should determine whether the entitlement should exist, what level it should have, and when it should expire or be removed.
Technical breakdown
Why ticket workflows do not equal access governance
ITSM platforms are built around service orchestration, not entitlement logic. A ticket can record who asked for access, who approved it, and when the request closed, but that does not answer the governance question of whether the access level was correct. Access governance needs policy-driven evaluation, licence scoping, segregation checks, and expiry logic. Without those controls, the workflow may look orderly while still producing excessive privilege and poor audit evidence.
Practical implication: treat ITSM approval as a routing step, not as a sufficient control for granting access.
How policy-driven access provisioning changes the control model
Policy-based access provisioning adds a decision layer before fulfillment. Instead of granting a generic application entitlement, the system can map role, department, request type, and risk level to a specific license tier, permission set, approval path, or rejection outcome. That changes the control point from post-approval manual execution to pre-approval entitlement validation. It also makes expiry a first-class condition, so access can end automatically when the business need ends.
Practical implication: define access policies around role, risk, and duration before connecting requests to fulfillment.
Why audit trails in ticketing are not the same as real-time access posture
A ticket history shows process, but access posture requires current state. Governance needs to know who has access right now, at what permission level, and whether that access conflicts with other entitlements or policy constraints. That is why a closed ticket is not the same thing as controlled access. If the system cannot show live entitlement state and revocation status, the organisation will still depend on manual review to discover excess access after the fact.
Practical implication: validate that access records, revocation status, and policy violations are visible outside the ticket queue.
Breaches seen in the wild
- SolarWinds supply chain compromise: A backdoored Orion build reached 18,000 customers; attackers then forged SAML tokens and hijacked app service principals.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
ITSM access request handling is not an access governance model. Ticketing systems can document requests and approvals, but they do not inherently determine entitlement quality, license scope, or duration. That distinction matters because governance is about deciding the right access, not merely processing the request efficiently. Practitioners should separate service workflow from identity control as a programme design principle.
Policy-driven provisioning is the missing control layer in most access request flows. The article’s core gap is not automation itself but policy evaluation before fulfillment. When role, department, risk, and segregation rules are not enforced at decision time, organisations create access that is administratively approved yet still mis-scoped. The practical conclusion is that access approval without entitlement logic is only partial governance.
Time-bound access should be treated as a governance requirement, not an enhancement. The article makes clear that access granted for a project or temporary need should expire automatically, because manual revocation is where standing privilege lingers. That is a lifecycle problem, not a ticketing problem. Identity teams should treat expiry and offboarding as part of the access decision, not as an afterthought.
Access posture must be measured outside the service desk queue. A closed ticket tells you that work was processed, not that the organisation is safe from over-permissioning or policy drift. This is where identity governance and service management diverge most sharply. Practitioners need a live entitlement view, not just a process log, if they want credible control over enterprise access.
Access governance breaks when request routing is mistaken for authorisation. The named concept here is ticket-to-entitlement drift: the gap between a request being approved and the resulting entitlement being properly scoped. That drift creates compliance exposure, bloated licensing, and avoidable privilege accumulation. Teams should recognise it as a structural governance failure, not a tooling inconvenience.
From our research library:
- Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
What this signals
Ticket-to-entitlement drift: When organisations let request routing stand in for authorisation, the process becomes visible while the entitlement becomes opaque. The practical effect is that identity teams can close tickets without reducing standing privilege, which is why governance has to move upstream into the approval decision itself.
Access governance for enterprise identity needs a live state model, not just historical ticket records. If the system cannot show current permission level, expiry, and policy conflicts, then the service desk has become an administrative wrapper around unmanaged access.
A useful programme test is simple: ask whether a closed access ticket proves the entitlement was correct or only that someone processed it. If the answer is only the latter, the organisation still needs a true governance layer.
For practitioners
- Separate request routing from entitlement decisions Keep ITSM as the intake and tracking layer, but require a policy engine to decide access scope, approval depth, and rejection conditions before fulfilment.
- Define role and risk-based approval rules Map each application to explicit rules for auto-approval, single approval, multi-level approval, or rejection based on role, department, and sensitivity.
- Enforce automatic expiry for temporary access Make project-based and exception-based access time-bound so permissions are removed when the business need ends, without relying on manual ticket closure.
- Review live access state outside the ticket queue Maintain a current view of who has access, at what permission tier, and whether any entitlements conflict with policy or segregation requirements.
Key takeaways
- ITSM tools are built to process work, not to decide whether access should exist, at what level, or for how long.
- When access requests are handled only as tickets, organisations tend to accumulate over-permissioned users, licence waste, and weak audit evidence.
- A separate governance layer with policy checks, entitlement scoping, and automatic expiry is what turns access handling into access control.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on access requests creating over-permissioned access without policy controls. |
| NHI-01 — Improper Offboarding | Temporary access must expire cleanly, or project access persists after the business need ends. | |
| Recommendation — Apply NHI-05 controls to prevent generic approvals from turning into overprivileged access. Enforce NHI-01 by revoking access automatically when the task or project ends. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article argues that access scope must be governed, not just approved through tickets. |
| Recommendation — Use AC-6 to ensure each request grants only the minimum access needed for the role. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether entitlements are evaluated and controlled, not merely requested. |
| Recommendation — Apply PR.AA-05 to review and enforce access permissions before provisioning them. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about managing user access lifecycles and avoiding uncontrolled entitlement growth. |
| Recommendation — Use CIS-5 to govern access requests, approvals, and revocation through a controlled account process. | ||
Key terms
- Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
- Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
- Over-Privilege: Over-privilege is the state where an identity holds more access than the work requires. In IAM and NHI programs, it usually emerges from role drift, delayed offboarding, emergency exceptions, and copied permissions that are never removed.
- Time-Bound Access: Time-bound access is a control pattern that grants permissions for a defined window and removes them automatically when the window ends. It is a practical least-privilege mechanism for cloud operations and NHI governance because it reduces how long elevated access can be abused.
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 9, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org