Notifications
Clear all
Topic starter
24/06/2026 9:14 pm
TL;DR: Microservices widen the attack surface by decentralizing authentication, authorization, token handling, and policy enforcement across many services, according to Cerbos. The governance problem is not microservices themselves but the assumption that monolith-era security patterns still hold once identity, trust, and control become distributed.
NHIMG editorial — based on content published by Cerbos: security and access control in microservices
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
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.
Q: Why do microservices increase identity and access risk?
A: Microservices increase risk because trust is distributed across many services, teams, and network paths.
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.
Practitioner guidance
- 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.
- Shorten token lifetime and narrow token scope Issue tokens only for the audience and operations required for the current transaction.
- 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.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how JWTs are issued, propagated, and validated across service calls
- Implementation detail on using TLS and mTLS together for service-to-service traffic
- How an API gateway can validate tokens, apply rate limits, and hide internal service topology
- The Netflix example showing how policy, gateway, and monitoring choices fit together in practice
👉 Read Cerbos's guide to microservices security and access control →
Microservices security and access control: are your controls keeping up?
Explore further
25/06/2026 6:20 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Microservices security and access control: what IAM teams miss
