Who is accountable for relay policy and access control in a tailnet?

The organisation operating the tailnet is accountable for defining relay policy, access controls, and deployment boundaries. Relays should be governed through ACLs, monitored like other infrastructure components, and reviewed as part of access architecture decisions. Operational ownership matters because a relay changes traffic flow, which affects performance, troubleshooting, and control visibility.

Why This Matters for Security Teams

Relay policy in a tailnet is not a networking footnote. It is part of the organisation’s access architecture because relays change how traffic moves, which devices can reach what, and what gets inspected or bypassed. That makes relay governance a security decision, an operations decision, and an audit decision at the same time. Current guidance from OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward accountable ownership, least privilege, and continuous review rather than informal infrastructure sprawl.

This matters because relays can obscure control boundaries if they are treated as “just connectivity.” In practice, a relay can broaden reach, alter trust assumptions, and complicate incident response if no one has explicit ownership for policy, logging, and change approval. That is especially risky when the tailnet supports secrets-bearing workloads, automation, or privileged administration. NHI Management Group’s research on the Ultimate Guide to NHIs shows that lifecycle and governance controls are where identity risks become operational risk, not after the fact. In practice, many security teams discover relay exposure only after a troubleshooting shortcut has already become a standing exception.

How It Works in Practice

Accountability should sit with the organisation operating the tailnet, but the work is usually split across security, platform, and infrastructure teams. Security should define the policy intent, such as which routes, peers, or services may traverse a relay. Platform teams should implement that intent in ACLs, route advertisements, and deployment guardrails. Operations should own monitoring, capacity, and break-glass procedures. The key is that relay permission is not an informal admin convenience; it is a governed control surface.

Practically, that means three things. First, define who can create or modify relay paths and under what approval criteria. Second, treat relay access like any other privileged control by reviewing it against role change, service change, and incident response needs. Third, log relay usage and compare it against expected topology so deviations are visible. The Top 10 NHI Issues highlights why visibility and lifecycle controls matter when identities or infrastructure components can expand access without a human sitting in the loop. For baseline control design, align with NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement, audit logging, and configuration management.

• Document the relay owner, approver, and operator for every environment.
• Apply ACLs to relay administration and relay usage separately.
• Review relay changes as part of access architecture, not only network operations.
• Monitor for unexpected route expansion, stale exceptions, and dormant relays.

These controls tend to break down in fast-moving engineering environments where relays are created for temporary debugging but never reclaimed because no one owns expiry enforcement.

Common Variations and Edge Cases

Tighter relay control often increases operational overhead, so organisations have to balance faster troubleshooting against stronger segmentation and review. That tradeoff is real, especially when distributed teams depend on relays for remote access, cross-environment testing, or incident support. Best practice is evolving, and there is no universal standard for exactly how much relay flexibility is acceptable.

One common edge case is a shared relay used by multiple teams. In that model, accountability can become blurred unless there is a single policy owner and separate operational operators. Another is the emergency or break-glass relay, which may be justified for resilience but should be time-bound, logged, and reviewed after use. For mature programmes, CIS Controls v8 is useful for mapping asset inventory, secure configuration, and access control expectations to relay governance. For broader identity lifecycle thinking, the Lifecycle Processes for Managing NHIs section is relevant because relays, like non-human identities, should have defined creation, review, and retirement points.

Where teams rely on relays to bypass normal network paths for convenience, policy quickly becomes inconsistent and visibility declines. That is where governance fails first.

Related resources from NHI Mgmt Group

• Who is accountable when an AI-assisted policy draft introduces an access control mistake?
• Who is accountable when an AI-generated authorization policy creates an access control failure?
• Who is accountable when an over-permissive access control policy exposes build tokens or deployment code?
• Who should be accountable for securing disconnected applications when access is managed through custom API automation?