Why do organisations use multiple meshes when services may already share the same network zone?

Multiple meshes create separate policy enforcement domains and prevent traffic from flowing directly between isolated workloads, even when those workloads are physically close. That matters when different teams, applications, or security domains need distinct controls, such as different mTLS settings or stronger separation between environments. The mesh boundary reduces accidental cross-domain communication.

Why multiple meshes exist even inside one network zone

A shared network zone does not guarantee shared policy. Teams often need separate enforcement points so one application group can use one trust model, certificate set, or routing rule while another stays isolated. That is why multiple meshes can exist side by side: they create a control boundary above the network layer, reducing accidental cross-talk and making policy ownership clearer.

In practice, the mesh is doing the work that the subnet cannot do on its own. The network zone may define where traffic can reach, but the mesh can decide whether a workload is allowed to establish service-to-service trust, present the right certificate, or accept traffic from a specific peer. That distinction matters when platform teams want shared infrastructure but different application owners need different security rules.

The result is architectural separation without requiring full physical separation. A finance service and an internal developer tool may sit in the same zone for routing efficiency, yet still need different trust domains, policy lifecycles, or environment separation. Multiple meshes let organisations keep the shared network layer stable while changing the communication rules at the service layer.

What changes at the boundary between meshes

The important change is not distance, it is control scope. A workload inside one mesh generally cannot assume it can speak directly to a workload in another mesh just because both are on the same network. Traffic may need explicit gateways, federation, peering, or translation rules, which gives operators a place to apply stricter checks and limit unexpected lateral movement.

This separation is useful when policies diverge materially. One mesh may enforce stricter mTLS, shorter certificate lifetimes, tighter egress policy, or more aggressive observability than another. It is also useful when two groups share infrastructure but not operational trust, because a shared mesh can become a single failure domain for policy mistakes, certificate issues, or overly broad discovery.

Seen this way, multiple meshes are an organisational control choice as much as a technical one. They help express ownership boundaries, reduce the blast radius of configuration errors, and make it easier to align service communication with the actual trust relationships in the business.

When a single mesh is not enough

One mesh is often fine when the services belong to one platform team, share one policy model, and can tolerate one operational cadence. Multiple meshes become more attractive when teams need autonomy, when environments have different assurance requirements, or when the cost of a shared policy mistake is too high. The design is especially common when production, staging, regulated workloads, or acquired systems must remain partially isolated even though they live on the same network substrate.

Multiple meshes are also a practical answer to heterogeneous tooling. Different meshes may support different certificate authorities, sidecar versions, policy engines, or traffic-management patterns. Rather than forcing one compromise design across all workloads, organisations sometimes choose a boundary that keeps each domain manageable and auditable on its own terms.

That said, the trade-off is extra complexity. More meshes mean more gateways, more federation rules, more policy duplication, and more places where visibility can fragment. The architecture is useful when separation is the requirement, not when it is just a way to avoid standardisation.

Risk and Threat Considerations

Multiple meshes reduce accidental coupling, but they can also create hidden trust gaps if teams assume the mesh boundary is enough by itself. Misconfigured gateways, overly permissive federation, or inconsistent certificate handling can quietly reopen the very lateral paths the separation was meant to close.

Failure mechanism: A team treats the shared network zone as evidence of shared safety, or treats mesh-to-mesh connectivity as a routine integration rather than a new trust boundary. That can lead to policy drift, unmanaged cross-mesh access, and blind spots in logging or certificate governance.

Impact: Cross-domain traffic may flow with weaker controls than intended, and a compromise in one domain can spread farther than expected. The risk rises when separation exists on paper but enforcement, monitoring, and ownership are split across teams.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SC-7 — Boundary Protection	Multiple meshes create controlled service boundaries within a shared network zone.
	AC-4 — Information Flow Enforcement	Mesh segmentation governs which workloads may communicate across domains.
	IA-9 — Service Identification and Authentication	Inter-mesh trust depends on authenticated service-to-service connections.
Recommendation — Enforce boundary controls at mesh gateways to restrict cross-domain service traffic. Apply information flow rules to permit only approved inter-mesh communications. Authenticate services at mesh boundaries before allowing cross-mesh access.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The answer depends on explicit trust boundaries and least-privilege service access.
Recommendation — Place explicit verification points between meshes instead of trusting shared network location.
CIS Controls v8	CIS-12 — Network Infrastructure Management	Separate meshes require managed segmentation and controlled interconnects.
Recommendation — Manage mesh gateways and segmentation points as controlled network infrastructure.

Practitioner Guidance

What to prioritise: Treat the mesh boundary as a governance boundary, not just a routing detail. If two meshes need to talk, define who owns the trust decision, who approves the connection, and what evidence proves the path is still constrained.

What to verify: Confirm that cross-mesh traffic must use explicit approved entry points, and that identity, certificate, and policy settings are consistent with the separation you intended. If you cannot explain why a workload can reach another mesh, the boundary is too loose.

Common mistake: Assuming that one shared subnet means one shared security model. The network may be shared for efficiency, but the service plane still needs deliberate separation whenever teams, environments, or assurance levels differ.

Practitioner takeaway: Use multiple meshes when the business needs distinct trust and policy domains, and be prepared to operate the boundary as an active control surface rather than a passive deployment choice.