The "No-Root" Enterprise Compliance Angle: Securing Developer Tunnels in 2026

The developer tunnel started life as a convenience: a quick way to put a local dev server on the public internet so a webhook provider, a teammate, or a client could reach it. In 2026 it sits squarely inside the security team’s field of view. Zero-trust programs and tighter DevSecOps pipelines mean that anything creating a public path into a workstation gets asked the same question: who approved this, and what can it touch?

The popular answer is “run it without root.” That is a good instinct, but it is only half of the story. Running a tunnel agent as an ordinary user genuinely shrinks the damage a compromised agent can do. It does not, by itself, make a tunnel compliant, and as we’ll see below, the same property makes these tools attractive to attackers. This guide separates what rootless tunneling really gives you, which tools support it, and what a defensible enterprise program looks like.

Why Security Teams Scrutinize Developer Tunnels

Tunnels are not suspicious because they are exotic. They are suspicious because they are ordinary, legitimate, and encrypted.

• MITRE ATT&CK catalogs Protocol Tunneling (T1572) as a technique for concealing traffic by wrapping it inside another protocol. It also lists ngrok as software that threat actors have used in several campaigns, including for lateral movement and data exfiltration.
• Cloudflare’s free TryCloudflare feature has been a recurring abuse target. Proofpoint reported in 2024 that malware delivery through it had grown since it became popular with criminals in 2023. Securonix documented a 2025 campaign that hosted payloads on trycloudflare.com subdomains. Cofense reported in March 2026 that incidents involving Cloudflare Tunnels and Workers peaked in 2025.
• As recently as August 2026, incident responders at SpearTip reported seeing attackers use Quick Tunnel subdomains to host malware, stage payloads, and support post-compromise activity. Their advice: monitor outbound connections to *.trycloudflare.com across DNS, proxy, firewall, and EDR telemetry.
• Attackers can also run cloudflared on a compromised machine using only a tunnel token, as GuidePoint documented, and detection vendors now ship rules for it, such as Elastic’s prebuilt Potential Protocol Tunneling via Cloudflared rule.

The takeaway for defenders: a developer tunnel and an attacker’s tunnel can look identical on the wire. Policy has to distinguish them by who authorized it and where it connects, not by how it behaves.

For a CISO-side view of the same problem, see our earlier piece, Why CISOs Are Blocking ngrok.

What “No-Root” Actually Buys You

A reverse tunnel is a connection that a private machine opens outward to a public relay, which then sends incoming traffic back down that same connection. Because the private machine never accepts an inbound connection, it works from behind a home router, a corporate firewall, or carrier-grade NAT (CGNAT) with no ports opened.

That outbound-only design is also why most tunnel clients need no special privileges at all:

• The ngrok agent makes an outbound TLS connection over port 443, the same port as ordinary HTTPS.
• SSH-based services like localhost.run and Pinggy use the SSH client already on your machine, so there is nothing new to install or elevate.
• bore’s server defaults to accepting only ports from 1024 upward, per its documentation.
• Tailscale’s tsnet library runs a self-contained node inside your process on a userspace network stack, with no root privileges required.

Where elevated privileges genuinely show up is at the edges: installing an agent as a persistent system service (for example, Packetriot’s daemon docs cover running the client under systemd), or binding the application you are exposing to a privileged local port.

What a rootless agent does for you. If the exposed application is compromised, the attacker inherits the permissions of the standard user account, not those of an administrator-level agent. Running the tunnel client as root is almost never necessary, so a policy forbidding it costs developers little.

What it does not do. It doesn’t tell you whether the tunnel is authorized, who can reach it, or where the traffic goes. Worse, the qualities that make rootless tunnels friendly to developers (no install, no admin rights, outbound-only on a common port) are exactly what attackers exploit. Treat “runs without root” as a necessary control, not a sufficient one. The controls that actually carry compliance weight are approved providers, authenticated access, central inventory, and egress monitoring.

