TL;DR: A malicious attachment sent through a third-party support ticketing platform enabled limited unauthorized access to a support-related internal environment, exposing mainly names and in some cases email addresses or phone numbers, while production systems and higher-risk data were not affected, according to Sumsub. The incident shows how support workflows can become the weak link when internal access boundaries and retrospective detection do not keep pace.
Editorial analysis by NHI Mgmt Group, based on content published by SumSub: “Security Incident Update”.
Key questions
Q: What breaks when support platforms are treated as low-risk systems?
A: Teams miss the fact that support queues often contain passwords, API tokens, incident details, and other sensitive operational data.
Q: Why can support-environment exposure still matter if production systems were not affected?
A: Because support environments often contain identity-linked data and escalation context that can be abused even without touching core applications.
Q: What do security teams get wrong about monitoring third-party support workflows?
A: They often monitor for major production incidents but under-invest in the service channels that sit beside them.
Practitioner guidance
- Harden third-party support access boundaries Segment support environments from production identity systems and restrict what a support platform can reach by default.
- Reduce support data exposure Minimise the personal data stored or surfaced in support tooling, and separate routine case handling from records that carry higher-risk identity attributes.
- Review support access controls regularly Revalidate who can submit, receive, open, and escalate support attachments or cases, including partner access and technical support personnel.
Bottom line: Support workflows can become a separate exposure path even when production identity systems remain untouched.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Support-channel compromise is an identity governance problem, not just a ticketing problem. The attack path ran through a third-party support workflow, which means the control failure sits at the boundary between external intake and internal trust. When support channels can reach internal environments with insufficient isolation, the organisation has effectively extended identity trust to a supplier-mediated surface. Practitioners should treat support intake as part of the identity perimeter, not as an operational exception.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a supplier support workflow exposes customer data?
A: Accountability usually sits with the organisation that allowed the trust boundary to exist, even if a supplier provided the platform. Security, IAM, support operations, and vendor risk all share responsibility for scoping access, monitoring the environment, and ensuring revocation. Frameworks such as NIST CSF and OWASP NHI help assign that control ownership clearly.
👉 Read our full editorial: Sumsub support ticket incident exposes a support environment gap
Support tooling is part of the identity perimeter, not an administrative back office. When a third-party ticketing platform can mediate access into an internal environment, the support channel has become an identity boundary that deserves lifecycle, logging, and authorization controls. The practical implication is that IAM teams need to govern support access as a distinct trust domain, not as a minor operational exception.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations treat support access controls differently from general IAM controls?
A: Yes. Support access needs its own lifecycle because it usually involves external parties, temporary escalations, and non-production data paths. The right model is separate authorization, tighter segmentation, and explicit review of who can interact with tickets, files, and internal support environments.
👉 Read our full editorial: Sumsub support ticket incident exposes a support environment gap