ITSM platform choice exposes access governance gaps in app requests

At a glance

What this is: Zluri compares Zendesk, ServiceNow, Jira, and its own app request approach to argue that ITSM choice matters most when it affects identity, role, risk, and compliance checks in access workflows.

Why it matters: IAM, IGA, and NHI teams should treat request intake as a governance control point, because the workflow that approves access often determines whether entitlement decisions are consistent or ad hoc.

By the numbers:

• Jira pricing starts at $7.50 per user per month for Standard, $14.50 per user per month for Premium, and Enterprise pricing is available on request.
• Zendesk's suite plan starts at $49 per agent per month and suite pro starts at $99 per agent per month.
• Zluri says its own platform is free for up to three agents, with a premium subscription available from $20 per agent per month.

Context

ITSM request workflows sit at the boundary between service management and identity governance. When a request channel can create access without checking role, entitlement scope, and policy fit, it becomes an access path rather than a control point.

This article compares Zendesk, ServiceNow, and Jira, then uses that comparison to argue for a self-service app request model that still verifies identity and business need before access is granted. The governance problem is not the ticket itself but the approval logic behind it.

For IAM and NHI programmes, app request handling matters because it often determines whether access reviews, approvals, and audit evidence are generated consistently or whether exceptions accumulate in a ticket queue.

Key questions

Q: How should security teams govern app requests in ITSM workflows?

A: They should treat app requests as access decisions, not service tickets. The workflow needs clear approval criteria, named approvers, policy checks, and an auditable record of why access was granted or denied. If those elements are missing, the portal may move tickets efficiently but still fail to enforce governance.

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

A: Because the catalogue becomes an implicit policy boundary. If applications are added faster than they are reviewed, users can receive access through convenience rather than governance. The risk is not only overprovisioning, but also the loss of clear approval logic, which weakens auditability and makes later recertification harder.

Q: What are the signs that ITSM access governance is failing?

A: Look for missing approval histories, inconsistent changelogs, weak searchability, manual reconstruction of request decisions, and reporting that cannot tie requests to actual provisioning outcomes. Those are signs that the workflow exists operationally but not as defensible governance evidence.

Q: What should teams do when app requests also create non-human access?

A: Apply the same identity checks, approval discipline, and entitlement scoping that you would use for privileged access. If a request can create integrations, service accounts, or other non-human access, it should be governed as part of the broader identity lifecycle, not treated as a separate ITSM convenience.

Technical breakdown

How app request workflows become identity control points

An ITSM request workflow is not just case handling. It can become the system that decides whether access is created, delayed, denied, or escalated, which makes it part of the identity control plane when the request is for a SaaS app or internal service. In practice, the risk is that convenience features such as self-service portals, routing, and automation can bypass the governance questions that matter most: who is requesting access, what role justifies it, and whether the entitlement aligns to policy. If those checks are not explicit, the ITSM tool becomes a workflow shell around informal approvals.

Practical implication: Treat app-request design as an access-governance decision, not a service desk configuration exercise.

Why request automation can still leave governance gaps

Automation speeds ticket movement, but it does not prove that the access decision was valid. A workflow can auto-assign, auto-route, or auto-notify while still failing to enforce the identity attributes, approval roles, and compliance checks that determine whether access should exist at all. That distinction matters because ITSM efficiency often gets mistaken for IAM control maturity. For IAM and NHI programmes, the useful question is not how fast a ticket moves, but whether the workflow captures a defensible decision record for who approved what, on what basis, and under which policy.

Practical implication: Require every automated request path to preserve approver identity, decision basis, and policy evidence.

App store models shift the approval burden to entitlement design

A self-service app store changes where the governance work happens. Instead of handling every request manually, the model pre-defines which apps are visible, which users can request them, and what checks happen before access is issued. That can improve consistency, but only if the catalog itself is curated against risk, role, and policy. Otherwise, the organisation has merely moved the control failure upstream into catalog design. The article's core message is that visibility and automation are useful only when the entitlement catalogue expresses governance intent clearly.

