How should security teams extend zero-trust access to non-HTTP protocols without relying on VPNs?

Security teams should treat non HTTP protocols as first class access paths and enforce identity, policy, and session controls at the proxy layer. A practical approach is to tunnel the protocol, authenticate users through SSO, and authorize access by route, group, or other policy inputs. That preserves zero trust principles while avoiding broad network access through a VPN.

Why Non-HTTP Access Needs Zero Trust, Not a VPN

Non-HTTP protocols such as SSH, RDP, PostgreSQL, SMB, and custom service ports are still access paths, so they need the same identity-first controls as web apps. A VPN gives broad network reach, but zero trust requires narrower decisions: who is connecting, to which route, for what purpose, and under what policy. That shift matters because protocol-level access often bypasses browser-based SSO patterns and creates hidden trust zones that are hard to audit.

For security teams, the practical goal is to replace network membership with session-specific authorization at the proxy or gateway layer. That approach aligns with NIST SP 800-207 Zero Trust Architecture and the identity risks described in Ultimate Guide to NHIs, where broad standing access and weak visibility are recurring failure points. NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

In practice, many security teams discover the weakness only after a jump host, bastion, or VPN subnet has already become the easiest path for lateral movement.

How Proxy-Based Access Control Works for Non-HTTP Protocols

The common pattern is to put a secure access proxy in front of the protocol, then use SSO and policy evaluation before any TCP session is established. The user authenticates through the identity provider, the proxy checks context such as group membership, device posture, time of day, and destination route, and only then opens a short-lived tunnel to the target service. This preserves the protocol while removing direct exposure of the internal network.

For agentic or service-to-service scenarios, the same model should apply to workload identity rather than human credentials. Current guidance suggests pairing the proxy with cryptographic workload identity, short-lived tokens, and policy-as-code so access is decided at request time, not by static subnet rules. That is consistent with OWASP Non-Human Identity Top 10 and Guide to SPIFFE and SPIRE, which both emphasize identity over network location.

• Authenticate users through SSO before the proxy opens the session.
• Authorize by route, application, group, or device state rather than by IP range.
• Issue ephemeral access and revoke it automatically when the session ends.
• Log the full decision path so protocol access can be reviewed later.

Where this works best, the proxy becomes the choke point for both human and machine access, which is especially valuable when teams need to monitor secrets-driven services and privileged admin paths; NHIMG notes that 79% of organisations have experienced secrets leaks and 97% of NHIs carry excessive privileges. These controls tend to break down in legacy environments that require direct broadcast, stateful peer discovery, or unmanaged client software that cannot be routed cleanly through an access proxy.

Common Variations, Tradeoffs, and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance usability against protocol compatibility and change management. There is no universal standard for every non-HTTP protocol yet, so teams often mix approaches: application-aware proxies for SSH and RDP, tunneling gateways for database access, and service mesh style controls for east-west traffic.

The main edge case is custom or stateful protocols that do not tolerate interception or proxying without breaking session semantics. In those environments, current guidance suggests falling back to narrow, policy-enforced relay points rather than reopening flat VPN access. Another common exception is third-party support access, where temporary approvals and full session recording may be more practical than persistent group membership. That aligns with the broader NHI risk picture in The State of Non-Human Identity Security, which reports that only 1.5 out of 10 organisations are highly confident in securing NHIs.

Security teams should also be careful not to confuse zero trust with one-time authentication. For non-HTTP access, the real control is continuous policy enforcement across the session, not just a login event. These designs are strongest where tooling can enforce route-level decisions consistently, and weakest where the protocol is opaque, the client is unmanaged, or the environment still depends on broad administrative reach.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust access across network and non-network resources without creating operational drift?
• How should security teams extend Zero Trust to autonomous AI agents without relying on static secrets?
• How should security teams use an enterprise browser to enforce zero trust for SaaS access?
• How should security teams restrict third-party access in supply chain environments without creating broad network trust?