Service mesh vs. API gateway for modern identity governance

At a glance

What this is: This is a comparison of API gateways and service meshes, with the key finding that they are complementary controls for different traffic paths and trust boundaries.

Why it matters: It matters to IAM and security teams because distributed applications now need separate governance for external identities, internal workload identities, and the policies that connect them.

By the numbers:

• The global microservices architecture market size is expected to reach $13.1 Billion by 2033, exhibiting a growth rate (CAGR) of 12.7% from 2025 to 2033.
• Sidecar memory consumption can vary widely from roughly 40 MB in baseline setups to over 1 GB in more complex environments.
• Latency may increase by about 1.7 ms at the 90th percentile and up to 2.7 ms at the 99th percentile when two proxies sit in the data path.
• According to the Cloud Native Computing Foundation, 54% of enterprises use Envoy as their proxy solution.

👉 Read Kong's analysis of service mesh and API gateway roles in modern architectures

Context

Modern distributed applications split trust across two very different traffic paths. API gateway and service mesh are not competing labels for the same control, because one governs requests at the edge while the other governs service-to-service traffic inside the environment.

That distinction matters for identity governance. External callers, partner integrations, and web clients need edge authentication and authorization, while internal services need workload identity, encryption, observability, and policy enforcement that matches east-west communication.

Kong frames the issue as a layered architecture decision, not a product choice. For IAM teams, the real question is how to separate access control for humans, APIs, and machine workloads without leaving gaps between the perimeter and the backend.

Key questions

Q: How should security teams split responsibilities between API gateways and service meshes?

A: Security teams should assign API gateways to external request control and service meshes to internal service-to-service control. The gateway should enforce authentication, authorisation, rate limits, and transformation for north-south traffic. The mesh should handle mTLS, workload identity, telemetry, and traffic policy for east-west communication. Splitting duties this way reduces blind spots and prevents one layer from being overloaded.

Q: Why do service meshes matter for identity governance in microservices?

A: Service meshes matter because microservices create internal trust relationships that a gateway cannot see. They let teams prove workload identity, encrypt east-west traffic, and rotate certificates without relying on static secrets. That makes service-to-service access auditable and reduces the chance that internal calls inherit trust they should not have.

Q: What breaks when organisations rely on an API gateway alone?

A: An API gateway alone leaves the internal service layer largely governed by network assumptions. That means east-west calls may be trusted too easily, workloads may use static credentials, and internal movement can go unobserved. The result is a perimeter-controlled environment with a weak backend trust model, which is a common failure pattern in distributed systems.

Q: How do teams know whether gateway and mesh controls are working together?

A: Teams should look for consistent identity and traffic telemetry from the edge to internal services. If a request can be traced from external authentication through to service-to-service authorisation, the control model is functioning. If logs stop at the gateway or internal calls lack identity context, the architecture has a governance gap.

Technical breakdown

North-south traffic and edge policy enforcement

North-south traffic enters and leaves the platform, so it is the natural place for an API gateway to terminate client requests, validate tokens, enforce quotas, and apply authorization rules before a request reaches backend services. In identity terms, this is the point where external callers prove who they are and what they can do. Gateways commonly handle OAuth 2.0, OIDC, JWT validation, API keys, and request transformation, which makes them the control plane for perimeter access decisions. They do not, however, solve service-to-service identity inside the environment.

Practical implication: treat the gateway as the first trust boundary for external identity and API policy, not as a substitute for internal workload controls.

East-west traffic and workload identity inside the mesh

East-west traffic is service-to-service communication inside the boundary, where a service mesh usually adds mutual TLS, certificate lifecycle management, routing controls, and telemetry. This is where workload identity matters most, because the system must prove that one service talking to another is legitimate even when both are already inside the network. SPIFFE-style identities and automated certificate rotation reduce reliance on static secrets and make internal trust continuous rather than implicit. The mesh therefore addresses the identity problem that appears after the gateway has already accepted the request.

Practical implication: use the mesh to bind service identity to every internal connection and eliminate static trust between microservices.

Why layered controls outperform a single control plane

The article’s central mechanism is separation of concerns. Gateways handle external policy, developer onboarding, and traffic shaping, while meshes handle internal encryption, observability, and resilience. When organisations try to use one layer for both jobs, they either overburden the gateway with internal trust logic or leave east-west traffic under-governed. The result is a visibility gap between request entry and service execution. In modern architectures, that gap is where privilege, telemetry, and compliance drift tend to accumulate.

Practical implication: map edge identity, workload identity, and telemetry to different controls before standardising on a shared architecture.

Threat narrative

Attacker objective: The objective is to reach internal services and data through a trust gap between perimeter controls and east-west communication.

