What do security teams get wrong about scaling APIs and service mesh together?

A common mistake is treating scale as a routing problem alone. In practice, growth increases the chance of inconsistent access policy, weak service identity, and unmanaged exceptions across environments. Security teams need repeatable controls for authentication, authorisation, observability, and compliance, otherwise faster delivery can simply amplify existing control gaps.

Why This Matters for Security Teams

Scaling APIs and service mesh together is not just an infrastructure decision. It changes how identities are issued, how trust is enforced, and how policy drift appears across environments. When teams focus only on traffic routing, they often miss the larger issue: every new service, sidecar, gateway, and token exchange multiplies the identity surface. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any API-heavy platform.

This matters because service mesh can make east-west traffic look controlled while the underlying service identities remain weak, over-privileged, or inconsistent. That gap is especially dangerous when APIs are deployed across multiple clusters or teams with different release cadences. Security teams also underestimate how quickly exceptions accumulate when product delivery is optimised faster than policy review. The result is a system that appears standardised on paper but behaves inconsistently under load and change. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity, monitoring, and governance as continuous capabilities rather than one-time setup. In practice, many security teams discover mesh-related trust gaps only after a service-to-service compromise has already spread across an otherwise “managed” platform.

How It Works in Practice

The common mistake is assuming the service mesh will automatically solve authentication and authorisation for APIs at scale. It can enforce mTLS, help standardise service identity, and centralise telemetry, but it does not replace API governance, entitlement review, or application-level policy. Mature implementations treat the mesh as one control plane within a broader identity architecture, not as the identity source of truth. That is where Guide to SPIFFE and SPIRE becomes relevant: workload identity should be cryptographically established so the platform knows what the service is, not just where traffic came from.

Security teams should align API and mesh scale around a few repeatable controls:

• Use workload identity for service authentication instead of static shared secrets.
• Apply least privilege to service-to-service access, with policy boundaries mapped to specific APIs and methods.
• Rotate credentials and certificates automatically, with short TTLs to reduce blast radius.
• Centralise policy-as-code so mesh rules, gateway rules, and API authorisation are evaluated consistently.
• Collect telemetry from both the mesh and the API layer so denied calls, token misuse, and unusual east-west paths are visible.

The Ultimate Guide to Non-Human Identities reinforces why this matters: 71% of NHIs are not rotated within recommended time frames, and 97% carry excessive privileges. At API scale, those two conditions combine into a fast-moving exposure problem. Teams also need to decide where the source of truth lives for identity and policy, because a mesh can enforce transport trust while an API gateway or application still makes the final access decision. These controls tend to break down in multi-cluster, multi-cloud environments because policy ownership fragments faster than identity lifecycle management.

Common Variations and Edge Cases

Tighter mesh enforcement often increases operational overhead, requiring organisations to balance stronger east-west control against deployment complexity and policy maintenance. That tradeoff is real, especially in hybrid estates where not every workload can adopt the same identity or proxy model. Best practice is evolving on how much authorisation should sit in the mesh versus the application, and there is no universal standard for this yet.

One edge case is legacy services that cannot support modern workload identity. Another is partner or third-party API traffic, where the mesh may only cover internal hops while external trust still depends on keys, tokens, or gateway controls. Teams also get caught by “policy shadowing” when a local exception is added to keep a release moving and never gets reconciled back to baseline policy. That is why current guidance suggests treating exceptions as time-bound, reviewable artefacts rather than permanent config. The State of Non-Human Identity Security shows how common weak visibility and poor rotation already are, so any additional exception layer makes control drift harder to detect. For public-facing API platforms, the safest model is to combine mesh-level transport trust with separate governance for authentication, authorisation, and offboarding, rather than assuming one layer can absorb all three.

Related resources from NHI Mgmt Group

• What do security teams get wrong about self-service data APIs in real-time environments?
• What do security teams get wrong about database scaling?
• What do security teams get wrong about protecting service accounts from interception?
• What do security and compliance teams get wrong about self-service transfer setup?