ITSM platform choice exposes access governance gaps in app requests

At a glance

What this is: This is a vendor comparison of ITSM platforms that also reframes ad hoc app requests as an identity governance problem.

Why it matters: It matters because access request handling sits at the intersection of ITSM, IAM, and lifecycle governance, where weak approval design can create unnecessary privilege and audit risk.

By the numbers:

• Zendesk integrates with over 1,000 apps and services.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Zluri's comparison of Zendesk, ServiceNow, Jira, and app request governance

Context

ITSM platforms now sit closer to identity governance than many teams acknowledge. When app requests, approvals, and access changes are handled through ticketing, the real question is whether the workflow can enforce who should get access, under what conditions, and with what evidence.

The article compares Zendesk, ServiceNow, and Jira, then extends the discussion to Zluri's app request model. That framing is useful for IAM and IGA teams because the operational choke point is not the ticket itself, but the approval logic and visibility around the request.

Key questions

Q: How should security teams govern app requests that are raised through ITSM tools?

A: Security teams should treat app requests as entitlement decisions, not just tickets. The workflow needs identity validation, business justification, approval authority, and an auditable record of who approved access. If the ITSM platform only handles routing, the organisation still needs a separate governance decision before access is issued.

Q: Why do self-service app stores create governance risk if they are not tightly controlled?

A: Self-service app stores can reduce friction, but they also make catalog design a policy issue. If too many apps are visible or approvals are too loose, users can bypass careful review and request access that is inconsistent with role, risk, or compliance requirements. The result is faster access with weaker accountability.

Q: What breaks when approval workflow automation is allowed to grant access implicitly?

A: Automation breaks down when routing, approval, and entitlement issuance are treated as the same action. In that model, a ticket moving forward can look like an approval even when no real governance decision has been made. That creates hidden privilege growth and makes audits harder to trust.

Q: Which identity governance controls matter most when ITSM platforms handle app access?

A: The most important controls are request classification, approval segregation, evidence capture, and post-grant review. Those controls ensure the platform can move work efficiently without turning convenience into silent privilege expansion. In practice, access governance must stay visible even when the request process is automated.

Technical breakdown

ITSM ticketing as an access control layer

An ITSM system becomes an access control layer when the request path determines whether a user can obtain software, permissions, or entitlements. That shifts the risk from simple ticket handling to entitlement governance, because the workflow now needs identity validation, role checks, and approval evidence before access is granted. If the process only tracks service efficiency, it can move faster while still approving the wrong request. This is where ITSM and IAM overlap, and where auditability matters as much as speed.

Practical implication: map every app request workflow to an explicit approval and evidence requirement before it can issue access.

Workflow automation and entitlement drift

Automation reduces manual effort, but in access workflows it can also accelerate mistakes if the underlying conditions are weak. A rule that auto-routes or auto-approves based on team, department, or request channel may be efficient while still creating entitlement drift, especially when request volume rises or business context changes. Mature governance distinguishes between routing automation, approval authority, and final entitlement issuance. Those are not interchangeable controls, even if they sit inside one platform.

Practical implication: separate request routing from approval authority and entitlement grant so automation does not become implicit approval.

Self-service portals and app store governance

A self-service app store simplifies user experience, but it also concentrates governance decisions into a single catalog. That means app visibility, risk scoring, and deny logic become policy decisions, not just UX features. If the catalog exposes too much or the deny path lacks a clear business rationale, users will bypass the intended request path and shadow IT will grow. The governance value comes from how the catalog is curated and reviewed, not from the portal alone.

Practical implication: treat the catalog as a governed access surface and review which apps are visible, approvable, or blocked.

NHI Mgmt Group analysis

ITSM-driven access requests are a governance control point, not a service desk convenience. Once app requests become the path to software access, the workflow itself decides whether identity and entitlement controls are enforceable. That makes approval design, evidence capture, and entitlement visibility part of IAM architecture rather than support operations. Practitioners should treat the request flow as a control surface and not as a purely administrative queue.

