ITSM tools are not access governance tools for enterprise identity

At a glance

What this is: This is a comparative analysis of IT service management tools that argues ITSM systems are built to move work, not govern access decisions.

Why it matters: It matters because IAM, NHI, and human access programmes all fail when ticketing is treated as governance, leaving privilege scope, expiry, and auditability undercontrolled.

👉 Read Zluri's analysis of why ITSM tools are not access governance tools

Context

IT service management tools are designed to route incidents, changes, and service requests. They are not built to determine whether a request is the right access, at the right privilege level, for the right duration. That gap matters because access decisions are an identity problem, not a ticket-handling problem.

In identity programmes, the failure is usually not the request itself but the control model behind it. When organisations use ITSM as the access decision layer, they inherit queues, manual approvals, and delayed revocation instead of policy-driven entitlement governance. The result is a familiar mix of overpermissioning, compliance drag, and orphaned access.

Key questions

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. That layer should evaluate role, license tier, existing entitlements, approval requirements, and expiration. If the ITSM tool is deciding access on its own, the organisation is tracking requests, not governing privileges.

Q: Why do ITSM-based access workflows create privilege creep?

A: They often close the request without removing or constraining the entitlement properly. If access is granted as a generic ticket outcome, temporary needs become standing access and overlapping permissions accumulate. The problem is structural: service desks optimise closure, while identity governance must optimise scope, duration, and accountability.

Q: What do security teams get wrong about access request automation?

A: They assume automation alone equals control. In practice, automation can speed up poor decisions if the workflow does not include entitlement selection, policy checks, and expiry enforcement. The right question is not whether the request is automated, but whether the access granted is precisely scoped and auditable.

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.

Technical breakdown

Why ITSM ticketing is not access governance

ITSM systems excel at intake, routing, and closure. Access governance requires additional logic: entitlement context, policy evaluation, segregation-of-duties checks, license fit, and expiry rules. A ticket can say someone asked for access, but it cannot on its own decide whether the request matches role, department, risk tier, or existing privileges. That distinction is why a closed ticket does not equal a governed entitlement.

Practical implication: treat ITSM as a workflow front end, not the authority for access decisions.

Policy-driven provisioning and time-bound access

A governance layer can evaluate a request before human review, then provision the specific access scope that matches policy. Time-bound access is especially important because many requests are temporary, but traditional ticket queues often create standing access by default. In identity terms, the control is not just approval, but exact entitlement selection and automatic expiry when the need ends.

Practical implication: enforce explicit expiry and entitlement scoping wherever access is provisioned.

Auditability and SoD controls in access workflows

Access governance needs a durable record of who requested what, which policy evaluated it, who approved it, and what was actually provisioned. It also needs to flag combinations that violate segregation-of-duties rules or conflict with existing access. ITSM alone usually records workflow state, not entitlement intent or governance outcome, which leaves audit teams with incomplete evidence.

Practical implication: require entitlement-level logs and SoD checks, not just ticket history.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing access is the predictable failure mode when requests are handled as tickets: the request is resolved, but the entitlement often persists beyond the business need. That turns temporary access into privilege creep and makes later recertification more expensive because the original decision was never scoped correctly. The implication is that access review programmes inherit bad starting data when ITSM is used as the source of truth.

Policy-based provisioning is the named concept practitioners should adopt: access should be evaluated against predefined rules before a human approval queue ever sees it. That approach matters because it separates low-risk requests from high-risk ones and prevents routine access from consuming governance capacity. For IAM teams, the field is moving from request handling to entitlement decisioning.

Access governance and service management are adjacent, not interchangeable: service desks are built to keep operations moving, while identity controls exist to constrain who gets what, for how long, and under which conditions. When those functions are conflated, the organisation usually underestimates risk because the process feels controlled. The practitioner conclusion is to keep ticketing and entitlement authority separate.

Audit evidence fails when the workflow records action but not governance context: a log that shows approval without policy rationale, license tier, expiry, or SoD evaluation leaves compliance teams with gaps they cannot reconstruct later. That is a control-design issue, not a documentation issue. The implication is that access governance needs its own evidence model, even if it integrates with ITSM.

From our research:

• 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.
• For practitioners, the forward step is to align request workflows with the NHI Lifecycle Management Guide so access decisions and revocation logic stay linked.

What this signals

Access governance is becoming a control layer, not a service desk feature: organisations that keep routing identity decisions through ITSM will continue to accumulate noisy approvals and weak evidence. The programme signal is clear: entitlement authority, expiry, and policy evaluation need their own operating model, even when the service desk remains the front door.

With 1 in 4 organisations already investing in dedicated NHI security capabilities and another 60% planning to do so within twelve months, the market is moving toward purpose-built governance rather than ticket-driven access handling, according to The State of Non-Human Identity Security. Teams that still treat access requests as generic work orders will find that their audit model lags their actual risk.

Policy-based least privilege: this is the practical shift underway, where the question becomes what access should be granted, for how long, and under what policy evidence. That shift also changes how human and non-human access are reviewed, because a single queue no longer captures the governance differences between them.

For practitioners

• 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.
• Capture entitlement-level audit evidence Record the policy evaluated, the approved permission tier, the actual access granted, and the expiration or revocation event so audits do not depend on ticket notes alone.
• Check for privilege overlap before approval Review whether the requester already has standing access to adjacent systems or overlapping permissions that create unnecessary exposure or segregation-of-duties conflicts.

Key takeaways

• ITSM tools move requests, but they do not by themselves govern access scope, expiry, or entitlement quality.
• The main risk is privilege creep hidden inside apparently clean ticket closures, which leaves audits and recertifications starting from bad data.
• Security teams should keep request routing and access authority separate, then require policy evaluation and automatic revocation for every access grant.

Key terms

• Access Governance: Access governance is the discipline of deciding who or what should receive access, at what level, for how long, and under what policy evidence. It goes beyond request handling by tying entitlement decisions to approval logic, expiry, auditability, and segregation-of-duties checks.
• Entitlement: An entitlement is the actual permission granted to an identity, such as a license tier, role, privilege set, or application scope. In governance terms, the important question is not whether a request was approved, but whether the entitlement matches the business need and terminates when it should.
• Segregation of Duties: Segregation of duties is a control that prevents one identity from holding combinations of access that create excessive operational or fraud risk. In access workflows, it requires evaluating whether a requested permission conflicts with existing access, not simply whether the request is convenient to fulfil.

Deepen your knowledge

Access request governance and policy-based provisioning are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to separate ticket handling from entitlement control, the course is a practical place to start.

This post draws on content published by Zluri: IT teams top 14 IT service management tools in 2026. Read the original.