What do organisations get wrong when they automate IT requests across ITSM, ITAM, and identity workflows?

Why This Matters for Security Teams

Automating ITSM, ITAM, and identity workflows is not just a productivity project. It changes who can request access, how entitlements are approved, and how quickly risky changes propagate across systems. If the underlying request model is loose, automation becomes a force multiplier for excessive privilege, stale assets, and broken approvals. NIST’s SP 800-53 Rev 5 Security and Privacy Controls remains clear that control design must come before scale. NHIMG’s Ultimate Guide to NHIs shows how often non-human identities accumulate risk through weak lifecycle governance and poor visibility.

Security teams often assume automation reduces human error by default, but the real risk is procedural drift: one bad mapping between ticket category, asset record, and identity entitlement can create standing access at machine speed. That is why request automation has to be treated as a control plane, not a convenience layer. In practice, many security teams discover their weakest approvals only after a mass provisioning workflow has already spread them across environments.

How It Works in Practice

The strongest automation patterns separate request intake, entitlement validation, and execution. That means the ITSM tool should not directly grant access just because a request was approved. It should pass through policy checks that confirm the requester, the asset, the role, the target environment, and the expiration logic all match the business rule. Current guidance suggests using policy-as-code for these checks so the decision is testable, auditable, and repeatable rather than embedded in ad hoc ticket logic.

For identity workflows, the most common failure is confusing approval with authorisation. A manager approval may satisfy process, but it does not prove the user should receive the specific entitlement on the specific asset. The same problem appears in ITAM when device ownership, lifecycle state, or software entitlement status is stale. NHIMG’s Top 10 NHI Issues highlights why service accounts, API keys, and other non-human identities need lifecycle controls that are at least as strict as human access.

Operationally, mature teams usually implement:

• pre-validation of request type against approved business rules
• separation of approval, provisioning, and revocation steps
• time-bound access for elevated entitlements
• logging that links ticket, asset, identity, and policy decision
• automatic exception routing for mismatched or incomplete records

That approach is especially important when requests trigger downstream changes in IAM, PAM, SaaS admin roles, or device posture tools. A request that looks routine in the ticketing layer can still produce overprovisioning if the asset inventory is stale or the role catalogue is too broad. The control fails when the organisation treats workflow automation as a one-time integration problem instead of a continuously governed policy system, especially in environments with fragmented CMDB data and multiple identity sources of truth.

Common Variations and Edge Cases

Tighter automation often increases operational overhead, requiring organisations to balance speed against verification, exception handling, and ownership. That tradeoff is usually worth it for high-risk requests, but it can slow low-risk service desk work if the control design is too rigid. Best practice is evolving, and there is no universal standard for how much validation belongs in ITSM versus IAM versus ITAM.

One common edge case is delegated administration. A local team may be allowed to approve access for its own environment, but the workflow still needs guardrails so the request cannot cross trust boundaries. Another is temporary access for contractors or incident response, where JIT provisioning may be appropriate but only if revocation is automatic and the time window is enforced. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that weak lifecycle control and poor revocation discipline repeatedly turn routine automation into persistent exposure.

Teams also get tripped up by duplicate identifiers, shadow assets, and service accounts that are managed outside the main approval path. Those gaps matter because automation will faithfully execute whatever record is present, even if the record is wrong. The practical fix is continuous reconciliation between the service catalog, CMDB, identity store, and entitlement model, with human review reserved for exceptions rather than every request. Organisations with inconsistent source data and no reconciliation logic are the ones most likely to see automation amplify a bad entitlement model instead of improving it.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat identity security as only an IAM or workforce problem?
• What do organisations get wrong when they try to manage tenant access and custom roles across multiple CIAM vendors?
• What do organisations get wrong when they assume identity security consolidation alone reduces risk?
• What do organisations get wrong when they treat partner enablement as a sales-only function?