Why do service meshes matter for zero trust in east-west traffic?

Why This Matters for Security Teams

Service meshes matter because zero trust fails fastest where teams assume internal traffic is inherently safe. East-west calls are often more numerous than north-south requests, and they are frequently where service accounts, API keys, and mTLS boundaries are either inconsistent or missing. NIST SP 800-207 Zero Trust Architecture makes the core point clearly: trust should be continuously evaluated, not inherited from network location.

In microservices estates, that matters because a compromised workload can pivot laterally through internal APIs, message buses, and sidecar-exposed routes long before perimeter controls notice anything unusual. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and that gap is exactly where east-west trust assumptions hide. The Ultimate Guide to NHIs — Standards also frames Zero Trust as a governance problem, not just an encryption problem. In practice, many security teams discover weak internal authentication only after a service-to-service compromise has already turned one workload into a launch point for broader access.

How It Works in Practice

A service mesh operationalises zero trust in east-west traffic by moving identity and policy decisions closer to the request path. Instead of trusting subnet membership, the mesh issues workload identities, enforces mutual TLS, and evaluates policy before one service can talk to another. This aligns with NIST SP 800-207 Zero Trust Architecture, which treats identity, device posture, and context as inputs to each access decision.

In practice, the mesh usually performs four jobs:

• Authenticates workloads with cryptographic identity, not just IP address or namespace membership.
• Encrypts service-to-service traffic by default, reducing exposure to passive interception and route tampering.
• Applies authorization at request time, so policy can distinguish between allowed service pairs, paths, and methods.
• Provides observability across internal calls, which helps teams detect abnormal lateral movement and unexpected dependencies.

For NHI governance, this is where workload identity becomes the control plane for service trust. The Guide to SPIFFE and SPIRE is a useful reference point because it explains how short-lived workload identities can replace static secrets that are easy to copy and hard to rotate. That matters when service meshes are used to enforce least privilege between dozens or hundreds of internal services, because the mesh can only be as trustworthy as the identities it binds and the policies it evaluates. These controls tend to break down in legacy environments where sidecars cannot be injected consistently, traffic bypasses the mesh through direct pod-to-pod paths, or teams still rely on hard-coded service tokens outside the mesh boundary.

Common Variations and Edge Cases

Tighter mesh enforcement often increases deployment and troubleshooting overhead, so organisations must balance stronger east-west control against platform complexity. Best practice is evolving, and there is no universal standard for every mesh implementation, especially when hybrid estates mix Kubernetes, virtual machines, and managed services.

One common edge case is partial mesh adoption. If only some services use mTLS and policy enforcement, teams can create a false sense of zero trust while leaving bypass paths open. Another is service discovery drift, where identity claims do not match actual runtime behaviour because ownership, naming, or certificate issuance is inconsistent. This is especially risky in environments with third-party integrations or multi-cluster topologies, where internal traffic may still cross trust zones.

NHIMG data from the Ultimate Guide to NHIs shows why this matters operationally: 97% of NHIs carry excessive privileges, which means a mesh cannot compensate for weak authorization design on its own. Current guidance suggests pairing mesh enforcement with explicit service ownership, short-lived credentials, and regular policy review. The mesh is a strong zero trust enabler, but it is not a substitute for cleaning up the identities and permissions that ride inside the traffic. In practice, the model becomes fragile when teams treat the mesh as a perimeter replacement instead of a continuous authorization layer.

Related resources from NHI Mgmt Group

• Why do Active Directory service accounts complicate zero trust programs?
• 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?