Your ITSM platform could be the way in for a cyberattack

Your ITSM platform holds personal data and connects to systems across the business, which makes it a target worth protecting like any other business-critical system. A recent ServiceNow API exposure is a good moment to ask two questions: who controls the security boundary around your service data, and how far can a single configuration mistake reach? The answers depend less on the vendor and more on the architecture.

In early June, ServiceNow told customers that a software bug had left some of their data reachable over the internet. The issue came down to a single API endpoint that was set up without authentication, so requests could be made to it without a password or credential. ServiceNow patched affected instances on June 5 and changed the endpoint configuration to limit access to authenticated users.

According to public reporting, the endpoint at the centre of it was /api/now/related_list_edit/create, which was configured by default to not require authentication. Security teams that went looking found requests to that endpoint coming from a specific IP address, which gave them something concrete to check their logs against. ServiceNow said it observed anomalous activity and, for a subset of customers, evidence of successful queries against instance tables, and that it notified those customers directly.

There is an important detail worth being precise about. ServiceNow has since said it believes the activity is attributable to security researchers doing bug bounty work rather than malicious attackers, and that the researchers told them no data was used or retained. So this is not a confirmed case of stolen customer data. What it is, clearly, is an unauthenticated endpoint that was exposed to the internet, and one that was reportedly first flagged back in April before the report was closed. The exposure sat in place for a while before it was fixed.

That is the part worth sitting with, because it is true regardless of who happened to find the door open.

Why this matters more than a single bug

An ITSM platform is no longer just a ticketing system. It holds personal data, it connects to HR and IT systems, and it powers automated workflows across the organisation through a growing number of integrations. Support tickets alone routinely contain passwords, keys, and credentials. That makes the platform a high-value target, and it means the platform has to be governed as a business-critical system with the regulatory compliance and security posture that implies.

Once personal data lives inside the ITSM tool, that data is in scope for GDPR. A weak or unmanaged API is not a minor technical detail in that context. It is an exposure of regulated data, with the reporting obligations and the risk that come with it.

The honest version of the lesson: ServiceNow is a capable platform used by thousands of large organisations, and configuration mistakes can happen to any vendor. The question for a buyer is not whether a vendor will ever have a bug. It is how the architecture limits the blast radius when one occurs, and how much control the customer has over their own access boundary.

Where architecture changes the picture

This is where the design of the platform matters. In a shared, multi-tenant SaaS model, a single misconfigured endpoint can affect many customers at once, because the access boundary is owned and operated by the vendor. When something is set incorrectly at the platform level, the exposure is not contained to one organisation.

ITSM360 runs entirely inside each customer's own Microsoft 365 tenant. APIs are reached through Microsoft Entra app registrations, where access is governed per customer with their own client ID and client secret. That is a one-to-one authentication boundary rather than a shared one. A configuration in one customer's tenant does not create exposure across a shared platform, because there is no shared platform sitting in front of everyone's data. Each tenant is its own boundary, controlled by the customer.

It also means the access controls are not a separate layer the ITSM vendor has to build, secure, and keep patched. They are the same Microsoft identity and security controls the organisation already runs across the rest of its estate: Entra, conditional access, audit logging in the tenant, and the wider Microsoft security and compliance framework. For a security team, the surface they are reviewing is one they already know how to govern, rather than a separate vendor environment with its own rules.

What that gives a security or compliance team

• A per-customer access boundary. Endpoints are authenticated against each tenant's own client credentials, so a problem is scoped to a single tenant rather than a shared platform.
• Data that stays in the tenant. Service data is not copied out to an external SaaS environment, which keeps it inside the organisation's own GDPR and data-residency perimeter.
• Governance through tools already in place. Access, logging, and conditional access run through Microsoft Entra and the tenant's existing security controls, not a parallel system to monitor.

The takeaway for anyone reviewing their ITSM

If you run any ITSM platform, the practical steps from this incident are the same ones security teams are already taking: review API access logs, confirm that endpoints handling business data require authentication, and treat configuration findings with the same seriousness as software vulnerabilities. None of that is specific to one vendor.

The longer-term question is structural. As ITSM holds more regulated data and connects to more systems, the access boundary around it becomes part of your compliance posture. It is worth asking who controls that boundary, how widely a single mistake can reach, and whether the platform's security is something you govern yourself or something you inherit from a vendor's shared environment. Those are reasonable questions to bring to any evaluation, including ours.

See how ITSM360 keeps your service data inside your own tenant

A short walkthrough of the architecture, the per-tenant authentication model, and how it fits the Microsoft security and compliance controls you already run.

Sources

• TechCrunch, "ServiceNow tells customers a bug left some of their data exposed to the internet" (10 June 2026)
• SecurityWeek, "ServiceNow Patches Vulnerability Exploited Against Some Customers" (10 June 2026)
• Grip Security, "ServiceNow Breach: 5 Key Things Security Teams Need to Know" (10 June 2026)