TL;DR: Zero trust has moved from theory to execution as identity standards such as OpenID Connect and SPIFFE mature, while centralized authorization replaces hard-coded application logic and narrows blast radius, according to Cerbos. The strategic shift is that access decisions now need auditable, request-level control as infrastructure becomes more distributed and AI agents add new non-human identities.
NHIMG editorial — based on content published by Cerbos: zero trust, identity standards, and centralized authorization
By the numbers:
- 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.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
Questions worth separating out
Q: How should security teams implement centralized authorization in zero trust environments?
A: Start by moving the most sensitive decisions out of application code and into a shared policy service.
Q: Why do service accounts make zero trust harder to operationalise?
A: Service accounts often have broad, persistent access and are difficult to inventory across cloud and application layers.
Q: What breaks when authorization is hard-coded into applications?
A: Hard-coded authorization fragments policy into many local decisions, which makes auditing and change management slow.
Practitioner guidance
- Centralize high-risk authorization decisions Move sensitive allow and deny logic out of individual services into a shared policy decision service so changes are auditable and consistent across the estate.
- Separate human and workload identity controls Use OIDC for federated human access and workload identity standards such as SPIFFE for services, rather than reusing the same trust pattern for both.
- Audit application-owned authorization paths Identify services that still embed role checks, entitlement logic, or conditional access rules in code and replace those paths with versioned policy controls.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- How its centralized authorization model is structured as a policy decision point in real deployments
- Why the vendor argues application-level authorization creates audit and change-management bottlenecks
- How the article frames zero trust for distributed systems, Kubernetes, and autonomous AI agents
- The business-case language used to justify blast-radius reduction and continuous compliance
👉 Read Cerbos' analysis of zero trust authorization and workload identity →
Centralized authorization in zero trust: what IAM teams must change?
Explore further
Zero trust now lives or dies on authorization, not just authentication. The article is right that identity proof alone does not solve distributed access. What breaks in practice is the assumption that verifying who is calling is enough to govern what they can do. Practitioners should treat centralized authorization as the control plane that makes zero trust auditable rather than aspirational.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why distributed authorization often fails at the first governance review.
A question worth separating out:
Q: How do zero trust controls need to change as AI agents become more common?
A: AI agents should be treated as non-human identities with request-level authorization, not as users with special privileges. Their access should be explicit, logged, and revocable, with policy boundaries that limit what they can do if their runtime behavior changes. Otherwise, autonomy turns into unmanaged reach.
👉 Read our full editorial: Zero trust now depends on centralized authorization and identity