Treat every public tunnel as an access boundary, not a convenience feature. Require authentication, explicit routing rules, and a named owner before exposure begins. If the tunnel fronts a service that handles secrets, callbacks, or admin functions, add IP restrictions and request validation so the endpoint never relies on obscurity or informal team knowledge.
Why This Matters for Security Teams
Public tunnels can be useful for development, demos, and integration testing, but they also create a live path into internal services that may never have been designed for internet exposure. Security teams should treat them as temporary access points with explicit ownership, not as an informal workaround. The control objective is simple: reduce surprise exposure, ensure traceability, and make sure the service behind the tunnel is governed like any other externally reachable asset.
This matters because tunnel endpoints often bypass normal perimeter assumptions. A developer may publish a service for webhooks, mobile app testing, or partner validation, then leave it reachable long after the original task is complete. That creates a real risk of unauthorised access, data leakage, and accidental abuse of admin or callback functionality. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces asset governance, access control, and continuous monitoring as baseline expectations rather than optional hardening steps.
Teams commonly underestimate how quickly a tunnel becomes part of the application trust boundary. Once a tunnel is live, scanners, bots, and curious third parties can discover it if it is poorly protected, and the exposed service may be treated as internal even though it is no longer private. In practice, many security teams encounter tunnel risk only after a leaked callback URL, credential misuse, or unexpected service exposure has already occurred, rather than through intentional review.
How It Works in Practice
Effective governance starts before the tunnel is opened. The service owner should document why the tunnel exists, what system it exposes, who approved it, and when it will be removed. Security teams should require an approval path for anything that exposes development services to the public internet, even if the exposure is meant to be short-lived. For higher-risk services, routing should be constrained so the tunnel only forwards the specific host, path, or port required for the test case.
Authentication should be mandatory whenever the tunnel provides anything beyond a harmless static demo. That can mean SSO, one-time access controls, or identity-aware proxying, depending on the environment. If the service handles secrets, webhooks, admin panels, or privileged APIs, add IP restrictions, request validation, and strong logging so the team can distinguish legitimate test traffic from opportunistic probing. These expectations fit naturally with the CISA Zero Trust Maturity Model, which emphasizes explicit verification and least privilege across exposed resources.
- Assign a named owner and expiry date before the tunnel is enabled.
- Limit the tunnel to the narrowest route, port, or callback path required.
- Require authentication for any service that can read, write, or invoke privileged functions.
- Log requests, source addresses, and failures so exposure is auditable.
- Remove the tunnel as soon as the test or integration need ends.
Operationally, teams should also treat tunnel configuration as part of change control. A public tunnel that points to a development service can still reach databases, caches, or internal dependencies if the backend is overconnected. These controls tend to break down in fast-moving developer environments where the tunnel is created ad hoc, shared through chat, and left running after the original session has ended because ownership and expiry are not enforced.
Common Variations and Edge Cases
Tighter tunnel governance often increases friction for developers, requiring organisations to balance speed of testing against the risk of exposing internal services. That tradeoff is real, and current guidance suggests the answer is not to ban tunnels outright, but to classify them by sensitivity and apply stronger controls as the business impact rises.
Some tunnels support harmless preview sites, while others front production-adjacent functions such as payment callbacks, release automation, or identity workflows. Those higher-risk cases deserve extra scrutiny because a tunnel may effectively become a temporary internet-facing API. If the service processes personal data or payment-related content, align tunnel approvals with privacy and payment controls, and consider whether the exposure should follow the same review path as any other externally reachable endpoint. For identity-heavy services, the tunnel may also become a weak link in session handling or credential protection if request validation is missing.
There is no universal standard for tunnel expiry periods, but best practice is evolving toward short-lived access, central visibility, and mandatory revocation. Public tunnelling should never be the default answer for external collaboration when a safer alternative such as a staging environment, a restricted VPN, or a controlled reverse proxy is available. The OWASP API Security Project is relevant where tunnels expose APIs, because request trust, authentication, and authorisation remain critical even when the endpoint is “only for development.”
Security teams should assume that any tunnel can be discovered, reused, or misrouted if governance is weak. The right question is not whether the tunnel is temporary, but whether its exposure is controlled well enough that temporary does not become forgotten.
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 surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Public tunnels must be tracked as exposed assets with clear ownership. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Tunnels should follow explicit verification and least-privilege access rules. |
| OWASP Non-Human Identity Top 10 | Tunnels often expose services that use secrets, tokens, or machine credentials. | |
| NIST AI RMF | If tunnels expose AI or automation services, governance should cover misuse and access risk. | |
| PCI DSS v4.0 | 1.2.1 | Tunnel exposure of payment-related services requires network exposure controls. |
Treat every tunnel as a zero-trust access path and verify each request before allowing reachability.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
