Zero Trust authorization gaps in cloud systems and NHI access

At a glance

What this is: This is a Zero Trust analysis showing that authorization is the control layer that most often fails after identity is established, especially in cloud and microservice environments.

Why it matters: It matters because IAM, NHI, and platform teams all inherit the same problem: authenticated identities can still cause damage when permissions are static, scattered, or poorly audited.

By the numbers:

• 86% of organizations have experienced a successful cyber, cyber attack in recent years.

👉 Read Cerbos’s analysis of Zero Trust authorization and layered security

Context

Zero Trust only works when identity is checked continuously and permissions are enforced at the moment of action, not just at login. In cloud systems, that means the real control problem is often authorization, because authenticated users, services, and workloads can still reach data or functions they should never touch.

This article uses aviation safety as a metaphor, but the security lesson is practical: layered defenses matter only if each layer is independent. For IAM and NHI programmes, the failure mode is predictable. Identity proofing and authentication can be sound while authorization logic remains fragmented across applications and services.

That gap becomes more acute as environments add microservices, external identity providers, policy exceptions, and distributed audit requirements. The result is not a lack of security intent, but a control plane that no longer scales with the architecture.

Key questions

Q: How should security teams implement Zero Trust authorization in cloud environments?

A: Start by separating identity proof from permissioning. Use a central policy layer to evaluate every access request against principal, resource, action, and context, then apply the same rules across applications and services. That approach reduces code duplication, improves auditability, and limits the damage caused by one compromised identity.

Q: What breaks when authorization logic is scattered across microservices?

A: Scattered authorization logic creates inconsistent enforcement, hidden exceptions, and audit gaps. One service may allow an action that another denies, which makes lateral movement easier and compliance harder to prove. The practical fix is governance, not just code cleanup: establish one policy model and one decision path.

Q: Why do strong authentication controls still leave systems exposed?

A: Because authentication only proves identity, not intent or entitlement. A valid login, token, or workload certificate can still carry broad permissions that let an attacker read, delete, or move laterally once inside. The remaining risk lives in authorization, where the system decides what the identity can actually do.

Q: What should organisations audit in their access control model first?

A: Audit the high-value actions that would cause the most harm if misused, then trace how each action is authorized across services, regions, and roles. If the same decision is implemented in multiple places, prioritise that path for consolidation because inconsistency there creates the largest blast radius.

Technical breakdown

Why authorization becomes the weak link in Zero Trust

Authorization is the decision about what an authenticated identity may do next. In simple systems, that logic can live in application code, but as environments grow it becomes entitlements, regional restrictions, role hierarchies, and audit obligations layered on top of each other. Each additional condition increases the chance of inconsistent enforcement. In a Zero Trust model, that is the critical failure point, because a valid identity token is not the same as a valid action. The architecture only holds if every request is evaluated against policy in context, every time.

Practical implication: move access decisions out of scattered code paths and into a consistent policy layer.

How layered security and policy decision points reduce blast radius

A layered model works because each control compensates for another control’s blind spots. Identity checks stop unauthenticated access, encryption limits data exposure, and policy decision points validate whether the authenticated principal can perform the requested action on that resource. This is the architectural difference between perimeter security and Zero Trust. The policy engine does not replace application logic, but it centralizes decisioning so the same rules apply across services, languages, and teams. That consistency is what prevents small authorization mistakes from becoming systemic exposure.

Practical implication: centralize policy evaluation so every service enforces the same access rules.

SPIFFE, OAuth2 and microservice identity do not solve authorization by themselves

Service identities help prove who or what is calling, but they do not determine whether the call should succeed. SPIFFE and SPIRE can issue strong workload identities, and OAuth2 or OIDC can authenticate users and clients, yet the application still needs a separate authorization decision. That distinction matters in microservices because internal calls are often treated as trusted by default, even though Zero Trust requires the opposite. Once a service is compromised, over-permissioned downstream access becomes the real containment problem.

Practical implication: treat workload identity as the start of control design, not the finish.

Threat narrative

Attacker objective: The attacker aims to convert a single trusted identity into broad operational access and then use that access to move laterally, steal data, or alter systems without immediate detection.

1. Entry occurs when an attacker gains a valid identity through exposed credentials, compromised service access, or another trusted authentication path.
2. Escalation occurs when the identity can reuse broad standing permissions to move laterally or reach data and functions that were never intended for that principal.
3. Impact occurs when missing or inconsistent authorization checks allow unauthorized deletion, exfiltration, or privilege expansion across distributed services.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

