Who should own automated access and reset decisions in ITSM?

Why This Matters for Security Teams

Automated access and reset decisions are not just service desk tasks; they are policy enforcement decisions with identity, privilege, and audit consequences. If ownership sits only with the support channel, the organisation often gets fast ticket handling but weak control over what can be reset, who can approve exceptions, and how abuse is detected. That gap matters because access resets often touch privileged accounts, service accounts, and recovery paths that attackers actively target. NHI Management Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which makes poorly owned reset workflows especially dangerous.

Current guidance from the OWASP Non-Human Identity Top 10 and the broader 52 NHI Breaches Analysis shows a repeated pattern: access processes fail when policy, workflow, and approvals are split across teams with no single accountable owner. The practical issue is not whether support can execute the steps; it is whether the organisation can prove the steps were safe, authorized, and repeatable. In practice, many security teams encounter reset abuse only after a compromised account has already been used to pivot into higher-value systems.

How It Works in Practice

Ownership should be structured around decision authority, not ticket handling. Identity engineering or IAM owns the policy logic, privileged access management owns the approval and elevation model, and service management owns workflow execution, routing, and evidence capture. That separation keeps the support channel operational without letting it define security boundaries. For human accounts, this usually means the help desk can trigger a reset only when policy conditions are met. For NHIs, the same principle extends to API keys, service accounts, tokens, and certificates, where reset may mean rotation, revocation, re-issuance, or session termination rather than a simple password change.

Best practice is evolving toward policy-as-code and tightly scoped workflow automation. At minimum, the owning team should define:

• Which identities are eligible for self-service or assisted reset
• What verification signals are required before action is taken
• Which resets require privileged approval or step-up authentication
• How exceptions are logged, reviewed, and periodically recertified
• How stale credentials are revoked and downstream sessions are invalidated

This is where runtime enforcement matters. The OWASP Non-Human Identity Top 10 is useful because it highlights why static process ownership fails when secrets and privileged identities are distributed across automation, CI/CD, and integrated apps. NHI Management Group’s Key Challenges and Risks section reinforces that secrecy, rotation, and offboarding are not one-time tasks; they are ongoing control functions that need a named owner. These controls tend to break down when the ITSM platform is allowed to auto-approve edge cases in federated or heavily customised environments because workflow exceptions start outrunning the written policy.

Common Variations and Edge Cases

Tighter ownership often increases ticket friction and implementation overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially where support teams are measured on closure time and end users expect instant recovery. Current guidance suggests that the answer is not to centralise every decision in security, but to separate routine execution from policy ownership so delegated actions remain bounded and reviewable.

There are also edge cases where the standard model needs adjustment. In small IT teams, one group may temporarily own both workflow and policy, but that arrangement should be treated as a transition state, not a target operating model. In highly regulated environments, reset decisions for privileged access or production NHIs may require dual approval, stronger evidence, and immutable logging. For third-party support or outsourced service desks, the owning team must still control policy, even if the vendor operates the ticket queue. NIST’s identity guidance and the emerging NHI governance literature both point to the same operational principle: delegation is acceptable, accountability is not.

For teams formalising this structure, the key question is not who touches the button but who can change the rules behind the button. That distinction is what prevents “automated” resets from becoming uncontrolled privilege recovery paths. In practice, many organisations discover this only after a reset path is abused to regain access to a compromised account rather than through an intentional governance review.

Related resources from NHI Mgmt Group

• Who should be accountable for automated decisions in healthcare ITSM?
• Who should own access decisions when ITSM and IAM responsibilities overlap?
• Who should own password reset and account unlock governance in the enterprise?
• Who should own TCO decisions for secrets management platforms?