Rootless Options in 2026

SSH-Based Services

SSH remote forwarding is the original reverse tunnel: you ask a remote SSH server to listen on a port and push traffic back through the session to a local port. Because it uses the standard SSH client, there’s no third-party binary to approve or elevate.

localhost.run offers the fastest start. One command, with no install or signup:

ssh -R 80:localhost:8080 nokey@localhost.run

Free domains will always be free, but per its free-tier documentation they are speed-limited and rotate periodically, so they’re poor candidates for webhook testing that needs a stable URL. A stable lhr.rocks or custom domain costs $9 per month billed annually.

Pinggy is another SSH-only option that requires no binary:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Per Pinggy’s help page, the free plan has a 60-minute tunnel timeout, and each new tunnel gets a new URL. A persistent URL or custom domain requires a paid plan (Pinggy’s own blog lists paid plans from $2.50 per month). TCP and TLS tunnels are available for free. One compliance detail worth knowing: Pinggy states that it reads tunnel traffic to power its Web Debugger feature.

A caution for security teams. Both services can run over port 443 or port 22, and Pinggy documents 443 explicitly. That makes them firewall-friendly, but it also means port-based egress rules alone can’t separate them from normal HTTPS. Domain- or SNI-level controls are the realistic lever.

Self-Hosted and Open-Source Tools

If you’d rather not send traffic through a third party, self-hosting removes the outside relay from the data path.

frp (Fast Reverse Proxy) is the best-known self-hosting option. It supports TCP, UDP, HTTP, and HTTPS forwarding plus a P2P mode, and its client and server can talk over TCP, QUIC, KCP, or WebSocket. Recent releases have added OIDC client options and detailed Prometheus metrics per proxy. Note the project’s support policy: starting with v0.69.0, each minor release is supported only until nine newer minor releases exist, so plan for regular upgrades.

bore is the minimalist alternative. Its README describes about 400 lines of safe, async Rust, distributed as a single binary for both client and server, and it forwards TCP only. A server can require a shared secret, verified through HMAC challenge-response on each connection:

bore server --secret my_secret_string
bore local 8000 --to your-bore-host.example.com --secret my_secret_string

The public bore.pub instance is handy for demos, but for anything compliance-relevant, run your own server. Note also that bore forwards raw TCP; if you need TLS, terminate it yourself.

zrok, built on the OpenZiti overlay network and developed by NetFoundry, is open source and self-hostable, with a free hosted instance at zrok.io. It supports both public shares (an HTTPS URL anyone can open) and private shares (a token-based connection that creates no public endpoint at all, accessed by another zrok user with zrok access private). On a hosted instance, operators can see traffic for public shares, so the privacy model differs from private shares on your own infrastructure. Version 2.0, released in March 2026, replaced the old reserve/release workflow with namespaces and names and renamed the CLI to zrok2.

Managed Edge Services

Cloudflare Tunnel. For quick testing, cloudflared creates a public HTTPS URL with no account:

cloudflared tunnel --url http://localhost:8080

Read the fine print, though. Cloudflare’s documentation says these quick tunnels are for testing only, with a 200 concurrent request limit and no Server-Sent Events (SSE) support. Anything shared or long-lived should use a named tunnel, which requires a Cloudflare account. Quick tunnels are also the exact feature the abuse reports above describe, which is why many security teams monitor for them.

ngrok. ngrok remains the reference point. Its free plan allows up to three online endpoints, and the pay-as-you-go plan has a $20 monthly base fee that includes $20 of usage. For enterprises, ngrok’s pricing page lists centralized management (SAML, OpenID Connect, SCIM, RBAC, audit logs) and a self-hosted option aimed at data-residency and compliance needs.

