TL;DR: ITSM platforms can route and approve access requests, but they do not determine least-privilege scope, time-bound entitlement, or segregation-of-duties risk, according to Zluri. The governance gap is not speed, it is that ticketing alone cannot decide what access should exist, for how long, or at what permission level.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “Top 14 IT Service Management Tools (ITSM Tools) in 2026”.
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.
Q: Why do access requests in ITSM create over-permissioning risk?
A: Because a ticket workflow treats each request as a separate event, while real identity risk accumulates across many requests and systems.
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.
Practitioner guidance
- Separate request intake from entitlement approval Keep ITSM as the request front door, but move access-scoping decisions into policy logic that can evaluate role, application risk, and existing access before provisioning.
- Define license tier and permission-level rules Map each requested application to the exact entitlement variant a user can receive, including read-only, standard, and admin access, so approvals do not default to broad access.
- Build automatic expiry into project access Set access to revoke itself when the approved business window ends, instead of relying on manual cleanup after a ticket has closed.
Bottom line: ITSM can route access requests, but it does not determine whether the resulting access is least-privilege, time-bound, or SoD-safe.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
ITSM-based access handling creates governance theatre when it is treated as the control. Ticketing proves that a request moved through a queue, not that the resulting entitlement was appropriate. The underlying assumption is that workflow completion equals access correctness, and that assumption breaks as soon as access scope, expiry, or role fit matters. Practitioners should treat ticket closure as evidence of process completion, not entitlement assurance.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What is the difference between ITSM workflow automation and access governance?
A: Workflow automation moves requests through a process. Access governance decides what access is appropriate, validates policy, and ensures the entitlement is limited in scope and duration. The two can work together, but they are not interchangeable.
👉 Read our full editorial: ITSM tools and access governance: why ticketing is not enough
Ticketing is not an identity control plane: ITSM can record access demand, but it cannot establish whether the access should exist, at what scope, or for how long. That is why ticket closure and governance completion are not the same event. For practitioners, the relevant distinction is between operational workflow and entitlement authority.
A few things that frame the scale:
- Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
A question worth separating out:
Q: What should IAM teams do with ITSM after adding access governance?
A: Keep ITSM for service requests, incidents, and change workflows, but stop using it as the system that decides entitlement scope. IAM teams should route access through a policy engine, preserve the audit trail, and reserve manual review for high-risk or exception cases.
👉 Read our full editorial: ITSM tools and access governance: why ticketing is not enough