Zero trust now depends on centralized authorization and identity

At a glance

What this is: This is an analysis of why zero trust has become practical now, with centralized authorization and workload identity emerging as the control points that matter most.

Why it matters: It matters because IAM, PAM, and NHI teams need governance models that work across users, workloads, and AI agents without pushing authorization back into application code.

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.

👉 Read Cerbos' analysis of zero trust authorization and workload identity

Context

Zero trust is no longer a network-bound theory. As applications, workloads, and users move across clouds and distributed platforms, security teams need a control model that identifies every request by identity rather than by location.

The hard part has never been the principle. It has been making identity-based authorization auditable and scalable across humans, service accounts, and AI-driven workloads without embedding policy logic into every application.

For teams building workload identity programmes, this is where standards matter. SPIFFE and related identity patterns give distributed systems a verifiable way to prove who or what is asking, while zero trust gives the governance model around that proof.

Key questions

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. Keep policies version-controlled, log every decision, and expose the control to review and testing. That gives IAM and security teams a single place to govern access changes across distributed services.

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. When their permissions are embedded in code or spread across many services, teams lose a clear view of what they can do. That makes blast radius larger and access reviews less reliable.

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. A single policy update can require multiple code changes, and teams lose a dependable record of who can access what. That is a control gap, not just a convenience issue.

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.

Technical breakdown

Why centralized authorization matters in zero trust

Authorization answers a different question from authentication. Once an identity is verified, the system still needs to decide what that identity can do, and hidden authorization logic inside each application makes that decision opaque, inconsistent, and difficult to audit. A centralized Policy Decision Point externalizes the decision, so applications ask a shared service for allow or deny based on policy. That architecture turns access control into a governable plane instead of a code-level patchwork, which is especially important when policies must change across many services at once.

Practical implication: move high-risk access decisions out of application code and into a central policy layer.

How SPIFFE and OIDC fit different identity problems

OpenID Connect is the federation layer for human and federated authentication, while SPIFFE provides strong workload identity for services and software running in distributed environments. The point is not to collapse them into one mechanism, but to use each where it fits: OIDC for user-centric trust and SPIFFE for machine-to-machine trust. That distinction matters because non-human identities need cryptographic proof that can travel with the workload, not a human login session or a shared secret copied between systems.

Practical implication: separate human authentication and workload identity controls instead of forcing one identity mechanism to do both jobs.

Why zero trust fails when policy is hard-coded

Hard-coding authorization in applications creates a fragmented control surface. Each service becomes its own policy island, which makes privilege reviews slow, change management brittle, and audit evidence incomplete. In distributed environments, that design also increases blast radius because one compromised service may inherit more access paths than its business function requires. Zero trust only becomes operational when policy is centralized, versioned, and enforced consistently at the point of decision rather than at the point of code deployment.

Practical implication: treat authorization policy as a shared control service with versioning, logging, and review workflows.

Threat narrative

Attacker objective: The objective is to turn one compromised identity into broad, repeatable access across distributed systems without tripping centralized controls.

1. Entry occurs when an attacker reaches a verified identity or an overly trusted workload in a distributed environment, often through exposed secrets or weakly governed service access.
2. Escalation follows when hidden or hard-coded authorization grants the compromised identity more action than its business role should allow, enabling lateral movement across services.
3. Impact is the expansion of blast radius, where the attacker uses legitimate request paths to access sensitive data or trigger high-value actions across cloud and application layers.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Workload identity is now a core NHI governance problem, not a niche platform topic. As services spread across Kubernetes and multi-cloud environments, the old model of static secrets and environment-bound trust stops scaling. SPIFFE-style workload identity gives security teams a more durable way to govern machine actors, and that aligns directly with NHI lifecycle, rotation, and offboarding discipline. The implication is that identity programmes must cover software identities with the same rigor as human access.

Zero trust is becoming a control architecture for both NHIs and emerging agentic systems. The article notes that autonomous AI agents increase the urgency, and that is directionally correct. Once software can initiate actions on its own, request-level policy becomes the boundary between contained behavior and uncontrolled execution. Practitioners need to think beyond perimeter removal and ask whether every non-human actor has a decision model that is observable, versioned, and revocable.

Blast radius is the right business metric for this shift. The value of centralized policy is not abstract architecture purity. It is that a compromised service should not be able to turn one credential into broad lateral movement. That maps directly to NIST Zero Trust thinking and to NHI governance realities where excessive privilege remains the norm. Security leaders should measure whether policy centralization is actually shrinking reachable action, not just simplifying administration.

From our research:

• 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.
• For the governance model behind workload identity, see Guide to SPIFFE and SPIRE, which explains how cryptographic workload identity supports zero-trust enforcement.

What this signals

Identity blast radius: the practical test for zero trust is not whether a service can authenticate, but whether a compromised identity can keep operating outside its intended role. Teams that cannot answer that question precisely should expect policy centralization to become a governance priority, not a platform refinement.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, distributed authorization models will keep failing unless entitlement scope becomes more tightly bound to request context and workload identity.

For identity programmes, the next step is to align zero trust controls with NIST SP 800-207 Zero Trust Architecture and with workload identity guidance such as the Guide to SPIFFE and SPIRE, because policy and proof now need to work together.

For practitioners

• 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.
• Measure blast radius, not just authentication coverage Test how far a compromised service account or token can move laterally and whether a policy engine actually blocks requests outside the intended role.

Key takeaways

• Zero trust becomes operational only when authorization is centralized and auditable, not when authentication is merely stronger.
• Workload identity and non-human governance now sit at the center of distributed access control, especially as AI agents add more autonomous request paths.
• The real measure of success is reduced blast radius, which depends on request-level policy, visible entitlements, and revocable machine identity.

Key terms

• Policy Decision Point: A Policy Decision Point is a centralized service that evaluates access requests against policy and returns allow or deny. In practice, it separates authorization from application code so decisions are consistent, versioned, and auditable across many services and identities.
• Workload Identity: Workload identity is the cryptographic identity assigned to a software service, container, or machine workload. It lets systems verify what is calling without relying on shared secrets or network location, which is essential for distributed zero trust architectures.
• Blast Radius: Blast radius is the amount of damage an identity or system can cause if it is compromised. In identity governance, it is shaped by privilege scope, request-level controls, and how easily one credential can be reused to reach additional data or services.
• Non-Human Identity: A non-human identity is any machine or software identity such as a service account, token, API key, certificate, or workload. These identities must be governed through lifecycle, privilege, and revocation controls because they often operate continuously and at scale.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: zero trust, identity standards, and centralized authorization. Read the original.