Why do microservices environments need both workload identity and API security?

Why This Matters for Security Teams

Microservices create a split-brain security problem. workload identity answers “which service is this?” so internal calls can be trusted, while API security answers “what is this request trying to do?” so exposed endpoints can be defended against abuse, malformed inputs, and rate anomalies. The distinction matters because internal east-west traffic and external north-south traffic fail in different ways. In NHI terms, a service account, token, or certificate is only one layer of control; it does not validate the safety of the request itself. NHIMG research notes that 57% of organisations lack a complete inventory of their machine identities, which makes identity-centric governance harder from the start, as discussed in the Ultimate Guide to NHIs.

For implementation detail, the SPIFFE workload identity specification is useful because it separates cryptographic workload identity from application logic. That separation is exactly why API gateways, WAF rules, and schema validation still matter after identity has been established. In practice, many security teams discover this only after an internal service is trusted too broadly and an exposed API is already being probed or abused.

How It Works in Practice

A mature microservices design uses both controls at the same time. Workload identity establishes a trustworthy service-to-service foundation, typically with short-lived credentials, mutual TLS, or signed tokens bound to the workload. API security then enforces request-level constraints such as authentication, authorisation, schema validation, throttling, and abuse detection. The two layers complement each other: identity decides whether the caller is legitimate, while API security decides whether the specific action and payload are acceptable.

Operationally, teams usually split the control plane this way:

• Use workload identity for service authentication, service discovery, and least-privilege service authorization.
• Use API gateways or ingress controls for schema checks, rate limits, request size limits, and token validation.
• Use policy-as-code for context-aware decisions when a request needs more than static RBAC.
• Rotate secrets and certificates aggressively, because long-lived credentials are a durable failure mode.

NHIMG guidance on machine identity shows why this is non-negotiable: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 20% of organisations have formal processes for offboarding and revoking API keys. That is covered in the Ultimate Guide to NHIs, while the Guide to SPIFFE and SPIRE helps explain how to anchor workload identity in verifiable cryptography rather than shared secrets.

These controls tend to break down when teams assume an internal mesh makes API abuse impossible, because compromised workloads can still send valid requests at machine speed.

Common Variations and Edge Cases

Tighter request controls often increase latency and operational overhead, so organisations have to balance stronger protection against deployment complexity. That tradeoff becomes more visible in service meshes, multi-cluster environments, and hybrid estates where identity issuance, policy enforcement, and traffic inspection are not all centralized.

Current guidance suggests treating these as layered controls rather than interchangeable ones, but there is no universal standard for how much logic should sit at the gateway versus inside the service. For example, some teams enforce coarse API controls at the edge and finer-grained intent checks in the service itself. Others rely on central policy engines for both. The right answer depends on service criticality, blast radius, and how consistently identity metadata is propagated.

NHIMG’s breach research reinforces the point that identity alone is not enough. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both show how quickly weak identity governance turns into broader exposure when secrets, permissions, and API paths are left too open. The practical rule is simple: workload identity proves who is calling, API security constrains what that caller can do, and neither control should be treated as a substitute for the other.

Related resources from NHI Mgmt Group

• How should security teams build resilience into hybrid identity environments?
• What do security teams get wrong about workload identity in cloud and CI/CD environments?
• How should security teams govern workload identity across mixed cloud environments?
• How should security teams unify identity visibility across IAM, PAM, and NHI systems?