Notifications
Clear all
Topic starter
09/06/2026 11:46 pm
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.
NHIMG editorial — based on content published by Zluri: IT teams top 14 IT service management tools in 2026
Questions worth separating out
Q: How should security teams govern access requests when ITSM is already in place?
A: Use ITSM for intake and workflow, but move the access decision itself into a policy-driven governance layer.
Q: Why do ITSM-based access workflows create privilege creep?
A: They often close the request without removing or constraining the entitlement properly.
Q: What do security teams get wrong about access request automation?
A: They assume automation alone equals control.
Practitioner guidance
- Separate request routing from entitlement authority Use ITSM to intake and track requests, but require a dedicated access governance layer to decide entitlement scope, license tier, and duration before provisioning occurs.
- Define policy rules for auto-approval and auto-rejection Preconfigure which access requests can be approved automatically, which need multi-level review, and which must be blocked because they conflict with role, department, or risk criteria.
- Make expiry mandatory for temporary access Provision time-bound access for project work, onboarding exceptions, and elevated requests so access is removed automatically when the approved window closes.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- The step-by-step access request flow showing how policy rules decide approvals before a human reviewer sees the request.
- The exact integration path for connecting access governance with existing ITSM platforms while preserving audit trails.
- The provisioning logic for specific license tiers, permission scopes, and automatic expiry after the approved access window.
- The way the app catalog and auto-approval rules reduce routine ticket volume without weakening governance.
👉 Read Zluri's analysis of why ITSM tools are not access governance tools →
ITSM tools and access requests: where identity governance breaks down?
Explore further
10/06/2026 2:15 am
ITSM-based access management creates a governance illusion: a completed ticket looks like control, but it often only proves that work was routed and closed. Identity governance requires decision quality, entitlement precision, and lifecycle expiry, none of which a generic service desk can infer on its own. The practitioner lesson is that closure is not control when access is the real subject.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That same research found that 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, which is a reminder that lifecycle control is still the weak point in many identity programmes.
A question worth separating out:
Q: How do organisations know if access governance is actually working?
A: Look for evidence that requests are resolved with the correct permission tier, temporary access expires automatically, and audits can trace the policy that justified each approval. If the main evidence is still ticket closure, the programme is measuring throughput, not governance quality.
👉 Read our full editorial: ITSM tools are not access governance tools for enterprise identity
