Notifications
Clear all
Topic starter
10/06/2026 11:10 pm
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
12/06/2026 5:00 am
Runtime authorization is the point where NHI governance becomes enforceable. Discovery and rotation help teams see and refresh machine identities, but they do not constrain what those identities can do at request time. Without a policy decision layer, the programme can catalog excess privilege without actually limiting it. The implication is that NHI control maturity should be measured by decision precision, not by inventory completeness.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most programmes still cannot govern machine identity sprawl end to end.
A question worth separating out:
Q: Should organisations treat workload identity frameworks as enough for NHI governance?
A: No. Workload identity improves authentication, but it does not decide whether a specific action should be allowed on a specific resource. Organisations need both strong identity proofing for machines and a policy layer that evaluates requests in context. Without that second layer, verified identities can still be overprivileged.
👉 Read our full editorial: Runtime authorization is the missing layer in NHI governance
