Join our Newsletter — 33% off our NHI Course

ITSM tools and access requests: what IAM teams are missing

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 20739
Topic starter  

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 →


This topic was modified 4 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21545
 

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



   
ReplyQuote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 21545
 

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:

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


This post was modified 4 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.