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

Why This Matters for Security Teams

Splitting responsibilities between an API gateway and a service mesh is not just an architecture preference. It is a control-plane decision that shapes where authentication, authorisation, observability, and policy enforcement happen. If both layers try to do the same job, teams get duplicated rules, inconsistent telemetry, and gaps in auditability. If one layer is overtasked, the result is brittle policy and slower incident response.

The cleanest model is to let the gateway own north-south traffic control while the mesh governs east-west service communication. That separation aligns with the control intent in the NIST Cybersecurity Framework 2.0 and with identity-heavy NHI guidance from the Ultimate Guide to NHIs. NHIMG research shows why this matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, which means control boundaries must be tight and explicit.

In practice, many security teams discover that the architecture only looked separated on paper after one policy layer failed to log, enforce, or revoke what the other layer assumed it had already handled.

How It Works in Practice

The gateway should be treated as the enforcement point for traffic entering or leaving the platform. That includes client authentication, coarse authorisation, schema or protocol transformation, rate limiting, bot and abuse controls, and request shaping for external consumers. The mesh should take over once traffic is inside the trust boundary, handling service-to-service mTLS, workload identity, retries, service discovery, telemetry, and fine-grained east-west traffic policy.

This split works best when identity is carried consistently across both layers. For workloads, the mesh should assert workload identity using a cryptographic primitive such as SPIFFE-based identities, not just static secrets. For traffic policy, current guidance suggests using policy-as-code so decisions are evaluated at runtime with full context, rather than relying only on pre-defined route rules. The Guide to SPIFFE and SPIRE is useful here because it shows how workload identity can replace ad hoc service credentials.

Security teams should also define which layer owns each control:

• Gateway: external authN, authZ, rate limits, and request normalization.
• Mesh: service identity, mTLS, service-to-service policy, and intra-cluster telemetry.
• Shared: audit logging, incident evidence retention, and policy exception review.

That division reduces the chance that a gateway policy silently diverges from a mesh policy, which is a common cause of drift during fast-moving application releases. These controls tend to break down when legacy services bypass the mesh or when teams attach business logic to gateway rules because the policy model becomes fragmented across inconsistent enforcement points.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance clean control boundaries against deployment complexity. Best practice is evolving for hybrid and multi-cluster environments, where traffic may cross multiple gateways and meshes before reaching a workload. In those cases, teams need a documented source of truth for identity, policy precedence, and logging ownership.

There are also exceptions. Public APIs may need advanced gateway inspection for schema validation or token exchange, while internal platform services may use the mesh for both mTLS and service identity enforcement. The key is not where a control lives in theory, but whether it is enforced exactly once and audited consistently. The NIST CSF emphasis on governance and continuous monitoring is especially relevant when teams operate multiple ingress paths or third-party integrations.

One practical warning is that gateway-only designs often miss lateral movement, while mesh-only designs can over-assume the trustworthiness of inbound requests. Mature teams usually combine both layers with strong secrets hygiene, short-lived credentials, and clear ownership of revocation. That is the operational lesson hidden inside the NHI data: excessive privileges and slow rotation are not abstract risks, they are the conditions that make split enforcement necessary.

Related resources from NHI Mgmt Group

• How should security teams implement token exchange in API gateways?
• How should security teams split responsibility between workload IAM and API security?
• How should security teams split responsibilities between AD recovery, ITDR, and access governance platforms?
• How should security teams split responsibilities between an IdP and an upstream authenticator?