Microservices security and access control: what IAM teams miss

At a glance

What this is: This is a microservices security guide that argues distributed architectures require stronger, service-level authentication, authorization, token handling, and communication controls.

Why it matters: It matters because the same governance gap that weakens service-to-service access in microservices also shows up in workload identity, privileged machine access, and policy drift across IAM programmes.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Cerbos's guide to microservices security and access control

Context

Microservices security fails when teams assume a monolith's centralized trust model still applies after identity, policy, and traffic are split across many services. Once authentication and authorization move closer to each service, the governance challenge becomes consistent enforcement across a distributed runtime, not simply stronger perimeter controls.

That shift matters to IAM and platform teams because each service becomes a policy enforcement point, each token becomes a bearer of delegated trust, and each communication path becomes part of the attack surface. For teams governing workload identity and service access, this is the same structural problem described in the Ultimate Guide to NHIs, where control quality depends on visibility, rotation, and lifecycle discipline.

Key questions

Q: How should security teams implement access control across microservices?

A: Security teams should enforce authorization at each service boundary, not only at the API gateway. Each service should validate the caller's identity, inspect token scope and audience, and apply policy based on the requested action. That approach reduces the chance that one weak service becomes a shortcut into the rest of the environment.

Q: Why do microservices increase identity and access risk?

A: Microservices increase risk because trust is distributed across many services, teams, and network paths. That makes inconsistent policy, over-privileged tokens, and weak service-to-service authentication more likely. The result is a larger identity blast radius, where a single control failure can affect many downstream systems.

Q: What do teams get wrong about token-based authentication in microservices?

A: Teams often assume a valid token is enough to authorize every downstream action. In reality, token scope, lifetime, audience, and transport handling determine how much damage a compromised token can do. A token should represent narrowly delegated trust, not a reusable pass for the full service chain.

Q: How do Zero Trust and mTLS work together in microservices?

A: Zero Trust requires every request to be verified, while mTLS ensures both services prove identity before exchanging data. Together they reduce implicit trust in internal traffic, but they still need fine-grained authorization to decide what the authenticated service can actually do. Encryption and identity proof are necessary, but not sufficient.

Technical breakdown

Decentralized authentication and authorization in microservices

Microservices replace one central security boundary with many smaller ones. Authentication proves who or what is calling a service, while authorization decides what that caller may do. In practice, this often means issuing tokens such as JWTs or OAuth access tokens and validating them at each hop. The architectural risk is inconsistency. If one service accepts looser claims, skips validation, or applies weaker policy logic, the entire chain inherits that weakness. Zero Trust pushes back on implicit trust by requiring every request to be verified and evaluated against policy, not just the first login.

Practical implication: standardize token validation and policy evaluation at every service boundary, not only at ingress.

Token propagation and bearer risk

Token propagation is the process of carrying a caller's identity and permissions across multiple services. It is useful because services can make authorization decisions without re-authenticating the original user at every step. The downside is that the token becomes a compact trust container. If it is over-privileged, too long-lived, or exposed in transit, any compromise can move laterally through the environment. This is why token scope, audience, expiry, and transport protection matter as much as the authentication event itself.

Practical implication: constrain token scope and lifetime tightly, and treat token handling as a lateral-movement control.

Service-to-service communication and mTLS

Microservices depend on frequent inter-service calls, so transport security alone is not enough. TLS encrypts data in transit, while mutual TLS adds reciprocal authentication so both sides prove identity before exchanging data. That matters because service-to-service traffic is often assumed to be internal and therefore safe, which is exactly the wrong assumption in a distributed system. API gateways help at the edge, but they do not secure every east-west call. Fine-grained authorization must follow the request deeper into the mesh.

Practical implication: combine mTLS with service-level authorization so internal traffic is verified, not merely encrypted.

NHI Mgmt Group analysis

Microservices security exposes the limits of monolith-era trust assumptions. A monolith can centralize policy, but microservices force identity and authorization logic to operate across many independently deployed services. That creates a governance problem, not just an implementation problem, because one inconsistent service can weaken the access model for the whole environment. The implication is that programme owners must treat distributed enforcement as a core control design requirement, not an architectural afterthought.

