How should teams evaluate ITSM tools for access request governance?

Why This Matters for Security Teams

ITSM tools are often treated as workflow engines, but access request governance is an identity control problem. A fast ticket does not prove who requested access, whether the entitlement was appropriate, or whether removal happened when the need ended. That gap is where audit findings, privilege creep, and delayed deprovisioning usually start. Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward stronger evidence, explicit approval, and revocation as core security outcomes, not optional workflow features.

For NHI and agentic workloads, this matters even more because access is often non-interactive, ephemeral, and tied to systems rather than people. If the ITSM platform cannot bind a request to a verified identity, approved entitlement, and revocation step, it becomes a record of activity rather than proof of control. That is why NHIMG’s Top 10 NHI Issues emphasizes lifecycle discipline over ticket throughput. In practice, many security teams discover access sprawl only after an audit or incident reveals that ticket closure never translated into actual removal.

How It Works in Practice

Evaluate the ITSM tool as part of the control chain, not as the control itself. The platform should capture who requested access, what specific entitlement was requested, who approved it, what evidence supported the approval, and how revocation will be enforced later. For human access, that means linking the workflow to an authoritative identity source and an entitlement catalog. For non-human access, it should also support workload context, such as service account ownership, token lifetime, and the system or agent that will use the permission.

At minimum, teams should test whether the tool can do the following:

• Bind each request to a verified identity, not just a username in a form field.
• Reference a named entitlement, role, or access bundle that can be audited later.
• Require approvers to validate business need, not simply click through queue notifications.
• Trigger downstream provisioning and revocation through a controlled integration.
• Preserve immutable evidence for audit and post-incident review.

That evidence becomes especially important when access is temporary. Best practice is evolving toward just-in-time access, time-bound approvals, and automatic expiration, which aligns with NHIMG’s lifecycle guidance for NHIs. The right question is not whether the ITSM system can move a request quickly, but whether it can prove the request was authorised, limited, and later removed. Current governance models also benefit from mapping controls to NIST Cybersecurity Framework 2.0 identity and access outcomes, because that creates a cleaner line between operational process and enforceable security control. These controls tend to break down when approvals are handled outside the system, because the workflow record no longer matches the actual access path.

Common Variations and Edge Cases

Tighter access governance often increases workflow overhead, requiring organisations to balance auditability against approval latency. That tradeoff is real, especially in engineering teams that need frequent privileged access, break-glass use, or temporary access for automation.

Some environments will need different handling. A mature ITSM tool may be sufficient for standard employee access, but it may not be enough for NHI, service accounts, or agents that need access across many systems and rotate credentials frequently. In those cases, the request process should connect to PAM, secrets management, or workload identity systems rather than trying to model everything as a human ticket. That distinction matters because an access request for an autonomous agent is not just permission to use a tool; it is a governed delegation of execution authority.

Where consensus is still forming is how much of the approval logic should live in ITSM versus policy engines. Current guidance suggests the ITSM layer should record intent and evidence, while policy-as-code or entitlement systems make the enforcement decision. NHIMG’s regulatory and audit perspectives and 52 NHI Breaches Analysis both reinforce the same lesson: if removal is manual, delayed, or outside the system of record, governance degrades quickly. This guidance breaks down in highly distributed environments where SaaS approvals, local admin rights, and machine credentials are all handled in separate tools with no shared revocation trail.

Related resources from NHI Mgmt Group

• How should security teams evaluate Centrify alternatives for identity governance?
• Why do SSO tools often fail to solve access governance on their own?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?