Service-to-service authorization exposes the next NHI governance gap

At a glance

What this is: This is a guide to service-to-service authorization, showing why non-user principals let distributed systems make access decisions without depending on the original user identity.

Why it matters: It matters because IAM programmes that stop at human sign-in controls miss the service identities, policy logic, and downstream permissions that actually govern modern application behaviour.

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.

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

Context

Service-to-service authorization is the control layer that decides what one application or service can do when talking to another. In distributed systems, that problem is no longer hidden inside a single monolith, because the original user identity is often absent by the time a background job or downstream API call is made. Service-to-service authorization therefore becomes a core part of NHI governance, not just an application design detail.

The security issue is not whether services can authenticate at all, but whether each service has a durable, scoping identity that lets teams enforce least privilege, rate limiting, monitoring, and auditability. When service identities are treated as first-class principals, platform teams can govern machine-to-machine access with the same discipline they apply to other non-human identities.

That is where the governance boundary shifts. Instead of asking only who the user is, practitioners have to ask what the calling service is allowed to do, how much standing access it has, and whether policy is being enforced centrally or reimplemented in every service.

Key questions

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. Centralise authorization decisions so access rules are versioned and testable, then scope permissions to the specific API, environment, and action the service needs. That approach reduces drift across teams and keeps machine-to-machine access governable.

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. User-centric access rules often fail once background jobs, internal APIs, or third-party integrations act without the original human context. Separate governance lets teams apply the right limits, logging, and accountability to each machine principal.

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. That usually leads to over-permissioned services, inconsistent rate limiting, and weak audit trails across internal systems.

Q: How do teams reduce risk from long-lived API keys in service communication?

A: Limit long-lived keys to the smallest possible scope, prefer short-lived tokens where the architecture allows it, and keep credential issuance separate from application code. The goal is to make each machine identity easier to revoke, rotate, and inspect without disrupting unrelated services.

Technical breakdown

Non-user principals in distributed systems

A non-user principal is an identity attached to a service, API, or workload rather than a person. In microservice architectures, this identity lets systems distinguish between the end user who started a workflow and the service that is now executing a downstream action. That distinction matters because authentication and authorization decisions often need to be made after the original request context has been lost. Once a service becomes the principal, it can be assigned scoped permissions, rate limits, and monitoring rules that reflect its actual role in the system.

Practical implication: model each service as an identity object and govern it separately from the human that triggered the request.

Authentication patterns for service-to-service traffic

Service-to-service authentication is usually built around JWTs, OAuth, or long-lived API keys issued to the service itself. Unlike human sign-in, the service is both the client and the identity, so the trust model is machine-to-machine rather than user delegation. That changes the risk profile because the credential often lives in application infrastructure, not in an interactive session. Where short-lived tokens are possible, they reduce exposure, but the more important point is that authentication must prove the calling workload, not the upstream user.

Practical implication: separate service credentials from user sessions and avoid designs that let downstream systems infer trust from the original human login alone.

Policy-based authorization for internal APIs

Authorization in this model is about what a service is allowed to do after it has been identified. In practice, that often means centralising policy so teams do not hardcode permission rules into every microservice. A policy engine can evaluate the calling service, the target resource, the action, and any contextual attributes such as environment or team ownership. This reduces duplication and prevents each service team from inventing its own access semantics. It also makes service permissions auditable and testable as code, which matters when authorization spans many APIs and deployment models.

Practical implication: keep service authorization policy central and versioned so internal APIs do not drift into inconsistent local access rules.

NHI Mgmt Group analysis

Service-to-service authorization is now a primary NHI governance control, not an implementation detail. Once services can call other services without human involvement, the identity surface expands beyond users into workload principals, API keys, and internal tokens. That means access decisions have to follow the service, not the person who initiated the workflow. Practitioners should treat machine identities as governed actors in their own right.

Fine-grained policy is the real control boundary in microservice environments. The article shows why a single user-centric authorization model breaks down when different services need different access to the same API. Coarse user permissions cannot express service-specific limits, so organisations need policies that distinguish internal services, external integrations, and critical downstream systems. The implication is that service authorization has to be explicit, testable, and centrally managed.

Identity sprawl becomes an architectural risk when every team invents its own service credential model. Distributed systems often encourage local fixes, but that approach turns service identities into unmanaged security debt. Central policy and shared identity semantics reduce drift across teams, environments, and deployment patterns. Practitioners should assume service identity growth will outpace manual governance unless it is controlled as part of the identity programme.

Coarse-grained trust in the calling service creates unnecessary blast radius. When a downstream API cannot distinguish between services that need different privileges, the result is over-permissioned machine accounts and weak accountability. That problem is especially visible in background jobs, shared APIs, and third-party integrations. The practical conclusion is that service identities need segmentation, not just authentication.

Rate limiting and logging become governance controls when they are tied to non-user principals. The article correctly frames these functions as identity-aware controls rather than generic platform features. A service identity lets teams see which workload is generating load, noise, or abnormal calls. Practitioners should use that visibility to tighten operational and security boundaries at the service level rather than the user level.

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 is why service-to-service authorization cannot be governed through owner memory alone.
• That visibility gap is explained further in Ultimate Guide to NHIs , Key Challenges and Risks, where over-privilege and unmanaged credentials are treated as structural programme risks.

What this signals

Service identity governance is drifting from platform concern to programme requirement. As more application logic moves into distributed services, IAM teams need a policy model that can distinguish workload principals from the humans who launch them. The governance question is no longer whether services can authenticate, but whether their access can be reviewed, tested, and revoked as a separate identity class.

Identity blast radius is the named concept teams should track here: the amount of downstream access a single service principal can exercise before policy catches up. When service identities are reused across internal systems, the blast radius expands faster than most access review cycles can absorb. That makes central policy, scoped credentials, and observability around machine principals the programme-level priorities.

With 97% of NHIs carrying excessive privileges, the pattern is already familiar: machine identities accumulate more access than their operating role justifies. That is why service-to-service authorization should be folded into NHI lifecycle governance and zero-trust design, not left as an application-team convenience.

For practitioners

• 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.
• Separate critical downstream services from generic traffic Give important services their own limits, monitoring thresholds, and access rules so heavy use by one team does not degrade the whole platform.

Key takeaways

• Service-to-service authorization turns internal APIs into governed identity boundaries, not just technical integration points.
• Machine identities need separate policy, logging, and revocation because user-centric access models do not cover downstream service behaviour.
• Centralised authorization and scoped credentials reduce the blast radius created when many teams share the same distributed architecture.

Key terms

• Non-user principal: An identity assigned to a service, workload, API, or other machine actor rather than a person. It lets organisations govern machine behaviour directly, including authentication, access control, logging, and revocation, instead of inferring trust from the human who started the workflow.
• Service-to-service authorization: The process of deciding what one application or service is allowed to do when it calls another. In practice, it requires machine-specific policy, not just user authentication, so downstream systems can distinguish one workload from another and enforce least privilege consistently.
• Machine identity: A digital identity used by software or infrastructure to prove who it is and what it may access. For distributed systems, machine identity is the control point that lets teams apply policy, monitoring, and revocation to APIs, background jobs, and internal services.
• Policy as code: An approach that stores authorization rules in version-controlled code instead of scattered application settings. It makes access logic reviewable, testable, and repeatable across services, which is especially useful when many teams share the same distributed platform.

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: service-to-service authorization and non-user principals. Read the original.