Your ITSM Platform Is Part of Your Attack Surface

Security teams spend a lot of time on the systems that face the internet: VPN gateways, email, web applications. The IT service management platform rarely makes that list. It sits behind single sign-on, it belongs to the service desk, and it looks like an internal ticketing tool.

Recent disclosures show why that view is outdated. In 2026, Ivanti patched eight vulnerabilities in Neurons for ITSM, several of them critical, including flaws that allow remote code execution without authentication. Months earlier, an access control flaw in the same product let an authenticated user escalate to administrator. Ivanti reported no known exploitation at disclosure in either case, and its cloud customers were patched by the vendor. Organizations running the platform on their own servers had to act themselves.

The lesson goes beyond one vendor. An ITSM platform concentrates exactly what an attacker wants, and it deserves a place in your risk register.

Why Attackers Care About the Service Desk

Think about what a mature ITSM deployment holds.

A map of the environment. The configuration management database lists servers, applications, network devices and the relationships between them. For an intruder, that is reconnaissance already done.

Privileged automation. Modern service desks reset passwords, grant group memberships, provision software and run scripts on endpoints. Those workflows run with service accounts that often have broad rights in Active Directory, cloud consoles and endpoint management tools.

Integration secrets. API tokens for monitoring, HR systems, cloud providers and chat tools are stored so the platform can connect to them. A compromised ITSM server can become a bridge into all of them.

Sensitive conversations. Tickets contain screenshots, error logs, configuration snippets and, far too often, credentials that a user pasted to “speed things up.”

Trust. Employees are trained to follow instructions that come from the service desk. A message sent from the real platform, with a real ticket number, is a strong phishing pretext.

Treat It Like Any Other Critical System

The good news is that existing risk management practice applies directly. Frameworks such as NIST SP 800-30 already describe how to identify threats, rate likelihood and impact, and decide on treatment. The work is to apply that process to the ITSM platform with the same rigor you would apply to a domain controller. If your team needs a starting point, this step-by-step IT risk management process covers the stages from setting context to ongoing monitoring.

In practice, five areas account for most of the exposure.

1. Patch Lag on Self-Hosted Deployments

SaaS customers usually receive fixes automatically, as happened with the recent Ivanti issues. On-premises customers depend on their own change process, and ITSM upgrades tend to be postponed because the service desk is busy and the upgrade can break custom workflows.

Set a target for applying critical security updates to the ITSM platform and track it like any other service level. Use the CVSS score as one input, not the only one, and check whether a vulnerability appears in CISA’s Known Exploited Vulnerabilities catalog. An exposed, unauthenticated remote code execution flaw in a system that holds integration secrets should move to the front of the queue.

2. Over-Privileged Service Accounts

List every account the platform uses to act on other systems. For each one, write down what it can do and what it actually needs to do. Automation built in a hurry often runs with domain admin rights because that was the quickest way to make a script work. Reduce those rights, rotate the credentials and alert on unusual use.

3. Integrations and Stored Tokens

Inventory every connector: monitoring, identity provider, HR, cloud, chat, remote support. Remove the ones nobody uses. For the rest, prefer scoped tokens with short lifetimes, store them in the platform’s secrets vault if it has one, and document who owns each integration. When the platform is patched for a serious flaw, rotate the tokens as part of the response.

4. Administrative Access

ITSM administrators can change workflows, approval rules and automation. That makes their accounts as sensitive as any infrastructure admin account. Require phishing-resistant multifactor authentication, keep the number of administrators small, and log every change to workflows and integrations to a system the administrators cannot edit.

5. Data in Tickets

Credentials, personal data and internal network details end up in ticket fields and attachments. Set retention rules for attachments, mask sensitive fields where the platform allows it, and teach agents to reject requests that include passwords. Periodic searches for patterns such as “password:” or private key headers will show how big the problem is.

A Short Risk Register Entry

If you add the ITSM platform to your register today, a first entry could look like this.

The numbers will differ for every organization. What matters is that the platform has an owner, a treatment plan and a review date.

Bring the Service Desk Into Security Reviews

The teams that run ITSM platforms and the teams that run security programs often sit apart. Closing that gap is mostly organizational: invite the platform owner to vulnerability review meetings, include the ITSM platform in penetration test scope, and make sure security advisories from the vendor reach both teams.

The service desk has become one of the most connected systems in the company. Treating it as an internal ticketing tool leaves a well-mapped, highly privileged system outside the security program, at a time when researchers, and the AI tools they use, are finding serious flaws in these platforms.