Service-to-service authorization: what IAM teams need to govern now

TL;DR: Service-to-service authorization gives microservices their own identity so teams can control access, rate limits, logging, and policy decisions without relying on the original user context, according to Cerbos. That shift turns service identities into a governance surface that IAM, IGA, and platform teams must treat as first-class non-human identities.

NHIMG editorial — based on content published by Cerbos: service-to-service authorization and non-user principals

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

Questions worth separating out

Q: How should security teams govern service-to-service authorization in microservices?

A: Treat each service as a non-user principal with its own policy, credential, and audit trail.

Q: Why do service identities need separate governance from user identities?

A: Because the service, not the person, is the actor making the downstream request.

Q: What breaks when service-to-service access is controlled only by human identity?

A: You lose service-level accountability, coarse-grained permissions become too broad, and downstream APIs cannot distinguish which workload should be trusted for which action.

Practitioner guidance

• Assign every service a distinct principal Map each microservice, background process, and third-party integration to its own identity so authorization and observability follow the workload rather than the original user request.
• Centralise service authorization policy Store service permissions as code in one policy layer so teams can test, review, and version internal access rules instead of reimplementing them in each service.
• Scope credentials to the service's real job Use short-lived tokens where possible and restrict long-lived API keys to the narrowest set of endpoints, actions, and environments the service actually needs.

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 service-to-service authentication flows differ across monoliths, APIs, and microservices.
• Implementation patterns for using JWT, OAuth, and API keys with non-user principals in distributed systems.
• Deployment options such as sidecar, systemd service, and Lambda execution for policy enforcement.
• Practical examples of how one policy repository can support multiple service instances.

👉 Read Cerbos's guide to service-to-service authorization for non-user principals →

Service-to-service authorization: what IAM teams need to govern now?

Explore further

View Full Forum →  |  NHI Foundation Course →