Who is accountable when access remains active after a support ticket is marked complete?

Why This Matters for Security Teams

When access is still active after a support ticket is marked complete, the failure is usually not the ticket itself. It is the control boundary between service management and identity lifecycle governance. In practice, teams often assume closure in the ITSM tool means revocation happened, but that assumption breaks down when the identity system, PAM layer, or automation hook is misconfigured. The result is lingering access that can be abused long after the original work is done.

This matters for both human and non-human access because the same pattern appears in agentic workflows: a task ends, but credentials, tokens, or delegated permissions remain valid. OWASP’s OWASP Non-Human Identity Top 10 treats credential lifecycle and over-privilege as core risks, and NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access enforcement must be continuous, not assumed at closure. NHIMG’s 52 NHI Breaches Analysis shows how often identity control failures persist beyond the event that should have ended access. In practice, many security teams encounter this only after the ticket is closed and the access has already been used in a way no one expected.

How It Works in Practice

Accountability depends on who owns the control that should have removed access, not who merely closed the request. If revocation is automated, the workflow owner is responsible for ensuring the trigger fires on the correct ticket state, the integration calls the right system, and failures are visible. If revocation is manual, the operational owner is accountable for timely execution, evidence, and escalation when the closure step is missed. That distinction matters because “done” in an ITSM queue is not the same as “revoked” in an identity platform.

A mature process usually includes:

• Ticket-state mapping that defines exactly which status change initiates removal.
• System ownership that identifies the identity, PAM, or application team responsible for enforcement.
• Exception handling for failed revocations, broken integrations, and delayed approvals.
• Audit evidence showing when access was removed, by whom or by what automation, and whether any fallback was used.

For machine identities and AI agents, the same principle is better implemented as short-lived access tied to task completion. Current guidance suggests using workload identity and ephemeral credentials so the task boundary drives privilege removal, rather than relying on a human to remember cleanup. That approach aligns with NHIMG’s Ultimate Guide to NHIs and implementation patterns discussed in DeepSeek breach. For runtime identity and policy enforcement, teams increasingly pair this with standards-based trust such as SPIFFE and request-time authorization such as OPA or Cedar.

These controls tend to break down when the ticketing system, identity provider, and target application do not share a reliable state model for completion.

Common Variations and Edge Cases

Tighter revocation controls often increase operational overhead, requiring organisations to balance speed of closure against assurance that access is truly gone. The most common edge case is a hybrid process: automation handles standard removals, but exceptions fall back to a manual queue. That is where accountability often becomes ambiguous, because each team assumes the other owns the missed step.

There is no universal standard for this yet, but current guidance suggests treating any exception path as a first-class control, not an informal workaround. If a contractor, support engineer, or AI agent retains access after closure, the question becomes whether the exception was approved, tracked, and time-bounded. If not, the control owner still owns the failure even when another team performed the final ticket action.

This is also where NHI and agentic systems raise the stakes. A support ticket may represent a temporary business need, but a token, API key, or delegated agent credential can outlive the ticket by days or weeks if TTLs are too long or revocation signals are unreliable. NHIMG’s The State of Secrets in AppSec underscores how fragmented secrets management and slow remediation create persistent exposure. The practical rule is simple: if closure does not automatically remove authority, then the process owner must prove who is responsible for the gap and how the gap is detected before it becomes abuse.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when access remains active after a mass exodus?
• Who is accountable when user access remains active after offboarding?