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.
At a glance
What this is: This article shows how relay spam can exploit support systems that let unauthenticated users create tickets and trigger trusted outbound messages.
Why it matters: IAM and security teams should treat helpdesk and support portals as governed trust surfaces, because weak ticket creation controls can be used to bypass spam filters and burden operations.
Context
Support portals often sit at the boundary between customer convenience and security control. When they allow unauthenticated ticket creation, the system may inherit the trust of the brand and the mail path without the governance needed to prevent abuse. In this case, the risk is not classic credential compromise but misuse of a trusted workflow to send messages that look legitimate.
That matters for IAM and NHI governance because service workflows, notification systems, and helpdesk integrations can become identity-adjacent abuse channels even when no account takeover occurs. The security question is whether the organisation has made verified-user access the default for a channel that can generate outward-facing trust.
The article suggests this starting position is common rather than exceptional, which is why the control gap deserves attention.
Key questions
Q: What breaks when support tickets can be created without verified users?
A: The support channel stops being a controlled service workflow and becomes a trusted message relay. Attackers can trigger legitimate-looking outbound mail through a brand domain without owning an account, which weakens filtering and creates nuisance or phishing-adjacent abuse. The core failure is confusing reachability with authorization.
Q: Why does trusted support mail create risk even when no account is compromised?
A: Because the recipient sees mail from an expected system and is more likely to allow it through spam and security checks. The attacker is not stealing a session, but abusing the organisation’s own trust signals. That makes the control problem one of workflow governance, not only authentication.
Q: What are the signs that a support platform is being abused for relay spam?
A: Look for sudden bursts of tickets from many unrelated addresses, repeated strange or random subject lines, and large volumes of outbound receipts with no matching support demand. Those patterns suggest the ticketing channel is being used as a delivery mechanism rather than a genuine service queue.
Q: Should organisations allow anonymous support tickets if spam filtering is strong?
A: Only when the business can tolerate the abuse risk and the workflow cannot generate trusted outbound mail with useful content. Spam filtering helps, but it does not fix the trust boundary problem. If the system can send legitimate-looking responses, verified-user gating is the more reliable control.
Technical breakdown
How relay spam exploits trusted support workflows
Relay spam relies on the support platform’s normal ticketing workflow. A public form accepts a return address, the system creates a case, and the platform sends receipts or follow-up messages from a domain that recipients trust. That trust often defeats automated filtering because the mail originates from a legitimate service rather than a disposable sender. The abuse is therefore not about breaking authentication in the classic sense. It is about turning a sanctioned workflow into a message relay that carries the platform’s trust with it.
Practical implication: treat ticket intake and outbound notifications as separate trust decisions, not as one default workflow.
Why optional verification becomes an abuse multiplier
If verified-user checks are optional, the ticketing system effectively treats reachability as permission. That means anyone who knows a valid email address can trigger a trusted message path, even if they cannot log in. The control failure is not a missing spam filter, but an absence of identity gating at the point where the workflow is initiated. Once that gate is absent, the platform becomes useful for nuisance traffic, targeted helpdesk abuse, and potential denial of service through volume.
Practical implication: require verified identity or equivalent proof before a ticket can generate trusted outbound communication.
Why file attachments and URLs change the threat boundary
The article notes that if attachments and text URLs are removed, the attacker’s ability to turn support spam into a broader payload delivery channel is sharply reduced. That distinction matters because a trusted receipt without content is mostly an annoyance, while a trusted receipt carrying files or links can become a phishing or malware delivery mechanism. Support systems therefore need content controls as well as identity controls, because the risk shifts materially when the system can relay richer payloads through a trusted sender.
Practical implication: constrain what unauthenticated support submissions can carry before the workflow reaches outbound delivery.
Threat narrative
Attacker objective: The attacker’s objective is to misuse a trusted support channel to deliver unwanted messages that bypass normal filtering and create operational disruption.
- Entry occurs through a public support form that accepts tickets without login and allows any return email address.
- The attacker uses the trusted support workflow to generate legitimate-looking outbound mail that reaches the selected recipient.
- Impact is nuisance spam and operational load, with a wider risk of helpdesk abuse if richer content or attachments are permitted.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Trusted workflow abuse is a governance problem, not just a mail problem. Support portals can create legitimate outbound trust even when no account takeover has occurred. That makes the control surface broader than spam filtering alone, because the system itself is acting as the trusted sender. Practitioners should treat any customer-facing workflow that can emit email as part of the identity and trust architecture.
Verified-user gating should be the default for any support channel that can trigger outbound trust. The article shows that convenience settings can become abuse paths when organisations allow anonymous ticket creation by default. This is especially relevant where support systems sit next to identity recovery, account access, or other high-trust workflows. Practitioners should assume that unauthenticated intake is a policy choice, not a harmless product default.
Relay spam is a low-complexity signal of a larger control gap: trust and reachability are being confused. A valid email address is not a permission model, and a support receipt is not proof of legitimate intent. Once that distinction is blurred, the organisation has no reliable boundary around outbound trust. The practitioner conclusion is to align ticket creation rules with the same governance discipline used for other externally reachable identity surfaces.
Support-system abuse belongs in the same governance conversation as NHI and service-account controls. The mechanism differs, but the pattern is familiar: a trusted system action is being used outside its intended authorization boundary. That is why helpdesk platforms, notification services, and workflow automation should be inventoried as trust-bearing systems, not just operational tools. The practical conclusion is to manage them as part of the broader identity and access programme.
What this signals
Relay spam shows how customer support platforms can become trust amplifiers when identity checks are treated as optional. The practical governance lesson is to classify externally reachable support workflows as security-relevant communication systems, not just service desks. Once they can originate branded outbound mail, they belong in the same control review as other trust-bearing identity surfaces.
Verified-user defaults are the cleaner control boundary than message filtering alone. If a workflow can be reached anonymously and can emit trusted responses, the organisation has already accepted an abuse path. Practitioners should align ticket intake policy, outbound messaging rights, and exception handling so that convenience does not outrank trust boundary design.
For practitioners
- Enforce verified-user ticket creation Disable anonymous ticket submission for channels that generate trusted outbound email, especially where the system can reply from a branded domain.
- Separate intake trust from delivery trust Review support workflows so the act of opening a ticket does not automatically confer permission to send trusted receipts or follow-up messages.
- Restrict payload-bearing submissions Remove attachments and link fields from unauthenticated forms where the business does not need them, and log every exception.
- Tune abuse detection for relay patterns Monitor for bursts of tickets from distributed email addresses, repeated subject patterns, and repeated outbound replies that resemble message relay rather than support demand.
Key takeaways
- Relay spam abuses the trust of support systems rather than breaking into them, which makes workflow governance more important than mail filtering alone.
- The article shows that anonymous ticket creation and trusted receipts can create an abuse path even when the attacker gains little direct capability.
- The most effective control is to make verified-user access the default for any support channel that can generate outward-facing trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on whether anonymous users should be authorised to trigger trusted support workflows. |
| Recommendation — Apply PR.AA-05 to ensure only verified users can trigger trusted outbound support communications. | ||
| CIS Controls v8 | CIS-5 — Account Management | Ticket creation abuse reflects weak account and access governance around support channels. |
| Recommendation — Use CIS-5 to restrict support access paths and remove anonymous entry points that can be abused. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The support form is a misconfigured trust surface when it allows unauthenticated message relay. |
| Recommendation — Treat relay-capable support forms as misconfigured interfaces and harden the submission workflow. | ||
Key terms
- Relay Spam: A form of abuse where an attacker uses a legitimate service workflow to send unwanted messages through a trusted sender. The service is not compromised in the usual sense, but its normal communication path is exploited to bypass filtering and make the message look more credible.
- Trusted-sender abuse: A phishing technique that exploits the legitimacy of a known sender, shared mailbox, or familiar collaboration context to increase user trust. In practice, it turns existing identity relationships into delivery infrastructure for credential theft, session hijacking, and follow-on compromise.
- Verified User Gating: Verified user gating requires a user or sender to authenticate before they can trigger a privileged workflow. In support systems, it narrows the attack surface by preventing anonymous parties from causing trusted messages or actions to be generated.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the wider security programme they run every day.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org