Self-service access models create a governance fork between speed and accountability. Employee app stores and bulk request handling reduce waiting time, but they also compress many entitlement decisions into fewer policy moments. That can improve experience while making review quality more important, because one weak rule now affects many users at once. Practitioners need to judge whether the workflow preserves accountability when access is granted at scale.

Access approval logic: the core failure mode is assuming that request routing and entitlement authorisation are the same control. They were designed for separate functions, but this assumption fails when a platform can push users from request to access with minimal human scrutiny. The implication is that teams must rethink where the authoritative approval decision actually lives.

Tool comparison alone misses the deeper programme question: who owns access governance after the ticket is raised? Zendesk, Jira, and ServiceNow can all move requests, but none of them automatically resolve business justification, compliance review, or lifecycle offboarding. That means IAM, IGA, and procurement all need a defined handoff model. Practitioners should define ownership across the request lifecycle before platform selection becomes an operating model decision.

The strongest signal in this topic is the convergence of ITSM and identity workflows. As organisations try to reduce friction in app access, they are effectively turning service management platforms into governance enforcement points. That convergence is useful only if review, approval, and recertification remain explicit controls. Practitioners should assume the boundary between service desk and identity governance will keep collapsing and plan accordingly.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• The governance lesson here connects to Ultimate Guide to NHIs, which shows why access decisions need lifecycle oversight after the request is approved.

What this signals

ITSM-led access workflows are converging with identity governance, which means programme owners need to decide where approval authority lives before scale makes the question harder to unwind. The operational goal is not faster ticket closure, but defensible access decisions that survive audit and recertification.

Request-to-access drift: when the same workflow handles intake, routing, and entitlement issuance, governance can disappear inside convenience. Teams should watch for catalogs that expand faster than policy review, because the visible efficiency gain can hide a growing control gap.

The broader signal is that IAM, IGA, and service management are now operationally entangled, especially where self-service app stores are used to reduce friction. That makes lifecycle ownership and approval segregation more important than platform choice alone.

For practitioners

• Define the approval authority for every app request Document which requests can be routed by ITSM automation, which require manager review, and which need IAM or security approval before access is granted.
• Classify requestable apps by risk and lifecycle impact Use risk score, compliance requirement, and data sensitivity to decide which apps belong in self-service and which should remain gated by additional review.
• Separate ticket routing from entitlement issuance Make sure the system that receives the request is not automatically the system that grants the access, especially for high-impact SaaS and privileged tools.
• Review the app catalog as a governed access surface Limit which applications appear in the employee app store, and remove apps that lack an approved owner, clear justification, or lifecycle oversight.

Key takeaways

• ITSM platforms can become access governance controls when they determine how app requests are approved and issued.
• Self-service app stores improve experience, but they increase risk if catalog visibility and approval logic are not tightly governed.
• IAM teams should separate routing, approval, and entitlement issuance so automation does not silently expand privilege.

Key terms

• Entitlement Governance: Entitlement governance is the control discipline that decides who or what should receive access, under which conditions, and with what evidence. In practice, it connects approval, role assignment, and lifecycle review so access is not treated as a one-time ticket outcome.
• Request-to-Access Workflow: A request-to-access workflow is the path from user submission to entitlement issuance. It becomes a governance mechanism when identity checks, business justification, and approval segregation are built into the process rather than added after the fact.
• Self-Service App Store: A self-service app store is a governed catalog where users request approved applications directly. It improves speed and user experience, but it also shifts policy decisions into the catalog design, making visibility, risk classification, and approval criteria critical controls.
• Approval Segregation: Approval segregation means the person or system that routes a request is not the same authority that grants access. This separation reduces hidden privilege expansion and makes access decisions easier to audit, especially in high-volume ITSM environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: IT Teams Zendesk Vs ServiceNow Vs Jira: Which ITSM Platform To Choose? Read the original.