Protocol coverage

Expanded Definition

Protocol coverage describes how consistently identity-aware controls are enforced across every protocol an environment actually uses, including SSH, DNS, UDP-based services, message buses, and legacy application channels. In NHI security, this matters because least privilege is only real when policy follows the traffic, not just the browser session.

Definitions vary across vendors because some tools focus on session control at the edge, while others extend enforcement into service meshes, gateways, or identity-aware proxies. No single standard governs this yet, so teams should treat protocol coverage as an operational measure of control reach rather than a product category. The most reliable reference point is the protocol surface of the workload estate, compared against NIST Cybersecurity Framework 2.0 expectations for access control and continuous governance.

The most common misapplication is assuming “web covered” means “environment covered,” which occurs when SSH, DNS, or broker traffic is excluded from the enforcement design.

Examples and Use Cases

Implementing protocol coverage rigorously often introduces latency, policy complexity, and exception management overhead, requiring organisations to weigh stronger enforcement against operational friction.

• A platform team requires identity-based authorization for SSH into Linux hosts, rather than allowing unmanaged key-based access through a separate admin path.
• A security group extends policy inspection to DNS queries so service identities cannot use name resolution as a covert channel around access controls.
• An engineering org maps service-to-service authorization in a mesh while also validating that non-mesh traffic is covered, using guidance from the NIST Cybersecurity Framework 2.0.
• During a review of Schneider Electric credentials breach lessons, defenders assess whether a forgotten protocol path let service credentials bypass normal enforcement.
• An incident response team inventories UDP and message-queue dependencies to ensure that future controls do not stop at HTTP and HTTPS.

These use cases show that protocol coverage is less about adding more rules and more about closing the gaps where identities can still authenticate, transmit, or pivot without inspection.

Why It Matters in NHI Security

Protocol coverage is a governance issue because NHI compromise rarely happens only through the “main” application path. Attackers look for the least monitored channel, and a single uncovered protocol can become an exception route for token theft, lateral movement, or command execution. That is why NHI Management Group highlights how frequently weaknesses accumulate in the broader identity estate, including the fact that 80% of identity breaches involved compromised non-human identities and that only 5.7% of organisations have full visibility into their service accounts.

When protocol coverage is incomplete, monitoring may look healthy while the real exposure remains outside the policy boundary. That disconnect undermines Zero Trust Architecture, weakens enforcement of identity assurance, and leaves defenders blind to the protocols where service accounts are most likely to be abused. The issue also aligns with the access-control principles expressed in NIST Cybersecurity Framework 2.0.

Organisations typically encounter the consequence only after a breach investigation reveals that traffic on an ungoverned protocol was the path used to bypass controls, at which point protocol coverage becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the Model Context Protocol (MCP) and why does it matter for security?
• When do IAST and RASP create a false sense of coverage for NHIs?
• How should security teams govern AI agents that use Model Context Protocol?
• Why does Model Context Protocol create identity risk for enterprises?