An alternative path used when two endpoints cannot connect directly. In secure networking, the relay should preserve encryption and policy enforcement while accepting the trade-off of added latency, shared capacity, and another place where access governance must be defined.
Expanded Definition
Relay fallback is the controlled shift from a direct endpoint-to-endpoint connection to an intermediary path when routing, NAT traversal, firewall policy, or network reachability prevents the preferred path. In secure environments, the relay is not just a technical detour. It becomes part of the trust boundary and must preserve encryption, authentication, and policy enforcement throughout the session.
Usage of the term varies across vendors and architectures. Some products treat relay fallback as an automatic connectivity feature, while others frame it as a security decision that changes how traffic is governed, logged, and inspected. In identity-sensitive systems, the fallback path can affect how user sessions, service connections, or Non-Human Identity traffic are authorized, especially when certificates, tokens, or device trust are evaluated differently on relayed traffic. NIST guidance on digital identity, including the NIST SP 800-63 Digital Identity Guidelines, is useful here because fallback paths often alter the assurance context around a connection.
The most common misapplication is treating relay fallback as a harmless transport feature, which occurs when teams enable it without defining who can use it, what gets logged, and whether the relay is allowed to terminate or inspect protected traffic.
Examples and Use Cases
Implementing relay fallback rigorously often introduces extra latency and a new control point, requiring organisations to weigh connectivity reliability against tighter governance and performance overhead.
- Remote collaboration tools may use a relay when peer-to-peer connectivity fails, but the session should still enforce encryption, identity checks, and access policy at the relay boundary.
- Zero Trust environments may route sensitive sessions through a broker or relay when direct paths are blocked, with authorization decisions tied to user, device, and resource posture.
- Non-Human Identity workloads can fall back to a relay when service endpoints are segmented by firewall rules, but the relay must not become an uncontrolled credential forwarding path.
- OT or restricted enterprise networks may rely on relay fallback to support supportability and resilience, while keeping the relay within approved logging and segmentation requirements.
- Cloud-based access services may use a relay to bridge clients that cannot establish direct TLS connectivity, with configuration mapped to NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement, auditability, and system protection.
Why It Matters for Security Teams
Relay fallback matters because it changes where trust is anchored. When a direct connection fails, the fallback path can become the only path, which means policy enforcement, session logging, rate limiting, and identity validation must still hold under degraded conditions. If this is not designed carefully, the relay turns into an exception channel that bypasses normal network controls or weakens encryption expectations.
Security teams should treat relay fallback as a governance object, not merely an availability mechanism. That means deciding whether it is allowed for privileged sessions, whether it can carry secrets, whether it is acceptable for machine-to-machine traffic, and how it is monitored for abuse. This is particularly important in NHI environments, where service accounts, workload identities, and agentic systems may retry connections automatically and create traffic spikes or hidden dependency chains. The connection to identity assurance is also relevant when a relayed session needs to preserve the same confidence level as the original path, especially under guidance such as NIST SP 800-63 Digital Identity Guidelines.
Organisations typically encounter relay fallback as a security problem only after a direct-path outage or firewall change exposes an unreviewed relay route, at which point access governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Relay fallback affects how access is enforced when direct paths fail. |
| NIST SP 800-63 | Digital identity assurance matters when relayed sessions must preserve trust. | |
| NIST SP 800-53 Rev 5 | AC-17 | Remote access controls govern sessions that may traverse relays instead of direct links. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes no implicit trust in alternate network paths such as relays. | |
| OWASP Non-Human Identity Top 10 | Relays can become hidden trust points for NHI traffic and credential handling. |
Re-evaluate trust and authorization for every relayed session instead of inheriting direct-path assumptions.