Practical implication: Govern the catalog, not just the ticket queue, or the same access exceptions will reappear in a faster workflow.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
• Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

App request workflows are now an identity governance surface, not a service desk detail. When access requests can trigger entitlement creation, the workflow is effectively deciding who may enter the software estate. That makes ticketing logic part of IAM and, where machine accounts or app integrations are involved, part of NHI governance as well. The practitioner conclusion is straightforward: if the workflow cannot express policy, it cannot be trusted to enforce it.

Self-service access models create governance debt when the catalogue is not policy-aware. A request portal that exposes apps without clear rules for role fit, risk tier, and business justification turns convenience into entitlement drift. The article points to the right problem space even when comparing ITSM platforms: the real issue is whether request intake preserves approval quality at scale. Practitioners should read that as a catalogue-governance problem first and a UX problem second.

Identity evidence should be produced by the workflow, not inferred after the fact. Approval records, role checks, and denial reasons need to be captured as part of the request lifecycle if they are going to support audit and recertification later. Otherwise, the organisation ends up reconstructing governance from ticket comments. The practitioner conclusion is that request systems must emit usable identity evidence, not just operational status updates.

ITSM and IAM are converging at the request layer, which means tooling selection now affects control design. The market is moving toward workflows that combine service management, access orchestration, and governance evidence in one place. That does not eliminate IAM architecture choices, but it does force teams to decide whether the request channel is a recording layer or an enforcement layer. Practitioners should treat that decision as architecture, not admin preference.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: NHI Lifecycle Management Guide

What this signals

Policy-aware request handling matters more than ITSM brand choice. Teams should evaluate whether the workflow can enforce identity, role, and compliance checks before access is created, not just whether it can route tickets quickly. That distinction will matter increasingly as app request portals absorb both human and non-human entitlement flows.

Identity evidence must be produced at request time. If the approval rationale is not captured when access is granted, later recertification becomes reconstruction rather than governance. Request systems that can emit decision records will fit IAM programmes far better than systems that only optimise ticket throughput.

For practitioners

• Define request approval criteria before platform selection Document the identity, role, risk, and compliance checks that every app request must satisfy, then test whether the workflow can enforce them consistently across all request types.
• Separate routing automation from access authorisation Use automation to move tickets, not to imply approval. Keep the approval decision tied to named approvers, policy context, and explicit entitlement review.
• Curate the app catalogue as a policy object Limit what appears in self-service based on business need, risk tier, and entitlement scope so the portal reflects governance intent rather than every available SaaS app.
• Require audit-ready decision records Ensure every approved or denied request stores who decided, what was requested, why it was approved or rejected, and which policy or role rule applied.
• Review request paths that touch non-human access Where app requests can create service accounts, integrations, or other non-human entitlements, apply the same approval rigor used for privileged human access.

Key takeaways

• App request portals become governance controls when they enforce role, risk, and compliance checks rather than only handling tickets.
• ITSM automation can speed routing without proving that an access decision was valid, so approval evidence still matters.
• Non-human access requests should follow the same lifecycle discipline as human access if the workflow can create entitlements.

Key terms

• App Request Workflow: A structured process for asking, approving, and provisioning software access. In identity governance, it is not just a support queue. It is a decision path that must preserve approval evidence, ownership, and revocation history so access can be reviewed and removed later.
• Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
• Request-cost Governance: The practice of setting policy around how expensive a request may be, based on endpoint semantics, parameter ranges, and expected business use. It shifts control design from raw traffic limits to a more precise model of safe application behaviour.
• Self-service catalogue: A curated list of applications or services users can request through an internal portal. It reduces friction, but it also defines a policy boundary because only approved items should be available. If the catalogue grows without review, it can hide access risk.

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 building or maturing an IAM programme, it is worth exploring.