Why do hybrid mesh firewalls not fully solve east-west risk?

Why This Matters for Security Teams

Hybrid mesh firewalls can reduce east-west exposure by giving teams a more consistent policy layer across sites, clouds, and segments. The problem is that they still operate mainly on traffic paths and zones, not on the identity and intent of the thing making the request. That means service accounts, API keys, and workload tokens can still be abused after an initial foothold unless internal access is constrained by separate identity controls.

This matters because east-west movement is usually where compromise becomes material. Once an attacker reaches an internal segment, network segmentation alone often does not stop privilege escalation, tool chaining, or credential reuse. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is exactly the kind of identity layer a firewall does not govern.

Current guidance suggests treating mesh firewalls as one control in a broader trust model, not as the trust model itself. Security teams that stop at boundary simplification often discover that internal trust assumptions were never removed, only hidden behind cleaner policy distribution. In practice, many security teams encounter lateral movement only after a service account or token has already been reused inside the segment, rather than through intentional east-west containment.

How It Works in Practice

To reduce east-west risk, mesh firewalls should be paired with identity-aware controls that evaluate each request in context. That means the policy decision is not just “is this subnet allowed,” but “is this workload, service account, or agent allowed to perform this action right now.” This is where NIST Cybersecurity Framework 2.0 is useful for framing governance, while implementation often relies on workload identity, short-lived tokens, and policy-as-code.

In practice, teams are moving toward:

• Workload identity as the primary control plane, so internal services authenticate as cryptographic identities rather than as “trusted east-west traffic.”
• Just-in-time credentials with short TTLs, so secrets are issued per task and revoked automatically when the task ends.
• Runtime authorization using policy engines, so access depends on the identity, requested action, and context at the moment of use.
• Microsegmentation or service-to-service controls that are enforced below the application layer, not only at perimeter choke points.

This is also where NHI hygiene becomes operationally important. The Top 10 NHI Issues research highlights how excessive privileges, weak rotation, and poor visibility turn internal trust into an attacker’s shortcut. A mesh firewall may slow scanning or reduce blast radius, but it cannot automatically revoke a leaked API key, distinguish a legitimate job runner from a stolen token, or stop a compromised service account from calling every internal endpoint it can reach. These controls tend to break down when environments rely on long-lived credentials and broad service trust because the firewall still sees permitted network flows, not malicious intent.

Common Variations and Edge Cases

Tighter east-west policy often increases operational overhead, requiring organisations to balance containment against deployment friction and service discovery complexity. That tradeoff is real, especially in hybrid estates where legacy applications, shared credentials, and flat internal networks are still in use.

Best practice is evolving, and there is no universal standard for this yet. In some environments, a mesh firewall is a reasonable first step because it centralises policy and reduces obvious lateral paths. In others, especially multi-cluster Kubernetes, shared CI/CD runners, or environments with many third-party integrations, the firewall can create a false sense of containment if it is not paired with service identity, secret rotation, and least privilege.

The hardest cases are workloads that behave autonomously or dynamically, such as batch jobs, ephemeral agents, and orchestration pipelines. Those systems can legitimately change destinations, credentials, and request patterns from one minute to the next, which makes static allowlists brittle. For those cases, current guidance suggests coupling network controls with workload attestation, JIT token issuance, and per-request policy evaluation. NHI Management Group’s 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities, reinforcing that identity abuse is not theoretical.

Hybrid mesh firewalls remain useful, but they do not fully solve east-west risk when the real attack path is identity abuse inside the segment, not just unauthorized network ingress.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why does shift-left security not fully solve AI agent risk?
• Why do Docker policy plugins not fully solve container identity risk?
• Why do just-in-time credentials not fully solve agentic AI risk?