Notifications
Clear all
Topic starter
10/06/2026 10:34 pm
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.
NHIMG editorial — based on content published by SumSub covering an incident involving unauthorized activity in a support-related internal environment
By the numbers:
- The unauthorized activity was detected retrospectively during a security review conducted in January 2026, even though the incident occurred in July 2024.
Questions worth separating out
Q: What breaks when a third-party support platform can reach internal systems?
A: The boundary between external support and internal trust breaks first.
Q: Why do support environments matter to identity governance if production was not affected?
A: Support environments often hold customer data and staff access that are easier to overlook than production systems.
Q: How do you know if third-party support access is operating outside its intended boundary?
A: Look for mismatches between the scope of the support case and the systems the platform can touch, plus long-lived access paths with no clear expiry.
Practitioner guidance
- Map support-channel trust boundaries Inventory every external support platform, file intake path, and internal system it can touch.
- Segment support environments from customer-data systems Treat support-related internal environments as sensitive systems with narrow entitlements, separate monitoring, and limited data access.
- Review third-party access lifecycles Track supplier support access from approval through expiry, including emergency access and exception handling.
What's in the full article
SumSub's full incident update covers the operational detail this post intentionally leaves for the source:
- Timeline detail on how the malicious attachment reached the support-related internal environment
- Specific customer notification and investigation handling steps taken after discovery
- Control changes to technical support personnel access and monitoring capabilities
- Audit and assurance context from SOC 2 Type II, ISO/IEC 27001, and ISO/IEC 27017 / 27018
👉 Read SumSub's incident update on the support platform compromise →
Support ticketing platform exposure: what IAM teams should review?
Explore further
11/06/2026 2:40 am
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
