What breaks when ITSM tools are used as the only access request control?

Why ITSM Records the Request But Does Not Control the Decision

An ITSM ticket is a workflow record, not an entitlement decision engine. It can capture who asked, who approved, and when the work moved, but that does not mean the request was judged against role design, business need, or access policy. The control failure is subtle: the process looks complete while the actual access decision may still be ungoverned.

That is why request handling and access control need different logic. An access request should be validated against entitlement catalogues, IAM and IGA Basics, and the decision criteria that define whether the access is appropriate in the first place. A ticket alone only proves movement through a queue.

When organisations confuse case management with authorization, they end up optimising for speed and traceability instead of correctness. The ticket may show closure, but it does not show whether the requester should have received that entitlement, whether the approval path matched policy, or whether the access was granted with enough restraint.

What Breaks in Entitlement, Time-Bounding, and Segregation of Duties

The first thing that breaks is entitlement scope. ITSM tools can route a request, but they do not inherently know whether the requested access fits the user’s job, environment, or risk class. They also do not naturally enforce time limits, so temporary access can quietly become standing access if no separate control revokes it.

The second break is conflict detection. Service desk workflow does not by itself identify separation of duties issues, cross-system toxic combinations, or role overlap that should block approval. A request can look legitimate in isolation and still violate policy once it is compared with existing access, business function, or dependency on another entitlement. Authorisation Models Guide is useful here because it shows why policy-based and attribute-based decisions are stronger than a form field and an approver name.

The third break is lifecycle discipline. If the tool only records the request, it may never force review of whether the access should expire, be recertified, or be removed when the need ends. That is how orphaned access accumulates: the record exists, but the governance loop is incomplete.

Why Audit Evidence Gets Weaker Even When the Queue Looks Clean

Auditors do not only ask whether a ticket exists. They ask whether the organisation can demonstrate that the access was appropriate, approved by the right authority, limited to the right scope, and removed when it should have been. An ITSM record can support the story, but it cannot on its own prove entitlement correctness or least privilege. The result is weak evidence with a strong-looking paper trail.

This is also where operational risk compounds. A fast approval path can create the impression of control while actually expanding access beyond what the business required. If no separate entitlement logic, license check, or revocation trigger exists, the ticket process becomes a transport mechanism for bad decisions rather than a control over them.

For practitioners, the practical distinction is simple: recordkeeping is evidence of process activity, not evidence of access appropriateness. Financial Services Identity Security Guide helps illustrate how access decisions become especially sensitive where privilege, third parties, and regulated workflows intersect.

Risk and Threat Considerations

Using ITSM as the only access request control creates a predictable exposure pattern: approvals can be fast, but they are often detached from entitlement validation, time limits, and segregation-of-duties checks. That makes over-permissioning more likely, increases the blast radius of mistakes, and leaves weaker evidence for audits and investigations.

Failure mechanism: The ticket workflow records movement and approval, but no separate control evaluates whether the requested access is appropriate, time-bound, or conflicting with existing access. Requests therefore pass through with a false appearance of governance.

Impact: Excess access can persist, orphaned access can accumulate, and reviewers may later be unable to prove that the grant was properly justified. In the worst case, the ticket becomes a record of how the wrong access was approved, not a safeguard against it.

Practitioner Guidance

What to prioritise: Treat the ITSM tool as the intake and evidence layer, then require an authorization or governance step that validates entitlement scope, duration, and conflict rules before any access is provisioned.

What to verify: Each approved request should map to a defined entitlement, an owner, an expiry or review point, and a policy basis that explains why the access was acceptable for that requester at that time.

Common mistake: Do not let approval status in the ticketing system stand in for access correctness. A closed ticket is not proof of least privilege, SoD compliance, or timely removal.

Practitioner takeaway: If the access control decision lives only in ITSM, you have workflow, not governance. The control must be able to say no, limit duration, and prove the decision was right.

Related resources from NHI Mgmt Group

• What breaks when app login tools are used for backend access control?
• How should security teams govern API keys used for generative AI access?
• What breaks when access reviews are used as the main risk control?
• What breaks when network controls are used instead of request-level policy for machine access?