They should treat them as both, because the initial issue is device enrollment and the downstream issue is traffic relaying. Endpoint teams control installation and software policy, while network teams need visibility into whether the endpoint is acting as an exit node. The best response is coordinated governance across device, proxy, and internal access controls.
Why bandwidth-sharing apps belong in both device and network control conversations
Bandwidth-sharing apps are not just another consumer utility on a laptop or phone. They can change how a device behaves on the network, especially if they create relay paths, background tunnels, or outbound traffic patterns that mimic normal browsing. That makes the risk split across endpoint policy, traffic inspection, and the organisation’s view of what an approved device is allowed to do.
The practical question is not whether the app is “really” a network issue or an endpoint issue. It is whether the organisation can prevent unapproved installation, detect relay behaviour, and stop the device from becoming part of an external traffic path. Those are different controls, and they fail in different ways.
What makes the endpoint side the first line of defence
The endpoint is where the app is installed, granted permissions, and allowed to run. If the device is unmanaged, has permissive software policy, or allows broad user installation rights, the app may appear long before the network team sees anything unusual. That is why installation control, application allowlisting, privilege restriction, and endpoint telemetry are the first questions to answer.
Endpoint visibility should focus on whether the software is present, whether it can auto-start, whether it requests proxy or VPN-style permissions, and whether it introduces a user-space service that can stay active after login. A device that can relay traffic is already a policy problem, even if no malicious use has been observed yet.
Top 10 Endpoint Security Risks is a useful companion here because it frames installation abuse, local privilege weakness, and software tampering as core endpoint failure modes.
Why the network team still needs to treat it as a traffic-relay problem
Once a device starts relaying traffic, the network question becomes whether the organisation can recognise that the endpoint is acting as an exit node, proxy, or forwarding path. That requires visibility into outbound patterns, unusual sustained sessions, destination diversity, and policy mismatches between the device’s normal role and its observed behaviour.
This is not only about blocking a known bad domain. A relay app may use legitimate destinations, encrypted sessions, or cloud infrastructure that blends into routine traffic. The control problem is therefore less about signature matching and more about correlating device identity, proxy logs, and egress behaviour so the traffic path is explainable.
Endpoint Security Guide helps here because it ties host telemetry, host isolation, and network containment together rather than treating endpoint and network controls as separate silos.
How organisations should decide what to govern, monitor, and restrict
Bandwidth-sharing apps should be handled through coordinated governance across software policy, device trust, and egress control. If the device is corporate-managed, the app should normally be subject to software approval rules and monitored for privilege escalation, persistence, and unmanaged outbound connections. If the device is personal or lightly managed, the tolerance for relay-capable software should be even lower because enforcement and attribution are weaker.
The key operational decision is whether the organisation is trying to stop installation, limit execution, or detect abuse after the fact. Stopping installation is strongest, but only works when software policy is enforced. Limiting execution helps when the software is needed for a legitimate business reason. Detection is the fallback, not the primary control, because by the time the device is relaying traffic the exposure already exists.
Device Trust and Posture Guide supports this view by showing how posture and compliance signals should influence access and trust decisions. Endpoint Hardening Checklist is also relevant because hardening is what turns policy into an enforceable baseline.
Risk and Threat Considerations
These apps can create a hidden trust boundary shift: a normal endpoint becomes part of an external routing path, which increases exposure for data leakage, policy evasion, and abuse of legitimate network trust. The risk grows when the organisation has weak software controls or cannot distinguish approved business traffic from user-installed relay behaviour.
Failure mechanism: A user installs or enables relay-capable software on a managed device, the software establishes persistent outbound connectivity, and the organisation lacks enough endpoint or egress visibility to recognise that the machine is forwarding traffic for others.
Impact: The device may be used as an exit node for unwanted traffic, which can weaken attribution, complicate incident response, and create reputational or legal exposure if abusive traffic is seen as originating from the organisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Software Inventory | Bandwidth-sharing apps need software inventory and approval control on endpoints. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardened endpoint baselines reduce unapproved installation and persistence paths. | |
| CIS-8 — Audit Log Management | Detecting relay behaviour depends on logs from endpoints and egress controls. | |
| Recommendation — Inventory and approve relay-capable software before it can run on managed devices. Enforce secure endpoint baselines that block unapproved relay and tunnelling software. Collect endpoint and proxy logs that can reveal unusual traffic-relay behaviour. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Relay apps are a least-functionality problem when they are not needed for business use. |
| AC-6 — Least Privilege | Local privilege often determines whether relay software can install or persist. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Traffic-relay abuse is best found by reviewing proxy and endpoint audit records. | |
| Recommendation — Disable unnecessary software functions and block relay-capable tools by default. Limit user privilege so relay-capable software cannot self-authorise persistence. Review logs for device behaviour that indicates proxying, tunnelling, or exit-node use. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Device and software trust decisions depend on access control and managed-device rules. |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Bandwidth-sharing apps become visible when network monitoring spots unusual relay behaviour. | |
| Recommendation — Tie device trust and software execution decisions to managed access control policies. Monitor egress patterns to detect endpoints acting as forwarding or exit nodes. | ||
Practitioner Guidance
What to verify: Confirm whether software installation is centrally controlled, whether local admin rights are necessary for persistence, and whether proxy or tunnelling behaviour is visible in endpoint or network logs. If you cannot answer those three questions, you do not yet have a usable control model.
Decision rule: If the app can install without approval and can send traffic through the organisation’s egress, treat it as both an endpoint control issue and a network detection issue. If you can only address one side, prioritise endpoint restriction first because it prevents the relay function from ever becoming active.
Practitioner takeaway: The right response is not to choose one control plane, but to make sure endpoint policy, device trust, and network visibility all agree on what a legitimate device is allowed to do.
Related resources from NHI Mgmt Group
- Should organisations treat 5G network security as an IT control issue or a third-party risk issue?
- Should organisations treat certificate expiry as an operational risk or a security risk?
- When should organisations treat LDAP-integrated apps as high-risk systems?
- Should organisations treat shadow AI as a security risk or an innovation issue?