Token propagation creates a wider identity blast radius than many teams account for. When tokens move across service boundaries, they become portable trust decisions that can be replayed, overused, or mishandled if scope and lifetime are not tightly constrained. This is a machine identity problem as much as an application problem, because the token often represents delegated non-human access rather than a person. Practitioners should see token handling as part of NHI governance, not just application authentication.

Zero Trust only works in microservices when internal traffic is treated as untrusted by default. The article's core security pattern is not the gateway itself, but the assumption that every request must be authenticated and authorized at the point of use. That aligns directly with workload identity and policy enforcement discipline, where control quality depends on continuous verification rather than network placement. Security teams should design for verification at each hop, not rely on the idea of a safe internal zone.

Policy consistency becomes the real control plane in microservices. When different teams own different services, security only holds if authentication, authorization, and communication rules are enforced consistently across the fleet. A single weak service can become the easiest route into the broader environment. For IAM and platform teams, that means governance maturity is measured by policy consistency, not by how many services have been onboarded.

Named concept: identity blast radius. In a microservices environment, the damage from one weak token, one misconfigured service, or one inconsistent policy is rarely isolated to a single application. The impact spreads along service dependencies because each call extends the trust chain. That is the practical meaning of identity blast radius, and it is why distributed systems need stronger control boundaries than monoliths ever did.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why service-to-service trust often outruns governance.
• If you are building out access governance for distributed systems, start with Ultimate Guide to NHIs - Key Challenges and Risks for the visibility and over-privilege patterns that commonly surface first.

What this signals

Identity blast radius: microservices do not just increase the number of controls to manage, they increase the number of places a trust failure can spread. For practitioners, that means access reviews, logging, and policy drift detection need to be designed around service relationships, not just individual workloads.

The NHI governance lesson is straightforward: if a service account, token, or certificate can be reused across multiple calls, the programme is already dealing with delegated machine trust. That is why teams should tie service identity controls to lifecycle management and policy consistency, not leave them embedded in application code.

As service meshes and gateway patterns mature, the practical question becomes whether identity policy is enforced centrally or merely distributed. Teams that can answer that clearly will be better positioned to align with OWASP Non-Human Identity Top 10 and the verification model behind Zero Trust.

For practitioners

• Enforce service-level authorization everywhere Require each microservice to validate identity and policy at the point of access, even when requests originate from trusted internal systems. Do not treat ingress controls as sufficient for east-west traffic.
• Shorten token lifetime and narrow token scope Issue tokens only for the audience and operations required for the current transaction. Revisit expiry, audience, and claim content so a captured token cannot authorize broad lateral movement.
• Pair mTLS with fine-grained policy checks Use mutual TLS to authenticate both ends of the connection, then apply authorization rules based on service identity, request context, and requested resource. Encryption alone does not establish access intent.
• Standardize policy enforcement across service teams Define a common control pattern for authentication, authorization, and logging so every team implements the same security baseline. Inconsistent policy is a governance failure, not just a development defect.

Key takeaways

• Microservices security breaks down when teams assume monolith-era trust and control patterns still work in a distributed environment.
• Tokens, mTLS, and service-level authorization all reduce risk, but only if they are enforced consistently across every service boundary.
• The real governance challenge is identity blast radius, where one weak control can propagate across the full service chain.

Key terms

• Token Propagation: Token propagation is the passing of an authenticated identity token from one service to another so downstream systems can make access decisions without reauthenticating the original caller. It increases convenience and traceability, but also concentrates trust into a portable credential that must be tightly scoped and short-lived.
• Service-to-Service Authorization: Service-to-service authorization is the policy decision that determines whether one service may call, read, or modify another service's resources. In microservices, this must happen at runtime for each request, because internal traffic is not automatically trustworthy just because it stays inside the network.
• Identity Blast Radius: Identity blast radius is the amount of downstream exposure created when one identity control fails, such as a weak token, a misconfigured service, or an overly broad permission set. In distributed systems, the blast radius can spread across many services because trust chains are shared and reused.

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 Cerbos: security and access control in microservices. Read the original.