Authorization drift is the control failure Zero Trust exposes most clearly: identity can be proven, yet access can still be overbroad, inconsistent, or impossible to audit once business rules accumulate across services. That is why many programmes look mature at the authentication layer but remain brittle at the action layer. The implication is simple: practitioners must treat authorization as the governing control plane, not an application afterthought.

Broken access control is not a point vulnerability, it is an architecture problem: the more systems, languages, and policy exceptions you add, the more likely it becomes that one service enforces rules differently from another. That makes lateral movement easier even when perimeter and identity controls appear sound. Practitioners should read this as a signal that policy consistency matters more than isolated hardening wins.

Policy decision points are the practical expression of Zero Trust at scale: externalizing authorization reduces the chance that every codebase invents its own permission logic. This aligns with NIST SP 800-207 and the broader shift away from implicit network trust. The practitioner takeaway is to design for one source of decision truth before the next audit or architecture expansion makes the current approach unmanageable.

Identity controls for users and workloads do not close the gap unless action-level policy exists: OAuth, SSO, and workload certificates answer who is calling, but not whether the call is allowed. That distinction becomes more urgent in microservices and cloud platforms where internal traffic is assumed safe by default. Practitioners should assume the attacker will use legitimate identity and focus governance on what that identity can actually do.

Policy sprawl: the core governance problem here is not absence of identity, but the uncontrolled spread of permission rules across applications, regions, and teams. This model was designed for simpler systems with stable application boundaries. It fails when access logic is duplicated everywhere and no one can prove the effective policy at the point of use. The implication is that governance must move upstream, or review and compliance will always trail reality.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to the State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• The 52 NHI breaches Report shows how weak lifecycle governance turns credential exposure into repeatable attack paths.

What this signals

Policy sprawl: many organisations will discover that the next Zero Trust failure is not identity proofing but governance fragmentation. Once authorization rules are duplicated across microservices, the programme loses a single source of truth and auditors lose a reliable path to evidence.

For IAM and NHI teams, the practical signal is that workload identity and SSO investments only reduce risk if they are paired with consistent action-level policy. Without that, the environment still behaves as if internal callers are trusted, which is exactly the assumption Zero Trust was meant to remove.

As identity environments spread across cloud, SaaS, and API layers, access review alone will not expose every flaw. Teams need to watch for policy exceptions, hard-coded role checks, and service-to-service paths that bypass central enforcement.

For practitioners

• Map authorization decisions to a single control owner Assign one accountable team to define and maintain access policy across applications, services, and regions. This reduces the risk that different engineering groups encode contradictory rules in separate codebases.
• Externalize policy checks from application code Use a policy decision point so the same principal, action, and resource logic is evaluated consistently at runtime. Keep application code focused on business logic and let the policy engine handle enforcement.
• Review microservice trust assumptions Identify internal service-to-service calls that are treated as trusted by default and require explicit authorization for each call path. This is where lateral movement typically hides.
• Log every access decision in a reviewable format Capture who requested access, what was requested, the policy result, and the context used for the decision. Without that evidence, audit and incident response both become guesswork.

Key takeaways

• The main risk is not weak authentication but weak authorization, because trusted identities can still perform harmful actions.
• The scale of the problem is visible in real-world confidence gaps, with NHI security maturity trailing human identity governance.
• Consolidated policy enforcement and reviewable access decisions are the controls that keep Zero Trust from collapsing into inconsistent application logic.

Key terms

• Authorization: Authorization is the decision about what an already authenticated identity is allowed to do. It evaluates the requested action, the resource, and the current context. In mature environments it must be consistent, auditable, and applied at the point of use, not assumed from login status alone.
• Policy Decision Point: A policy decision point is the component that evaluates access requests against policy and returns allow or deny. It centralizes logic that would otherwise be duplicated across applications, which makes it easier to enforce least privilege, maintain consistency, and produce reliable audit evidence.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Zero Trust Architecture: Zero Trust Architecture is a security model that assumes no implicit trust based on network location or prior access. Every request must be verified using identity, context, and policy. In practice, the model only works when authentication, authorization, and monitoring all reinforce one another.

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: learning Zero Trust from aviation and the missing authorization layer. Read the original.