Notifications
Clear all
Topic starter
22/06/2026 10:14 am
TL;DR: Microservices increase attack surface by decentralizing authentication, authorization, and service trust, so weak policy consistency or token handling in one service can expose the wider system, according to Cerbos. The security model shifts from perimeter assumptions to consistent identity and policy enforcement across services, making Zero Trust and workload identity operational necessities.
NHIMG editorial — based on content published by Cerbos: securing microservices with centralized authorization
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should teams keep authorization consistent across microservices?
A: Teams should centralize authorization decisions in a single policy model and enforce those decisions uniformly across every service.
Q: Why do microservices increase the risk of lateral movement?
A: Microservices increase lateral movement risk because internal service calls are often trusted too broadly once one component is compromised.
Q: What breaks when service-to-service trust is assumed rather than verified?
A: Implicit trust breaks the security boundary because internal traffic is treated as safe even when a service has already been compromised.
Practitioner guidance
- Standardise authorization at a central policy point Define access rules once and evaluate them at runtime across all services so each team is not maintaining its own security logic.
- Bind service access to workload identity Use cryptographic workload identity rather than network location or cluster membership as the basis for service trust.
- Tighten token audience and delegation handling Validate token audience, scope, and delegation claims at every hop, especially where one service acts on behalf of another identity.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of how Cerbos structures runtime authorization for service-to-service requests.
- The YAML policy examples used to apply fine-grained access control based on workload identity and user context.
- The implementation pattern for on-behalf-of access where one service acts for a user through an act claim.
- The practical flow for logging and auditing authorization decisions at runtime across services.
👉 Read Cerbos' guide to securing microservices with centralized authorization →
Microservices security: what identity teams need to fix first?
Explore further
22/06/2026 11:02 am
Microservices security is really distributed identity governance. Once a monolith is split into services, the problem is no longer only code isolation. The real issue is whether every service identity, token, and policy decision is governed consistently across the application boundary. In practice, the weakest service, the loosest token rule, or the least disciplined team becomes the control failure that defines the whole system. Practitioners should treat microservices security as an identity governance operating model, not a set of isolated technical fixes.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: Who should own microservices security decisions in a distributed architecture?
A: Ownership should be shared between platform, IAM, and application teams, but policy definition needs a clear control owner. Without that, each service team will make its own choices about authentication, authorization, and token handling, and the organisation will inherit inconsistent enforcement that is hard to audit or correct.
👉 Read our full editorial: Microservices security gaps are really identity governance gaps