Microsoft Dev Tunnels. For Microsoft-centric organizations, this is one of the few options with first-class admin controls. By default, hosting or connecting to a tunnel requires authentication with the account that created it, and anonymous access has to be explicitly enabled. Administrators can deploy group policies that disable anonymous access, disable Dev Tunnels entirely, or restrict use to an allow-list of Microsoft Entra tenant IDs. The policies apply across Visual Studio, VS Code port forwarding, the Remote - Tunnels extension, and the devtunnel CLI. Microsoft also publishes the domains the service uses (such as *.devtunnels.ms), so you can allow or deny outbound access at the network layer.

Packetriot Spokes: A Managed Server for Teams

Individual developers can get by with SSH tricks or single-binary tools. Teams that need central control look at a server they manage themselves. One example is Spokes, the server behind Packetriot.

According to Packetriot, Spokes is a private instance of the same tunneling server that runs packetriot.com, built to manage and serve HTTP/S and TCP tunnels for large teams or fleets of devices. It scales to thousands of tunnels per instance, and the standard Packetriot client works with it unchanged. Details worth knowing:

• Access model. Administrators manage users and tokens instead of relying on Packetriot’s account system, and Spokes ships an embedded SOCKSv5 proxy plus an upstream service monitor, according to the Spokes docs. Packetriot’s site also lists OpenID Connect support.
• Endpoint policy. Client local policies let a local IT admin constrain which destinations and ports tunnel rules may target. They are managed through the client’s CLI, so remote rule pushes from the server cannot override them.
• Deployment. An official Docker container, Kubernetes support, and RPM and DEB packages. SQLite is the default datastore, with MariaDB and Postgres options for larger deployments.
• Licensing. Annual, priced by maximum tunnel count: $1,000 for 100 tunnels, $2,000 for 250, $3,500 for 500, and custom pricing at 1,000 or more. A 30-day trial license is available.
• Provenance. Spokes was forked from Packetriot’s earlier server, Hubs, and Packetriot migrated its own network to Spokes in 2023.

Packetriot pitches the on-premise option as a way to reuse the compliance processes you already have (it names HIPAA, GDPR, SOX, and PCI) rather than adding a SaaS vendor to your regulated data path. That’s a fair architectural point, but treat it as a vendor claim: hosting your own tunnel server changes who is in the data path, and doesn’t make an organization compliant on its own.

At a Glance

Tool	Model	Privilege footprint	Watch out for
localhost.run	SSH to hosted relay	Stock SSH client	Free domains rotate and are rate-limited
Pinggy	SSH to hosted relay	Stock SSH client	Free tunnels last 60 minutes; provider reads traffic for its debugger
Cloudflare quick tunnel	Hosted edge, cloudflared	User-level binary	Testing only; 200 concurrent requests; no SSE; frequent abuse target
ngrok	Hosted edge (self-host option on enterprise plans)	Outbound TLS on 443	Free plan limited to 3 online endpoints
Microsoft Dev Tunnels	Hosted, tenant-aware	devtunnel CLI or IDE	Best admin controls, but Microsoft-ecosystem oriented
frp	Self-hosted	Client and server binaries	You own patching; frequent minor releases
bore	Self-hosted	Single binary	TCP only, no built-in TLS
zrok	Hosted or self-hosted	User-level client	v2 CLI renamed to zrok2; public vs. private shares differ in privacy
Packetriot Spokes	Self-hosted or vendor-managed	Standard client	Licensed by tunnel count; vendor sales process

Embedding the Tunnel in the Application

A different approach to reducing the number of separate tunnel binaries is to embed tunneling directly in the application. Several real, documented options exist today:

• ngrok Agent SDKs. ngrok publishes Agent SDKs for Go, JavaScript, Python, and Rust that let you create endpoints from your own code; you handle incoming connections as if you had opened a socket on a local port. ngrok recommends them when you don’t want to manage a separate agent process or bundle the agent with your software. The Go SDK reached v2 (golang.ngrok.com/ngrok/v2).
• Tailscale tsnet. In Go, tsnet embeds a full Tailscale node in your process with no root privileges required. It can also publish the app to the public internet through Tailscale Funnel via ListenFunnel, which currently supports TCP on ports 443, 8443, and 10000 and requires HTTPS to be enabled in the Tailscale admin console.
• zrok and OpenZiti SDKs. zrok’s docs cover integrating sharing directly into your code through its Go SDK, so an application can bind services to the overlay without a separate client.

