NHI runtime authorization: are your controls keeping up?

TL;DR: Non-human identities outnumber human users by roughly 17 to 1 in most organisations, and many teams still lack visibility into what service accounts and workload identities do at runtime, according to Cerbos. The missing control is not rotation alone but request-level authorization, because standing overprivilege turns every valid secret into an unnecessary blast radius.

NHIMG editorial — based on content published by Cerbos: runtime authorization for non-human identities

By the numbers:

• Non-human identities now outnumber human users in most organizations by roughly 17 to 1.
• Only 15% of organizations feel confident in their ability to secure NHIs, according to the NHI Management Group.
• 50% of surveyed organizations had a breach in the past year tied to compromised machine identities, with poorly scoped API keys, SSL/TLS certificates, and service account tokens as the most common vectors.

Questions worth separating out

Q: How should security teams implement runtime authorization for non-human identities?

A: Start by identifying the service-to-service requests that matter most, then enforce policy at the decision point rather than in application code.

Q: Why do non-human identities create more overprivilege risk than human users?

A: Because machine identities are often granted broad permissions to keep systems running, and those permissions persist even when the underlying workload only needs a narrow action set.

Q: How do security teams know if NHI authorization is actually working?

A: Look for consistent allow and deny decisions at runtime, complete audit logs for each request, and fewer services that need code-level permission checks.

Practitioner guidance

• Map the highest-risk service-to-service flows first Start with the interactions that can reach customer data, payment systems, or production admin paths, then define the exact actions each workload needs rather than granting service-wide access.
• Move authorization decisions out of application code Centralize policy evaluation so teams stop duplicating if statements and ad hoc checks across services, which creates inconsistent access behaviour and uneven auditability.
• Require action-level policy rules for every sensitive resource Write allow conditions around the specific action, resource, identity, and context, then deny everything else by default so a valid secret cannot automatically imply broad access.

What's in the full article

Cerbos' full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step policy logic for evaluating principal, resource, and action at runtime
• SPIFFE identity parsing examples for service-to-service authorization flows
• Request and audit-log payload examples that show how allow and deny decisions are recorded
• Implementation patterns for sidecar or centralized deployment alongside existing authentication

👉 Read Cerbos' article on runtime authorization for non-human identities →

NHI runtime authorization: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →