How do hybrid identity teams decide between direct network rules and tunnels?

Why This Matters for Security Teams

Choosing between direct network rules and tunnels is really a decision about who owns the path, how much of it is observable, and whether access can be governed at runtime. Direct rules are easier to audit when customer networks support stable allowlisting and clear route ownership. Tunnels can reduce friction, but they often hide dependency chains and make incident response slower. That tradeoff matters because NHI exposure is already common: NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.

Security teams often get this wrong by treating tunnels as a convenience layer instead of a temporary exception. In a zero trust model, access should be explicit, narrow, and reviewable, which is consistent with NIST SP 800-207 Zero Trust Architecture. The practical question is not whether a tunnel works, but whether it can be governed as reliably as a direct rule. In practice, many security teams encounter tunnel sprawl only after an outage, audit finding, or third-party incident has already made the exception visible.

How It Works in Practice

Start by classifying the traffic path as either stable production connectivity or temporary exception handling. Direct network rules are appropriate when the destination is known, the route ownership is clear, and the customer environment can support deterministic allowlisting. That makes change control, monitoring, and incident scoping much easier. Tunnels, by contrast, should be treated as constrained overlays for testing, migration, or environments where the network team cannot yet provide a stable route.

In operational terms, the better control is the one that preserves visibility and makes access decisions enforceable at the right layer. For production paths, that usually means explicit source and destination rules, documented ownership, and reviewable change windows. For tunnels, teams should require an exception record, a time limit, monitoring, and a rollback plan. This aligns with the broader NHI governance patterns documented in Top 10 NHI Issues, especially where access paths outlive the original use case.

• Use direct rules when the customer can maintain static routes, stable IP ranges, and clear responsibility for changes.
• Use tunnels only when direct routing is not feasible and the exception can be tightly monitored.
• Require logging at both ends so the team can trace source, destination, and duration.
• Set expiry dates for tunnels and review them as part of access recertification.
• Prefer direct rules when the path is part of business-as-usual production traffic.

Where routing decisions intersect with secrets, service accounts, or API keys, the underlying identity risk becomes more important than the transport choice. NHIMG research on the 52 NHI Breaches Analysis shows how quickly weak identity hygiene turns a networking exception into a broader incident. These controls tend to break down when the tunnel becomes the default production path because the exception stops being temporary and starts functioning as hidden infrastructure.

Common Variations and Edge Cases

Tighter network control often increases operational overhead, requiring organisations to balance predictable governance against deployment speed. That tradeoff is real, especially when multiple customer environments have different firewall standards, fragmented ownership, or inconsistent change processes. Current guidance suggests using the most governable option, not the most convenient one, but there is no universal standard for this yet.

There are a few common edge cases. Shared hosting and heavily regulated customers may insist on direct allowlisting only, which favours static rules even when the implementation takes longer. Migration projects sometimes start with tunnels and later move to direct routes once the target environment stabilises. In highly constrained partner environments, a tunnel may be acceptable if it is explicitly documented, time-bound, and monitored. The important point is to avoid normalising exceptions, because every permanent tunnel weakens route ownership and complicates audit evidence.

For teams handling many third-party integrations, the best practice is evolving toward a formal decision record that captures business need, network ownership, expiry, and monitoring requirements. That record should be reviewed alongside access governance, not left to network operations alone. If the routing choice cannot be justified in terms of control, visibility, and revocation, it is probably the wrong choice.

Related resources from NHI Mgmt Group

• How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
• How do teams decide between JWT, OAuth, and federated workload identity?
• How should security teams decide between centralized and decentralized identity management?
• How should teams decide between Authentik and Keycloak for self-hosted identity?