Security Requirements for Selecting an ITSM and Service Desk Platform: A Buyer’s Guide to Criteria and Testing

An ITSM and service desk platform holds the keys to the rest of the estate: it resets passwords, approves changes, stores attachments full of logs and tokens, and runs integrations with privileged service accounts. Yet most selections are scored on workflow, reporting and licence price, with security reduced to a questionnaire answered after the shortlist is fixed. This vendor-neutral buyer's guide sets out the security requirements to write into the RFP, how to score them, what to ask vendors and how to prove the answers in a proof of concept. It is for security architects, IT service management owners and procurement leads choosing a SaaS or self-hosted ITSM platform. For hardening a platform you already run, see Securing the ITSM platform itself.

Key takeaways

• Treat the service desk as a privileged system. Whoever controls password and MFA reset workflows, change approvals and integration accounts can reach almost anything, so score the platform like an identity system, not a ticketing tool.
• Identity basics must be included, not sold as extras. SAML or OIDC single sign-on, phishing-resistant MFA, SCIM provisioning and audit logs belong in the base licence, as CISA's Secure by Demand guidance asks buyers to insist.
• Tickets are a data store full of secrets. Attachments, HAR files, logs and pasted credentials end up in tickets; require attachment controls, retention by record type and redaction before you migrate a single ticket.
• Integrations are the largest identity surface. Every connector, on-premises agent, webhook and API client is a non-human identity; require scoped, expiring, attributable credentials for each.
• Prove it in the PoC. Test a forced MFA reset, an attachment containing a session token, a revoked integration token and a full audit log export before you sign, not after go-live.

Define requirements

Start from what the platform will do in your organisation, because the security requirements follow the use cases. Agree these points with IT operations and the service desk before talking to vendors:

• Scope of service: internal IT only, or also HR, facilities and customer support. Customer-facing portals and public knowledge bases add anonymous access paths and personal data from outside the organisation.
• Identity actions: will agents reset passwords, reset or re-register MFA, unlock accounts or grant access through catalogue requests? If yes, the platform becomes part of your identity proofing chain. See the Account Recovery and Help Desk Security Guide.
• Change and automation: will approved changes trigger automation (orchestration, scripts, infrastructure jobs) directly from the platform? Then platform administrators effectively hold change rights in production.
• Data classes: list what will land in tickets: personal data, HR cases, security incidents, logs, screenshots, crash dumps and browser traces.
• Hosting and residency: SaaS region, customer-managed keys, government or sector hosting needs, and whether any on-premises connector is acceptable.
• Integrations: directory and IdP, endpoint management, CMDB discovery, monitoring alerts, chat platforms, code repositories and AI assistants. Count them; each needs an account.
• Exit: how ticket history, attachments, audit logs and configuration will be exported if you leave. The ITSM platform migration playbook shows how much has to move.

Small organisations with a single SaaS service desk can focus on identity, data retention and integration tokens. Large or regulated organisations should add tenant isolation evidence, customer-managed keys, separation of platform administration from security administration, and contractual audit log retention.

Capability areas

Identity and administration

• Single sign-on: SAML 2.0 or OpenID Connect for agents, requesters and administrators, with local password login disabled except for documented break-glass accounts.
• MFA: phishing-resistant options (FIDO2/WebAuthn) enforced through the IdP, with no product path that bypasses SSO, such as a legacy mobile app or basic-auth API.
• Provisioning: SCIM 2.0 (RFC 7643 and RFC 7644) or equivalent so leavers lose agent and approver rights when the IdP disables them. See the SCIM Provisioning Guide.
• Role model: granular roles that separate platform administration, workflow design, security incident handling and agent work, with field-level and record-level access controls.
• Impersonation: many ITSM platforms let administrators act as another user for testing. Require that it can be restricted to named roles, is logged with both identities and can be disabled in production.
• Session controls: idle and absolute timeouts, IP or network restrictions for administrators and re-authentication for sensitive actions.

Service desk identity workflows

• Mandatory verification steps in password, MFA and access reset forms, with the verification method recorded on the ticket.
• Higher assurance or second-person approval for privileged accounts and for any MFA re-registration.
• Alerts to the user and to security when a reset is completed. CISA advisory AA23-320A describes Scattered Spider posing as staff to get help desks to reset credentials, the pattern behind the MGM Resorts breach and the Co-op cyber attack. See the Help Desk Identity Verification Policy Template.

Data protection in tickets

• Encryption at rest with an option for customer-managed keys, and TLS for all portals, APIs and inbound email handling.
• Attachment controls: file type restrictions, malware scanning, size limits and the ability to restrict who can open attachments on sensitive record types.
• Pattern-based detection or masking of secrets and personal data in ticket fields and attachments, and a retention policy per record type with verified deletion.
• Controls on public portals and knowledge articles so internal articles cannot be published anonymously by a misconfigured permission.

The Okta support system breach shows why: according to Okta's root cause analysis, an attacker used a service account stored in the support case system to open customer files, some of them HAR files containing session tokens, and hijacked sessions at five customers.

Integrations and non-human identities

• Dedicated integration accounts per connector, non-interactive, with scoped OAuth clients or tokens that expire and can be rotated without downtime.
• An inventory view of every API client, token, webhook and on-premises connector with owner, last use and scopes.
• Signed or authenticated webhooks, outbound allowlists and egress controls for any on-premises integration agent.
• Vetting and permission review for marketplace apps before installation.

The Internet Archive breach showed what follows when help desk API tokens are not rotated after a first compromise. See the ITSM platform integration security guide.

