Notifications
Clear all
Topic starter
14/07/2026 6:06 pm
TL;DR: Relay spam against Zendesk-style support systems can turn trusted ticket receipts into unwanted messages, with attackers using public-facing ticket forms and legitimate return addresses to bypass spam filtering, according to Swarmnetics. The governance lesson is that convenience features become an abuse path when verified-user controls are optional rather than default.
NHIMG editorial — based on content published by Swarmnetics: Zendesk Incident Demonstrates How “Relay Spam” Can Hit Support Systems, but How Big Is the Risk?
Questions worth separating out
Q: How should security teams handle anonymous ticket submission in support systems?
A: Allow anonymous ticket submission only when the business need is clear and the trust boundary is tightly controlled.
Q: Why do support systems create identity and trust risk even without account compromise?
A: Because the risk comes from workflow trust, not just login compromise.
Q: What do organisations get wrong about spam abuse in helpdesk tools?
A: They often focus on content filtering and ignore the origin control.
Practitioner guidance
- Restrict ticket creation to verified users Disable anonymous ticket submission where the support function does not require it, and define an exception process for any customer-facing use case that truly depends on public intake.
- Separate public intake from trusted outbound messaging Ensure that receipt and case-update messages generated from public forms do not inherit the same trust treatment as authenticated support interactions, especially in mail filters and SOC review logic.
- Review support workflows as identity-adjacent assets Inventory which portals, helpdesk tools, and case systems can originate messages, then apply the same governance review you would use for externally facing accounts and service identities.
What's in the full analysis
Swarmnetics' full analysis covers the operational detail this post intentionally leaves for the source:
- How the relay spam pattern works across specific support platforms and message flows.
- The exact default settings that make anonymous ticket creation possible in common helpdesk deployments.
- The practical trade-offs between public intake convenience and verified-user gating.
- The vendor's observations on which message characteristics were most likely to slip through spam controls.
👉 Read Swarmnetics' analysis of Zendesk relay spam and support system abuse →
Relay spam in support systems: are your ticket controls keeping up?
Explore further
14/07/2026 6:11 pm
Support portals are identity systems in disguise. When a ticketing platform can originate trusted outbound messages from an unauthenticated public form, it is functioning as an identity-bearing communication channel, not just a service desk. That means access governance has to extend beyond employee directories and privileged accounts to include externally reachable support workflows. Practitioners should treat support origin controls as part of IAM and messaging trust.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who is accountable when a public support workflow is abused for trusted-message spam?
A: Accountability usually sits with the owners of the support platform, the identity team, and the security function together. The practical failure is leaving a trusted outbound path open to anonymous input. Governance frameworks should require clear ownership for support-channel access, exception approvals, and abuse monitoring.
👉 Read our full editorial: Zendesk relay spam shows support systems can be abused as trusted senders
