Why do non-HTTP protocols complicate zero trust architecture?

Why Non-HTTP Protocols Break the Assumptions Behind Zero Trust

zero trust works best when every request can be evaluated against identity, context, and policy at the moment of access. That model maps naturally to web traffic, but SSH, DNS, UDP, and device management channels often sit outside the control plane that organisations build first. The result is not a failure of the concept, but a coverage gap. NIST’s NIST SP 800-207 Zero Trust Architecture emphasises that trust decisions must be dynamic and continuous, yet many environments still treat non-HTTP traffic as an exception.

That exception pattern becomes especially dangerous for non-human identities, because the same service account or API key may be able to reach multiple protocols with inconsistent enforcement. NHI Management Group’s Ultimate Guide to NHIs notes that properly managing NHIs is essential to successful Zero Trust adoption, and the operational reality is that these identities often outnumber human identities by a wide margin. In practice, many security teams discover protocol-specific blind spots only after an operator shell, resolver path, or admin tunnel has already bypassed the intended policy boundary.

How Non-HTTP Traffic Fits into Zero Trust Controls

Non-HTTP protocols complicate Zero Trust because the security stack must understand more than URLs and sessions. SSH, DNS, syslog, database connections, message queues, and UDP-based service traffic often rely on different authentication mechanics, different policy points, and sometimes no application-layer identity at all. Current guidance suggests treating these paths as first-class workloads rather than legacy exceptions.

A workable approach usually combines network segmentation, workload identity, and runtime authorisation. The goal is to establish identity for the calling workload, not just the device or subnet, then decide whether that workload should be allowed to use a given protocol at that moment. NHI Mgmt Group’s Guide to SPIFFE and SPIRE is useful here because it explains how cryptographic workload identity can replace brittle reliance on static network location. Where possible, organisations should pair that with policy engines that can evaluate context per request, rather than hard-coding broad allow rules.

• Inventory every non-HTTP path, including admin tunnels, service-to-service ports, and name resolution flows.
• Assign workload identity to the caller so policy can distinguish authorised automation from generic network access.
• Use short-lived credentials and revoke them automatically when the task ends.
• Apply the same policy review discipline to SSH, DNS, and UDP as to web applications.

Forensic visibility matters too. The Top 10 NHI Issues research highlights how excessive privilege and poor visibility expand risk across identity types, and non-HTTP channels often magnify that problem because they are less instrumented than browser-based traffic. These controls tend to break down when legacy appliances, flat network segments, or unmanaged east-west traffic cannot carry identity signals or enforce policy inline.

Where the Model Gets Messy in Real Environments

Tighter enforcement on non-HTTP protocols often increases operational overhead, so organisations must balance security coverage against latency, compatibility, and administrative complexity. That tradeoff is real in environments with legacy infrastructure, embedded systems, or operational tooling that was never designed for identity-aware access.

Best practice is evolving, and there is no universal standard for every protocol. Some traffic can be proxied and inspected, while other flows need endpoint controls, microsegmentation, or compensating detections. DNS is a good example: it may be technically simple, but it is foundational to service discovery and can be hard to constrain without breaking applications. SSH presents a different issue, because privileged access may need just-in-time elevation and session recording, while UDP often carries state-light traffic that is difficult to bind cleanly to a single authenticated transaction.

That is why Zero Trust programmes should not stop at web gateways. They should extend policy to operational channels, define exception handling explicitly, and measure whether identity controls actually reach the protocols attackers use for lateral movement. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant here because lifecycle governance, rotation, and offboarding become much harder once credentials are reused across multiple non-HTTP paths. Organisations that delay that work usually find the gap during incident response, not during design.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?
• Why do Active Directory service accounts complicate zero trust programs?