An IT service management platform approves access, fulfils it through integrations and records the evidence that it was approved, so whoever controls its workflows, admin roles and integration accounts controls a large part of your identity estate. This guide sets out a vendor-neutral hardening model for any ITSM or service desk platform: approval workflow integrity, separation of duties, platform admin roles, integration accounts and tokens, on-premises agents, inbound channels, data held in tickets and the platform's own logs. It does not repeat product settings: those are in the Jira Service Management Security and ServiceNow Security Guide (platforms are listed alphabetically). Response to a compromised platform is covered in If your ITSM platform is compromised. It is written for service management owners, platform administrators, identity teams and security architects.
Key takeaways
- The approval is the control. When a ticket approval triggers automatic provisioning, the workflow engine is an authorisation system and needs the same rigour as the identity provider it feeds.
- Self-approval is the commonest gap. Requesters approving their own requests, approvers editing a request after approval, and fulfilment staff granting what they requested all defeat separation of duties (NIST SP 800-53 AC-5).
- Integration accounts outrank administrators. The accounts and OAuth clients that let the platform write to the directory, cloud and endpoint tools usually hold more privilege than any human role, and they keep working after password resets.
- Tier the platform's own admins. Who can edit workflows, scripts, roles and integrations is a Tier 0 question when the platform provisions Tier 0 access.
- Reconcile, do not just log. The strongest detection compares access actually granted in target systems with approved tickets, and treats every unmatched grant as a potential incident.
Why the ITSM platform is a high-value identity system
Most organisations route access requests, password and MFA resets, change approvals and onboarding through the service desk. Over time the platform gains write access to the directory, the identity provider, cloud consoles, endpoint management and network tooling so that fulfilment can be automated. The result is a system that can grant almost any access, with an audit trail that makes the grant look legitimate. Attackers use the same path: the joint FBI and CISA Scattered Spider advisory (AA23-320A) describes actors socially engineering help desk staff to reset passwords and MFA, and abusing trusted relationships with contracted help desks. The help desk call in the MGM Resorts breach, as the attackers described it, shows how one service desk interaction can lead to identity provider administration.
| Asset in the platform | Why an attacker wants it | ATT&CK technique | Primary control |
|---|---|---|---|
| Agent and admin accounts | Act as IT, approve or fulfil requests | T1078 Valid Accounts | SSO with phishing-resistant MFA, tiered admin roles |
| Integration accounts and OAuth clients | Write to directory, cloud and endpoints without a human | T1528 Steal Application Access Token | Scoped, owned, rotated credentials with network restrictions |
| Approval and fulfilment workflows | Grant access with a legitimate-looking trail | T1098 Account Manipulation | Separation of duties, change control on workflow edits |
| Ticket history, attachments, knowledge base | Harvest pasted passwords, keys, diagrams | T1213 Data from Information Repositories; T1552 Unsecured Credentials | Secret scanning, retention, field-level restriction |
| Outsourced or partner desk access | Enter through a supplier | T1199 Trusted Relationship | Separate partner roles, contract terms, access review |
Approval workflow integrity
An approval only means something if the approver is the right person, approved the exact thing that was fulfilled, and could not be the requester. Design the workflow so these properties hold in the engine, not in policy text. The detailed design of request forms and approver selection is in the Access Request and Approval Workflow Design Guide; the controls below are the platform-side enforcement.
- Block self-approval: enforce in the workflow that the requester, the "requested for" person and the approver are different identities, including when the approver is chosen through a delegate or a group.
- Lock the request after approval: any change to the requested item, role, target account or duration after approval must reset the approval. Fulfilment should read the approved values, not the current form values.
- Separate fulfilment from requesting: a fulfiller should not be able to complete a request they raised or approved. Where a small team cannot separate roles, require a second approver and log it.
- Control delegation: approver delegation during leave is a common bypass. Limit delegates to the same or higher level, cap the duration and alert on new delegations for privileged catalogue items.
- Risk-tier catalogue items: privileged groups, admin roles, production access and MFA resets for privileged users get stronger approval (two approvers, the resource owner plus the manager) and time-bound fulfilment.
- Verify approvals that arrive by email: approving by replying to a notification is convenient and spoofable. For high-risk items require approval inside the authenticated platform, and protect the inbound channel with DMARC (see the DMARC, SPF and DKIM Guide).
Credential and MFA resets deserve their own catalogue items with identity verification that public information cannot defeat. The Help Desk Identity Verification Policy Template covers the verification steps; the platform's job is to make verification a mandatory, recorded field before the reset task can close.
Platform admin roles and tiering
The NCSC's secure system administration principles recommend risk-managing administration through tiers, using privileged access management and logging all administrative activity. In an ITSM platform, apply the tiers to what a role can change, not to its job title.
| Capability | Suggested tier | Why | Handling |
|---|---|---|---|
| Edit workflows, business rules, server-side scripts, automation | Tier 0 when the platform provisions privileged access | Can change what an approval does | Named admins only, just-in-time elevation, changes through a change record and a non-production instance |
| Create integrations, OAuth clients, API keys, credentials store entries | Tier 0 | Creates non-human access to other systems | Two-person rule, owner recorded, alert on creation |
| Manage roles, groups, SSO and authentication settings | Tier 0 | Can make anyone an admin or bypass SSO | Break-glass local account only, sealed and monitored |
| Manage catalogue items, forms, assignment rules | Tier 1 | Can misroute approvals | Peer review, version history |
| Work queues, update tickets, read knowledge | Tier 2 | Data access, social engineering target | SSO, MFA, queue-scoped roles |
- Enforce SSO for every human: keep local passwords only for documented break-glass accounts (see the Break-Glass Account Guide) and alert on any local sign-in.
- Use phishing-resistant MFA for admins: AA23-320A recommends phishing-resistant MFA (FIDO/WebAuthn or PKI-based) as resistant to push bombing and SIM swaps.
- Remove standing admin: elevate through PAM or the platform's own elevated-role feature for the duration of a change.
- Restrict partner and outsourced desks: give suppliers their own roles, scoped queues and separate identities, and review them as part of supplier management (NIST CSF 2.0 GV.SC-07).
Integration accounts, tokens and agents
Integrations are where ITSM platforms accumulate non-human identities: inbound accounts that monitoring and HR systems use to create tickets, outbound credentials the platform uses to provision access, and on-premises discovery or orchestration agents. They map closely to the OWASP Non-Human Identities Top 10 (2025), notably NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI. For OAuth versus service account trade-offs, see OAuth Apps vs Integration Service Accounts.
| Direction | Example | Risk | Control |
|---|---|---|---|
| Inbound (other systems call the ITSM) | Monitoring creates incidents; HR system opens joiner requests | A stolen token can create or approve requests | Write-only scope to specific tables or request types; no approval rights; source IP restriction |
| Outbound (ITSM calls other systems) | Fulfilment adds users to directory groups; resets passwords | Token or stored credential grants directory or cloud admin | Least-privilege service identity per target; scoped to the groups the catalogue can grant; secrets in a vault, not the platform |
| On-premises agents | Discovery, orchestration, credential-holding mid-tier servers | Agent host holds credentials for many internal systems | Hardened dedicated hosts, outbound-only connectivity, credentials scoped per discovery range, Tier 0 treatment when it touches domain controllers |
| Marketplace apps and plugins | Third-party apps with API access to tickets | Supplier compromise reads ticket data | Approval process for apps, review requested scopes, remove unused apps |
For OAuth-based integrations, RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) states that access token privileges should be restricted to the minimum required, that tokens should be audience-restricted to a specific resource server, and recommends asymmetric client authentication such as mutual TLS or private_key_jwt. Give each integration its own client and owner so it can be revoked without breaking others, and never let a person sign in as an integration user. Deeper patterns are in the Identity provider (IdP) and SSO platform integration security guide.
Inbound channels and data in tickets
- Email-to-ticket: spoofed email can open, update or approve tickets. Enforce DMARC on inbound processing where the platform supports it, and do not let email alone change the "requested for" field on access items.
- Customer portals: external portals widen the population that can reach the platform; restrict account self-registration and request sharing to the audiences that need them.
- Pasted secrets: tickets and chats collect passwords, API keys and recovery codes. Scan ticket fields, comments and attachments, mask or redact on detection, and rotate the secret, not just the text. See Secrets in chat and tickets.
- Retention and export: set retention for attachments and closed tickets, restrict bulk export and reporting on sensitive tables, and alert on unusual export volumes.
- AI assistants and agents: assistants that summarise tickets or act on requests inherit the platform's data and its integrations; scope their identity like an integration account. See AI Agents in the IT Service Desk.
Decision guidance
- Automated fulfilment or human fulfilment: automate low-risk items fully; for privileged items keep automation but require two approvals and time-bound grants. Manual fulfilment by a broad team is often riskier than tightly scoped automation, because the team needs standing directory rights.
- Credentials in the platform or in a vault: store outbound credentials in an external secrets manager where the platform supports it; if they must live in the platform's credential store, restrict who can read or export it to Tier 0 admins.
- Small organisations: with three admins, separation of duties comes from a second approver and logging rather than separate teams. Prioritise SSO and MFA, blocking self-approval and scoping the one or two integrations that write to the directory.
- Large organisations: multiple instances, partner desks and dozens of integrations mean an integration inventory with owners, a non-production pipeline for workflow changes and automated reconciliation become essential.
Implementation roadmap
- Inventory (weeks 1 to 2): list admin roles and holders, integrations and their credentials, on-premises agents, marketplace apps and catalogue items that grant privileged access.
- Quick wins (weeks 2 to 4): enforce SSO and MFA, disable unused local accounts, remove unused integrations and apps, and turn on platform audit log export to the SIEM.
- Workflow controls (month 2): block self-approval and post-approval edits in a non-production instance, test with the catalogue's top privileged items, then deploy behind a change record. Keep the previous workflow version so you can roll back.
- Integration hardening (months 2 to 3): split shared integration accounts, scope each to its tables and target groups, move secrets to a vault, add IP restrictions, assign owners and rotation dates.
- Admin tiering (month 3): move Tier 0 capabilities to just-in-time elevation and require change records for workflow, script and integration changes.
- Reconciliation (months 3 to 6): compare group and role changes in the directory and cloud with approved tickets daily; investigate unmatched grants.
Detection and measurement
Log administrative changes, role grants, integration and OAuth client creation, credential store reads, bulk exports, local sign-ins and approval events, and send them to the SOC (NIST SP 800-53 AU-2, AU-6; CSF 2.0 PR.PS-04). High-value alerts: a new admin or integration outside a change window, a workflow or script edited in production, an approval by the requester or a new delegate on a privileged item, and an integration used from a new network location.
- Unmatched privileged grants: directory or cloud privileged changes with no approved ticket, target zero.
- Self-approval rate: approvals where approver equals requester or requested-for, target zero.
- Integrations with owner and rotation date: percentage of integration credentials with a named owner and a rotation within policy.
- Standing Tier 0 admins: count of permanent holders of workflow, integration or role admin rights.
- Secrets found in tickets: detections per month and median time to rotation.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Separation of duties in approvals | AC-5 Separation of Duties | PR.AA-05 |
| Admin and integration least privilege | AC-6 Least Privilege; AC-2 Account Management | PR.AA-05 |
| Workflow and script changes | CM-3 Configuration Change Control | PR.PS-04 (evidence) |
| Integration credentials | IA-5 Authenticator Management | PR.AA-05 |
| Logging and review | AU-2 Event Logging; AU-6 Audit Record Review | PR.PS-04; DE.CM-03 |
| Outsourced desks and marketplace apps | SA-9 External System Services | GV.SC-07 |
Common failure patterns
- One integration user for everything: a single account with admin rights serves monitoring, HR and fulfilment, so one leaked credential exposes all of them and nobody can rotate it safely.
- Approvals that can be edited: fulfilment reads the current form, so a requester changes the group after the manager approves a harmless one.
- Workflow admins treated as Tier 2: the people who can edit provisioning scripts sit in the same role as queue managers and have no MFA step-up.
- Resets closed without verification: MFA reset tickets close with no recorded verification, the pattern AA23-320A describes in help desk social engineering.
- Logs kept only in the platform: an attacker with admin rights can read or tamper with the only copy of the evidence.
Practitioner checklist
- SSO and phishing-resistant MFA for every admin; local accounts limited to monitored break-glass.
- Self-approval and post-approval edits blocked in the workflow engine.
- Privileged catalogue items require two approvers and time-bound fulfilment.
- Workflow, script, role and integration changes are Tier 0, just in time, and go through change control.
- Every integration has its own identity, owner, scope, network restriction and rotation date.
- Outbound credentials stored in a secrets manager; credential store access limited.
- Inbound email protected by DMARC; email cannot approve privileged items.
- Ticket fields and attachments scanned for secrets with rotation on detection.
- Platform audit logs exported to the SIEM with alerts for admin, integration and approval anomalies.
- Daily reconciliation of privileged grants against approved tickets.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CISA and FBI: Scattered Spider Advisory AA23-320A
- NCSC: Secure System Administration
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- OWASP: Non-Human Identities Top 10
- MITRE: ATT&CK Enterprise Matrix
Related NHI Mgmt Group resources: Jira Service Management Security · ServiceNow Security Guide · If your ITSM platform is compromised · Security Requirements for Selecting an ITSM and Service Desk Platform