Why do ITSM-based access workflows create privilege creep?

Why This Matters for Security Teams

ITSM-based access workflows create privilege creep because the workflow is designed to close a ticket, not to manage the full lifecycle of access. Once a request is approved, the entitlement often persists unless someone separately revisits scope, expiration, and revocation. That mismatch is how temporary exceptions become standing privileges, especially in environments that rely on shared service accounts, API keys, and operational shortcuts.

This is not a paperwork problem. It is an identity governance problem that directly expands blast radius and weakens Zero Trust posture. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, while only 20% of organisations have formal offboarding and revocation processes for API keys. OWASP’s OWASP Non-Human Identity Top 10 frames this as a structural control failure, not an isolated ticketing issue.

In practice, many security teams discover privilege creep only after a service account is reused for an unrelated task and nobody can explain why it still has access months later.

How It Works in Practice

Privilege creep usually starts when ITSM treats access as a one-time approval. A manager or approver confirms a business need, the request is fulfilled, and the entitlement is considered complete. The trouble is that many organisations never translate that approval into a bounded access model with an expiry date, a task scope, or an automatic reclaim step. For NHIs, that gap is even more dangerous because the identity may be embedded in automation, code, or orchestration and therefore never naturally “logs off.”

Good practice is to connect service desk workflows to identity governance controls, so the approval object and the entitlement object are not the same thing. That means the system should answer four questions at request time and after it: what is the identity, what is it allowed to do, for how long, and who is accountable for removing it. NIST’s Cybersecurity Framework reinforces the need for least privilege and ongoing access review, while the NHI Management Group guide highlights how poor rotation and weak offboarding leave long-lived access in place.

• Use time-bound approvals instead of open-ended entitlement grants.
• Issue the minimum role or scope needed for the stated task, not the nearest generic role.
• Link each approval to a renewal or expiry event so access is reviewed, not assumed permanent.
• Separate ticket completion from entitlement revocation so closure does not equal compliance.
• For NHIs, prefer short-lived secrets and automated rotation over manual exception handling.

Some teams also enforce periodic recertification, but current guidance suggests recertification alone is not enough when the original request was overly broad. These controls tend to break down in high-change environments such as DevOps pipelines and shared operational accounts because access is reused faster than review cycles can keep up.

Common Variations and Edge Cases

Tighter access workflows often increase operational overhead, so organisations must balance speed against the risk of permanent over-entitlement. That tradeoff becomes visible in incident response, release engineering, and third-party integrations, where teams prefer durable access to avoid friction. Best practice is evolving, but there is no universal standard for using ITSM alone as the source of truth for entitlement duration.

One common edge case is emergency access. If a break-glass ticket grants broad privileges and nobody enforces automatic rollback, the exception becomes ordinary access. Another is delegated administration, where a “temporary” admin role is attached to a team rather than a person and never removed. The Ultimate Guide to NHIs — Key Challenges and Risks shows why this is especially dangerous when secrets are widely distributed and only partially visible.

The safest pattern is to treat ITSM as the request front end, not the governance engine. Identity controls should decide entitlement duration, enforce revocation, and record evidence of removal. Where teams cannot automate that today, the least risky interim step is to restrict approvals to bounded scopes and require explicit renewal before access survives the original business need.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• When does JIT access create more risk than it reduces?
• What is the difference between role-based access and API key governance for NHI security?
• Why do developer-led access models create NHI risk?