Why do legacy IGA platforms often create more ticketing than real automation in enterprise access management?

Why Legacy IGA Turns Access Requests Into Tickets

Legacy IGA platforms often optimise for workflow coordination rather than decision intelligence. They can provision and deprovision accounts, but when a request depends on application state, entitlement nuance, business context, or exception handling, the platform cannot reliably decide on its own. That gap pushes the process back into human review, where the IGA tool becomes a ticket router instead of an automation engine.

This is especially visible in enterprises with large application portfolios, because access logic is rarely uniform. Some systems have coarse role models, some require attribute checks, and some need manual validation because their entitlement design was never normalised. The platform can record that a request happened, but recording is not the same as executing the correct control. For that reason, many teams confuse orchestration with automation: the system can move work around quickly, yet still depend on people to resolve the hard cases.

Current identity governance guidance suggests that automation only holds when the entitlement model is stable enough for policy to make a repeatable decision. In practice, many security and IAM teams discover the real ceiling of their IGA stack only after they try to scale beyond a narrow set of standard joiner-mover-leaver scenarios.

How Ticketing Emerges in Practice

The ticketing pattern usually appears when an IGA workflow hits a decision point it cannot evaluate deterministically. A request may need one of several things: application owner approval, conditional approval based on department or location, manual evidence of training, or a custom entitlement that was never mapped to a reusable rule. The platform then pauses, raises a ticket, and waits for a human to interpret the situation.

That fallback is not always a failure. In some environments, it is the correct control because the business has not standardised the access model enough to automate safely. The problem is that many organisations treat this as full automation when it is actually partial automation with human arbitration. The difference matters because ticket volume, approval latency, and exception handling load all become part of the operating model.

• When the request path depends on an app-specific rule, the workflow engine can only route, not decide.
• When entitlements are inconsistently named or nested, policy logic becomes brittle and breaks under change.
• When approvers are used as a catch-all control, the process shifts from governed access to inbox-based review.
• When revocation and recertification are not tightly modelled, the platform keeps generating work instead of reducing it.

This is why legacy IGA tools often succeed at simple create, read, update, and delete actions but struggle with nuanced access reasoning. If the environment depends on frequent exceptions, custom connectors, or manual ownership mapping, the platform will keep escalating cases into tickets because the underlying policy model is too thin to resolve them.

For a broader view of why machine and service-account governance breaks down when lifecycle and visibility are weak, the Ultimate Guide to NHIs is a useful reference, and the OWASP Non-Human Identity Top 10 shows how control gaps emerge when identity state is not treated as a first-class governance problem.

These controls tend to break down when every application invents its own entitlement logic and the IGA layer has to compensate with manual approvals at scale.

Where Legacy IGA Stops Scaling

The main trade-off is that tighter governance logic often increases administrative overhead unless the identity model is simplified first. Many organisations want the control outcome of automation without doing the prerequisite work of entitlement cleanup, ownership assignment, and policy standardisation. Best practice is evolving, but there is no universal standard for this yet: some teams centralise more logic in the IGA tool, while others move decisions closer to the target application or adopt more context-aware access workflows.

A practical warning is that ticketing volume is often a symptom, not the root cause. High ticket counts can mean the system is protecting against uncertainty, but they can also mean the access model is too fragmented to automate. The distinction is important because reducing tickets by relaxing controls is not the same as improving automation. Teams need to decide whether the right fix is better entitlement design, stronger application integration, or a narrower automation scope.

For practitioners, the key question is not whether the platform can open a ticket. It is whether the access decision can be made from reliable policy inputs without a human translating business context into a one-off exception. When that translation is still required, the platform is supporting governance, but it is not yet delivering true automation.

Risk and Threat Considerations

Ticket-heavy access management creates governance drag, but it also creates exposure when the organisation starts treating manual approval as a control equivalent to policy enforcement. The longer access decisions depend on inboxes and exceptions, the more likely privileged access, orphaned entitlements, and inconsistent approvals become. That matters because access friction often encourages workarounds that bypass the intended review path.

Failure mechanism: The control fails when decision quality depends on humans resolving ambiguous entitlement requests faster than the business can tolerate. At that point, approvers become a bottleneck, approvals become rubber-stamped, and exceptions accumulate without a durable policy model to prevent recurrence.

Impact: The result is slower provisioning, weaker auditability, and a larger chance that excessive or outdated access remains in place because the process is optimised for routing work rather than enforcing repeatable decisions.

Practitioner Guidance

What to prioritise: Measure how many requests are truly policy-driven versus how many exist only because the platform cannot decide. If most exceptions come from a small set of applications, fix those entitlement models first rather than tuning the workflow engine.

What to verify: Check whether every approval step has a clear decision rule, an accountable owner, and a revocation path. If any of those three are missing, the platform is likely creating governance theatre rather than durable automation.

Decision rule: If a request requires repeated human interpretation to be approved safely, treat it as an access-model problem, not an automation problem. If the decision cannot be expressed in reusable policy, keep the ticket but do not call the process automated.

Practitioner takeaway: Real automation in access management is visible when policy can make the same decision repeatedly with the same inputs; if people still have to translate the request, the system is only moving the work, not eliminating it.

Related resources from NHI Mgmt Group

• Why do hybrid identity environments often create more access risk when organisations split credential management between legacy and cloud systems?
• Why does relying on IAM alone create risk for privileged access management?
• What is the difference between access governance and access management in enterprise security programs?
• Why do legacy automation platforms often create more operational cost than the licensing price suggests?