Why do ITSM tools often create identity governance gaps?

Why This Matters for Security Teams

ITSM platforms are excellent at routing work, approvals, and status updates, but they are not identity control planes. When access requests are converted into tickets, the system of record often becomes the workflow record instead of the entitlement record. That creates a gap between who asked for access, who approved it, what was actually granted, and when it should expire. The result is stale access, weak accountability, and remediation that depends on humans remembering to close the loop. NIST’s Cybersecurity Framework 2.0 treats identity and access as an ongoing control function, not a one-time service desk transaction.

NHIMG’s Ultimate Guide to NHIs shows why this matters operationally: NHIs outnumber human identities by 25x to 50x, yet only 5.7% of organisations have full visibility into their service accounts. In practice, ITSM-driven fulfilment becomes a blind spot when the ticket closes but the entitlement lives on.

In practice, many security teams encounter access drift only after an audit finding, a breach, or a failed offboarding event, rather than through intentional governance.

How It Works in Practice

The governance gap usually appears when the request, approval, provisioning, and revocation steps are split across different tools with no shared identity state. An ITSM workflow may capture business justification and manager approval, but the actual credential, role assignment, or service account change can happen elsewhere, often without a durable link back to policy or expiry. That makes recertification difficult because reviewers see a ticket history, not the live entitlement picture.

Good practice is to treat ITSM as an orchestration layer, not the authority for access state. The access system should record the identity, owner, scope, TTL, and revocation trigger, while the ticket should simply reference the control action. For NHIs, this is especially important because lifecycle management, rotation, and offboarding need to be machine-enforced. NHIMG’s lifecycle guidance and Top 10 NHI Issues both reinforce that manual follow-through is where control breakdowns accumulate.

• Use ITSM to collect request context, approvers, and business purpose.
• Use IAM or PAM to issue the entitlement, with ownership and expiry attached at creation time.
• Store recertification evidence in the identity system, not only in the ticket archive.
• Automate revocation when the task, project, or integration ends.
• Reconcile ticket status against live access state so closure means removal, not just completion.

This guidance breaks down when the organisation depends on legacy systems that cannot expose entitlement APIs, because revocation and recertification then remain partially manual.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against faster fulfilment. That tradeoff becomes visible in environments with emergency access, shared admin accounts, or third-party integrations that still rely on static secrets. Current guidance suggests that exceptions should be explicit, time bound, and reviewed separately, but there is no universal standard for every workflow pattern yet.

One common edge case is “approval by ticket” for NHIs that need perpetual availability. A build pipeline, API client, or automation agent may need repeated access, but that does not justify permanent standing privilege. The better pattern is short-lived credentials, scoped workload identity, and policy checks at request time. That aligns with evolving NHI governance and with regulatory and audit perspectives that expect a defensible control trail, not just a ticket trail.

Another variation appears when ITSM is used as the front door for access reviews. That can work only if the underlying system can prove who owns the asset, whether the entitlement still matches job function, and whether revocation actually occurred. Otherwise, the ticket becomes documentary evidence of a process that may not have changed the live identity state. In mixed human and NHI estates, that is where stale entitlements persist longest.

Related resources from NHI Mgmt Group

• Why do centralized IT management tools often create identity risk?
• Why do complex identity tools create governance risk?
• Why do disconnected IT tools create identity governance problems?
• Why do SSO tools often fail to solve access governance on their own?