1. Entry occurs at the API edge, where untrusted north-south traffic must be authenticated and authorised before reaching internal services.
2. Escalation happens when internal east-west calls rely on implicit trust, static credentials, or weak service identity instead of mTLS and workload-level authentication.
3. Impact follows when an attacker or rogue workload can move laterally through services, consume data, or bypass policy boundaries that were only enforced at the edge.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API gateway and service mesh are identity controls for different trust boundaries, not interchangeable infrastructure layers. The gateway governs external access, where authentication and authorisation must stop untrusted traffic at the edge. The mesh governs internal service identity, where east-west communication needs cryptographic proof and continuous visibility. Practitioners should stop asking which layer replaces the other and instead ask where each boundary begins.

Identity governance fails when organisations treat internal services as already trusted. Service meshes exist because network location is not identity, and microservice sprawl turns implicit trust into a security debt. This is a classic workload identity problem, not just a networking problem. The practical conclusion is that internal access should be re-authenticated at the service boundary, not inherited from perimeter approval.

Service-to-service security is now part of IAM architecture, not just platform engineering. The same programme that governs human access reviews and API authorisation should also govern workload certificates, rotation, and telemetry. That convergence is where IAM, PAM, and cloud platform teams need shared ownership. Practitioners should design governance around the identity subject, not the traffic protocol.

East-west observability is a governance requirement, not an operational bonus. Without consistent telemetry across the gateway and the mesh, teams cannot reconstruct how a request moved from external caller to internal service action. This creates audit blind spots and weakens incident response. The implication is clear: identity governance must cover the full request path, or it only covers the front door.

Layered controls reduce risk only when teams accept that policy has to follow the request path. Edge enforcement, internal encryption, traffic management, and API lifecycle controls solve different parts of the same problem. Organisations that collapse those responsibilities into one control plane usually create either blind spots or excessive complexity. Practitioners should align architecture with trust boundaries first, then choose tooling.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• From our research: 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• For adjacent guidance: Review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that become critical when workload identities span edge and mesh layers.

What this signals

Identity boundary design now has to span both application entry and internal execution. Teams that only govern the edge will continue to miss service-to-service privilege drift, especially as microservices and AI-enabled workloads increase the number of internal identities that need lifecycle control. The practical signal is that access governance, telemetry, and certificate management need to be planned as one control surface, not three separate teams.

Workload identity is becoming the missing layer in many IAM programmes. The gateway can prove who is allowed in, but the mesh proves what each service can do after it is already inside. If those layers are not tied together, incident response loses continuity and compliance teams lose evidence. Practitioners should expect more pressure to connect API management with identity lifecycle controls and internal observability.

Gateway and mesh convergence is pushing IAM teams toward a broader model of identity governance. The question is no longer whether the edge is secure, but whether the full request path is explainable from authentication to service action. That shift should trigger review of internal service certificates, log correlation, and the handoff points between platform engineering and identity teams.

For practitioners

• Define separate trust boundaries for edge and internal traffic Map which identities are external users, partner systems, and internal workloads. Assign API gateway policy to north-south traffic and service mesh policy to east-west traffic so that authentication, authorisation, and telemetry remain boundary-specific.
• Bind workload identity to every service-to-service call Use cryptographic workload identities and automated certificate rotation for internal service communication. Remove static secrets where possible and require mTLS for east-west connections that carry sensitive data or privileged operations.
• Unify identity telemetry across gateway and mesh layers Correlate gateway logs, mesh traces, and identity events so security teams can reconstruct who accessed what, from where, and through which service chain. Without that correlation, incident response will miss the path between entry and impact.
• Review API lifecycle controls separately from service security Keep versioning, deprecation, developer onboarding, and rate limiting in the gateway domain, while enforcing internal policy, encryption, and routing in the mesh domain. This prevents governance drift when application teams change one layer without considering the other.

Key takeaways

• API gateways and service meshes solve different identity and traffic problems, so treating them as substitutes creates governance gaps.
• The article shows that edge policy alone is insufficient once east-west service traffic becomes the main attack and trust surface.
• IAM teams should align external authentication, workload identity, and internal telemetry across the full request path, not in isolated layers.

Key terms

• API Gateway: An API gateway is the external control point that receives client requests before they reach backend services. It authenticates callers, applies policy, limits usage, and can transform requests so the service layer is protected from direct exposure.
• Service Mesh: A service mesh is an internal traffic control layer for service-to-service communication. It adds encryption, identity, routing policy, and observability so workloads can communicate securely without relying on implicit network trust.
• Workload Identity: Workload identity is the cryptographic identity assigned to a non-human workload, such as a service or container. It lets systems authenticate one another independently of IP address or static secret use, which is essential for governed east-west communication.
• East-west Traffic: East-west traffic is communication that moves between internal services rather than in and out of the perimeter. It is a key governance boundary because internal trust assumptions can hide privilege, movement, and misuse if identity is not enforced at the service level.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Service Mesh vs. API Gateway: What’s the Difference? Read the original.