Public Relay

What a public relay does in a remote session path

A public relay is a fallback transport layer for session traffic when peers cannot establish a direct path. It does not create the session itself, but it becomes part of the communications route, which means the relay operator and its network path are now part of the trust and availability picture.

The key distinction is that a relay is usually about reachability, not authorization. It helps traffic get through NATs, firewalls, or asymmetric network conditions, but it also introduces another externally run service that the session depends on.

Why organisations use relays instead of direct connectivity

Public relays exist because direct peer-to-peer connectivity is not always reliable or even possible. In practice, they are often the simplest way to make remote access work across hostile networks, roaming endpoints, or tightly filtered environments.

That convenience comes with a trade-off. The relay can add latency, reduce performance consistency, and create an operational dependency on a third-party or centrally managed infrastructure component. For many teams, the relay is a pragmatic reachability control rather than a preferred steady-state architecture.

Security and trust implications of the relay path

Because the relay sits in the middle of traffic flow, it expands the attack surface around session establishment and transport availability. A relay does not automatically expose application data, but it does concentrate trust in a service that must be resilient, well monitored, and carefully constrained.

A relay path can also complicate assumptions about direct network trust. If the relay is abused, unavailable, or misconfigured, the result may be service degradation, session failure, or reliance on an unintended access route. The security question is less about the relay “being bad” and more about whether the organisation has intentionally accepted the extra dependency.

When a public relay is the right compromise

Public relays are most defensible when direct private connectivity is not available and the business still needs a dependable remote path. They are especially useful when reachability matters more than strict path control, or when the alternative would be no connection at all.

Security teams should treat the relay as an operational fallback, not a blanket default. Where a direct private path is feasible, it usually offers a cleaner trust boundary and fewer external dependencies. Where it is not feasible, the relay becomes a managed compromise that should be documented and monitored as part of the access design.

Risk and Threat Considerations

Public relays introduce concentration risk because many remote sessions may depend on the same intermediary service. If that service is slow, unavailable, abused, or misconfigured, users may lose access or be forced onto weaker alternative paths.

Failure mechanism: The relay becomes a single external hop in the access path, so outages, traffic shaping, interception concerns, or control failures at that hop can disrupt availability or weaken confidence in the session route.

Impact: Remote access can degrade or fail at scale, troubleshooting becomes harder, and the organisation inherits operational and trust exposure from infrastructure it does not fully control.

Practitioner Guidance

Why practitioners should care: A public relay is not just a network convenience, it is a dependency decision. Teams should decide whether the relay is an acceptable fallback for reachability, and whether the added latency and third-party exposure are worth the trade-off for the use case.

What to watch for: Treat relay usage as a signal that direct connectivity is failing or unavailable. If relay traffic becomes the default path rather than the exception, review whether the architecture, network policy, or remote access design needs a more direct and lower-dependency option.

Related resources from NHI Mgmt Group

• What is the difference between using a remote desktop tool's public relay model and connecting through a private network path?
• How do security teams detect when an agent is using public infrastructure as a relay?
• Why do still-valid secrets matter after public disclosure?
• How should security teams reduce NTLM relay risk in Active Directory?