Platform customisation

• Server-side scripting, flows and business rules are code. Require version control or change sets, peer review, separation of development, test and production instances and a log of who promoted what.
• The ability to restrict script execution rights and outbound calls from scripts.

Audit, logging and evidence

• Audit records for sign-ins, role and permission changes, configuration changes, impersonation, data exports, attachment downloads and API use, exportable to your SIEM through an API or stream.
• Retention of at least six months at no extra charge, the baseline CISA's Secure by Demand guide asks SaaS buyers to look for, with longer contractual retention for regulated organisations.
• Logs that distinguish how a file was opened. Okta reported that file views from a case and from the files tab produced different log events, which slowed its investigation.

Vendor assurance and resilience

• Independent assurance (SOC 2 Type II report, ISO/IEC 27001 certificate with a scope covering the service, CSA STAR entry), recent penetration test summary and a published vulnerability disclosure policy.
• Backup and restore at record level, documented RTO and RPO, and a complete export of data and audit logs on exit.
• Notification commitments for security incidents affecting your tenant.

Evaluation criteria

Weights are illustrative. Adjust them to the use cases agreed above; a platform that will run identity resets should weight identity workflows higher.

The table below maps common ITSM threats to the requirement that addresses them. ATT&CK IDs are from ATT&CK v20.

Where identity fits

An ITSM platform is both a consumer and a producer of identities. It consumes your workforce identities through SSO and SCIM, and it creates non-human identities for every integration, often with broad read and write rights across the directory, endpoint management and cloud accounts. Ask how each integration account is owned, scoped, rotated and decommissioned, and feed them into your NHI inventory from day one. See the NHI Discovery Guide and, where virtual agents or AI assistants act on tickets, the AI Agents in the IT Service Desk guide.

Questions to ask vendors

• Are SAML or OIDC SSO, SCIM provisioning and full audit logs included in the licence tier we are buying, or sold separately?
• Which sign-in paths (mobile apps, APIs, legacy endpoints, email actions) bypass SSO and MFA, and can each be disabled?
• How is administrator impersonation logged, and can it be limited to named roles or turned off in production?
• Can reset workflows enforce a recorded verification step and require second-person approval for privileged accounts?
• How do you detect or mask passwords, tokens and HAR files in tickets and attachments, and can we restrict who opens attachments?
• What audit events exist for attachment downloads, data exports and API calls, how long are they kept at no extra cost, and how do we stream them to our SIEM?
• Can every integration use its own scoped, expiring credential, and can we list all active tokens with last use?
• Where is our data stored, who on your staff can access our tenant, under what approval, and is that access logged to us?
• Which independent reports cover this service, and does the scope include the region and features we will use?
• What do you provide on exit: data, attachments, audit logs and configuration, in which formats and within what period?

Red flags

• SSO, MFA enforcement or audit logs available only in a premium tier.
• Shared integration accounts or API keys that never expire and cannot be scoped.
• No log of attachment access or data export, or audit retention measured in days.
• Impersonation available to all administrators with no separate log entry.
• Vendor support staff access to tenant data with no customer approval or customer-visible log.
• An assurance report whose scope excludes the hosting region or the modules you are buying.

Proof of concept

1. Connect the trial tenant to your IdP with SSO and SCIM, disable local login and confirm a disabled IdP user loses agent access within the agreed time.
2. Build the password and MFA reset form with mandatory verification and approval, then attempt to complete a reset without the verification fields.
3. Attach a test file containing a dummy session token and a dummy API key; check masking, scanning, who can open it and the audit trail of each download.
4. Create three integrations with separate scoped credentials, revoke one and confirm only that integration fails, with the failure logged.
5. Run an administrator impersonation session and a bulk export, then confirm both appear in the SIEM with the right identities.
6. Promote a scripted change from test to production and confirm the record shows author, reviewer and time.
7. Restore a deleted record and export a sample of tickets, attachments and audit logs in the exit format.

Score each step pass or fail against the criteria table. Agree a rollback point: if the identity or audit tests fail, do not proceed to contract on the promise of a future release.

After selection: measures and common failure patterns

Once live, track: the share of agents and administrators signing in only through SSO with phishing-resistant MFA; integration credentials older than your rotation standard; median time from IdP leaver event to loss of ITSM access; the number of tickets flagged for secrets or HAR files and how quickly they are purged; and the proportion of identity resets with a recorded verification step. The ITSM platform rollout playbook and ITSM platform health check cover rollout and review.

• Migrating history unfiltered: years of tickets with passwords and logs are copied into the new platform before retention and masking are configured.
• Integration accounts as administrators: connectors run with full administrator rights because scoping was not tested in the PoC.
• Outsourced desk with full rights: third-party agents get the same roles and network access as internal staff.
• Reset workflow on paper only: verification is a policy, not an enforced field, so it is skipped under pressure.
• Logs never leave the platform: audit data is not streamed to the SIEM, so a compromise is investigated with whatever the vendor still holds. See If your ITSM platform is compromised.

Framework mapping

Standards and references

• CISA: Secure by Demand Guide
• CISA: Secure by Design Pledge
• NCSC: The Cloud Security Principles
• CISA: Scattered Spider Advisory AA23-320A
• Cloud Security Alliance: Cloud Controls Matrix
• NIST: SP 800-53 Rev. 5
• Okta: Support Case Management System Root Cause Analysis

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Securing the ITSM platform itself · Jira Service Management Security · Help Desk Social Engineering Incident Playbook · Security Requirements for Selecting a CMDB and IT Asset Management Tool