A naming note: you may see “TunnelAPI 2.0” in tool roundups. That is one vendor’s hosted tunneling and API-gateway product, not an industry standard for embedded tunneling, so it shouldn’t be treated as a compliance baseline.

Security implications, honestly stated. Embedding removes a separately installed binary and ties the tunnel’s lifetime to the application process, which can help with inventory and cleanup. But it also changes where detection has to happen. A tunnel created inside application code won’t show up as a recognizable “ngrok” or “cloudflared” process, so process-name rules won’t catch it. Network-layer visibility (DNS, proxy logs, and destination allow-lists) becomes the reliable control. Whether authentication such as mutual TLS is enforced depends entirely on the product you choose and how you configure it, not on the embedding approach itself.

Building a Compliant Tunneling Program

Moving from ad-hoc tunnels to a governed model works best as a rollout, not a ban. Developers will route around a block that offers no alternative.

1. Inventory what’s already there. Use EDR, DNS, and proxy telemetry to find tunnel agents and tunnel domains in use. Start with well-known destinations (*.trycloudflare.com, ngrok domains, *.devtunnels.ms) and existing detection content like the Elastic rule above. Flag anything running with elevated privileges.
2. Write an acceptable-use standard. Require unprivileged execution, require authentication on every exposed URL, and prohibit anonymous or permanent public tunnels. Remember that a tunnel URL alone is not access control: anyone who has the link can reach the app unless you add authentication at the edge.
3. Offer sanctioned alternatives. Match tool to need. Microsoft shops can standardize on Dev Tunnels with tenant restrictions enforced by group policy. Teams that need central audit and control can run a self-hosted stack such as Packetriot Spokes, frp, or zrok, or buy an enterprise plan from a managed provider. For occasional webhook tests, decide whether SSH-based services are permitted at all, and if so, which.
4. Enforce at the network layer. Because these services deliberately use common ports, add domain- or SNI-based egress controls and alerting for unsanctioned tunnel destinations. Anything you approve should be allow-listed by destination.
5. Integrate identity. Tie sanctioned infrastructure to your identity provider so that tunnel creation is attributable to a person. Spokes tokens, Dev Tunnels’ Entra tenant restrictions, and ngrok’s enterprise SSO features all serve this purpose.
6. Standardize internal tooling. If your platform team wraps tunneling into scaffolding or CLIs, build on a sanctioned SDK (ngrok’s, tsnet, or the zrok/OpenZiti SDKs) so the approved path is also the easiest one.

The Bottom Line

“No root” is the right default for every tunnel client, and it costs developers almost nothing. But rootless is where the conversation starts, not where it ends. The same low-friction properties that make unprivileged tunnels pleasant to use also make them popular with attackers, which is why mature programs pair least-privilege execution with approved providers, authenticated access, centralized inventory, and egress monitoring. Pick tools that let you prove who opened a tunnel, to where, and for how long. That is what auditors will actually ask for.

---

Fact-Check Changelog (remove before publishing)

Every claim in the original draft was checked against vendor documentation or primary sources as of September 29, 2026. Changes, most significant first:

