Look for changes in traffic shape, not just outages. Unexpected encrypted connections, unusual high-port egress, or bandwidth patterns that do not match the device’s normal role are strong indicators of abuse. Because the device may still look healthy, detection must focus on behaviour and destination patterns rather than service uptime.
Why This Matters for Security Teams
A connected device that has been turned into a relay can remain online, responsive, and apparently healthy while quietly moving traffic for an attacker. That makes this issue easy to miss if monitoring is limited to uptime, service checks, or simple device health telemetry. Security teams need to treat traffic behaviour as a primary signal, especially when a device begins to communicate in ways that do not match its intended role.
This matters because relay abuse often sits between access compromise and broader network misuse. It can support command channels, proxying, lateral movement, data exfiltration, or hiding the origin of malicious activity. A device does not need to be fully owned to be useful to an attacker; partial abuse is often enough. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to detect anomalous activity patterns, not only known-bad signatures.
Practitioners often assume that if a device is still functioning, it is not involved in abuse. In practice, many security teams encounter relay activity only after unusual egress has already been used to obscure another compromise.
How It Works in Practice
Relay abuse is usually identified by comparing a device’s observed communications against its expected baseline. The key question is not just whether the device is sending traffic, but whether the destination, protocol, timing, and volume are consistent with its normal function. A smart camera, badge reader, or building controller should not suddenly behave like a general-purpose network path to high-port external services or unfamiliar cloud endpoints.
Operationally, teams should combine network telemetry, asset context, and identity-aware logging. That means correlating outbound flows with device type, location, firmware version, and known business purpose. If the device normally talks only to a small set of internal services, then outbound encrypted sessions to diverse destinations deserve scrutiny. Where possible, analysts should inspect:
- Unexpected long-lived encrypted connections from a low-function device
- High-port or non-standard egress that does not match the device role
- Traffic volume spikes that are inconsistent with the device’s normal duty cycle
- Frequent destination changes, especially across geographies or cloud providers
- Protocol mismatches, such as device classes that suddenly initiate generic tunnel-like behaviour
Detection works best when network monitoring is tied to asset inventory and segmentation policy. Devices that are supposed to be tightly constrained should have explicit egress expectations, and deviations should feed alerting or automated containment. MITRE’s ATT&CK knowledge base remains useful for mapping relay-like activity to broader post-compromise techniques, especially when the device is being used to hide source, pivot traffic, or support command-and-control.
In parallel, teams should look for management-plane abuse, credential misuse, and new persistence on the device itself. A relay is often a symptom of broader compromise, so traffic anomalies should be paired with firmware integrity checks, configuration drift review, and authentication logs. These controls tend to break down when the organisation lacks accurate device inventory or when IoT and operational technology traffic is not centrally observed.
Common Variations and Edge Cases
Tighter monitoring often increases telemetry volume and investigation overhead, requiring organisations to balance detection depth against operational noise. That tradeoff is especially sharp in environments where devices are chatty by design, such as industrial networks, building management systems, or remote field equipment.
There is no universal standard for what “normal” looks like in every connected device class, so current guidance suggests using role-based baselines rather than one-size-fits-all thresholds. Some devices legitimately use encrypted outbound channels, cloud relays, or vendor-managed update paths. Those cases are not automatically malicious, but they do require stronger allowlisting, firmware provenance checks, and periodic review of whether the dependency is still justified.
The hardest edge cases are devices that legitimately bridge networks, such as gateways, protocol converters, and remote support appliances. In those environments, relay-like traffic may be expected, which makes behavioural context essential. Security teams should verify whether the device is supposed to relay traffic, for whom, under what conditions, and with what monitoring. The NIST Computer Security Resource Center is a useful reference point for applying control baselines and logging practices in these mixed environments.
Where OT uptime is prioritised over visibility, abuse can persist because network changes are feared more than suspicious traffic. Where third-party maintenance is embedded into normal operations, relay abuse can hide inside approved remote access unless those paths are tightly scoped and reviewed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is central to spotting relay-like traffic anomalies. |
| MITRE ATT&CK | T1090 | Proxy/relay behaviour maps directly to traffic relaying and proxying techniques. |
Investigate devices showing proxy-like egress and correlate with other compromise indicators.
Related resources from NHI Mgmt Group
- How do security teams know if a connected app is overprivileged?
- How do security teams know whether an OAuth-connected app is operating outside its intended boundary?
- How do security teams know whether a policy engine can be abused for cloud credential theft?
- How do security teams know whether a privileged access appliance has been abused?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
