Notifications
Clear all
Topic starter
11/06/2026 10:50 pm
TL;DR: Authorization, not just authentication, is the missing layer in many Zero Trust architectures because once an identity is trusted, overly broad permissions can still enable lateral movement and data exposure, according to Cerbos. The broader lesson is that access decisions must stay contextual at the point of action, or layered defenses remain incomplete.
NHIMG editorial — based on content published by Cerbos: learning Zero Trust from aviation and the missing authorization layer
By the numbers:
- 86% of organizations have experienced a successful cyber, cyber attack in recent years.
Questions worth separating out
Q: How should security teams implement Zero Trust authorization in cloud environments?
A: Start by separating identity proof from permissioning.
Q: What breaks when authorization logic is scattered across microservices?
A: Scattered authorization logic creates inconsistent enforcement, hidden exceptions, and audit gaps.
Q: Why do strong authentication controls still leave systems exposed?
A: Because authentication only proves identity, not intent or entitlement.
Practitioner guidance
- Map authorization decisions to a single control owner Assign one accountable team to define and maintain access policy across applications, services, and regions.
- Externalize policy checks from application code Use a policy decision point so the same principal, action, and resource logic is evaluated consistently at runtime.
- 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.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- A worked explanation of how the Policy Decision Point evaluates principal, action, and resource at runtime.
- A deeper walkthrough of the authorization evolution from roles to entitlements, compliance, and microservices.
- Examples of how policy decisions can be externalized from application code into a shared enforcement model.
- The article's extended discussion of Zero Trust in practice, including the architectural trade-offs the post only summarizes.
👉 Read Cerbos’s analysis of Zero Trust authorization and layered security →
Zero Trust authorization in cloud systems: where do teams still fail?
Explore further
12/06/2026 7:13 am
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: Zero Trust authorization gaps in cloud systems and NHI access