1. “TunnelAPI 2.0” as a standard: removed and replaced. The draft described “TunnelAPI 2.0 standards” for embedding tunnels in application runtimes, with mTLS and ephemeral routing. No such standard exists. TunnelAPI (2.0) is a single vendor’s hosted tunneling and AI/API-gateway product, listed in the awesome-tunneling directories alongside a 1.0 tool with an arm CLI. The embedded-library, mTLS, and “no listening ports” claims had no supporting source. The section was rewritten around real embedded options (ngrok Agent SDKs, Tailscale tsnet, zrok/OpenZiti SDKs) and now includes a one-line clarification of the TunnelAPI naming.
2. EDR narrative reversed. The draft claimed that EDR platforms (CrowdStrike, SentinelOne, Defender) “kill” tunnel agents run with elevated rights and that rootless tunnels avoid EDR conflicts. I found no source for vendor-specific behavior, and the evidence points the other way: MITRE, Proofpoint, Securonix, Cofense, SpearTip, and GuidePoint show that user-level tunnels (needing only a token or SSH) are what attackers use. The article now presents rootless as necessary but not sufficient and cites Elastic’s cloudflared detection rule as a real example.
3. Unsupported root-privilege claims removed. “Some tools required root to bind ports below 1024, install system-wide certificates to intercept HTTPS, or register as services” had no source for the certificate-interception claim; reverse-tunnel clients connect outbound and typically need no privilege. Root is now described only where documented (system-service installation, privileged local ports).
4. Packetriot Spokes. Deployment options (Docker, Kubernetes, RPM/DEB), SQLite default with MariaDB/Postgres, HTTP/S and TCP scope, “thousands of tunnels,” and the regulation list all match Packetriot’s enterprise page. Removed “dominates the 2026 market” (no market-share source), softened “audit logs” (docs describe the ability to audit and manage traffic), and reframed compliance-risk reduction as a vendor claim. Added pricing tiers, 30-day trial, client local policies, token/user management, SOCKSv5 proxy, OIDC mention, and Hubs-to-Spokes history.
5. bore. “Under 1,000 lines” replaced with the README’s “about 400 lines.” TCP-only and single-binary confirmed. Added HMAC secret, 1024 default minimum port, and the warning about the public bore.pub server.
6. zrok. The draft said zrok “operates on a default mental model of private sharing.” zrok offers both public and private shares as explicit choices. Corrected, added the private-share behavior, hosted-instance visibility caveat, and the v2.0 (March 2026) rename to zrok2.
7. Cloudflare Tunnel. Quick tunnel command confirmed. Added the documented limits (testing only, 200 concurrent requests, no SSE). Softened “runs entirely in user-space” and removed the “massive DDoS mitigation” claim as unsourced for this context. Noted that named tunnels require an account.
8. Pinggy. Command and TCP/TLS availability confirmed. The draft’s “URL changes on reconnect” is correct, and the specific figure (60-minute free timeout) was added. Added the debugger traffic-reading disclosure and pricing from Pinggy’s own blog.
9. localhost.run. Command confirmed. Added free-domain throttling/rotation and $9/month custom-domain pricing.
10. frp. Protocol list confirmed. Added transport options, OIDC/metrics improvements, and the v0.69.0+ support policy.
11. “Security teams have started blacklisting popular consumer-grade tunnel agents entirely.” Replaced with sourced statements: monitoring recommendations (SpearTip) and Microsoft’s admin controls for Dev Tunnels. Also removed “risk having their workstation isolated” as unsourced.
12. New sections added: MITRE ATT&CK and abuse-campaign context; Microsoft Dev Tunnels group policies; ngrok plan and enterprise details; comparison table; the “Building a Compliant Tunneling Program” steps revised to include egress controls and identity integration.

Left out intentionally / needs a vendor-doc check before you add it: - One third-party glossary claims ngrok cut its free tier in February 2026 (2-hour sessions, random URLs only). That conflicts with ngrok’s own site, which advertises a free static domain, so I did not include it. Verify against ngrok’s current pricing-limits page if you want to comment on ngrok’s free tier. - The exact sudo requirement for cloudflared service install was not verified in this pass, so the article refers only generically to system-service installation, citing Packetriot’s daemon docs. - Pinggy’s UDP support is documented in third-party comparisons (including our own earlier Pinggy vs. localhost.run piece) but I did not re-confirm it on Pinggy’s own page, so the article does not mention it.