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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Zero Trust in cybersecurity - how it works”.
Key questions
Q: How should security teams implement contextual authorization in cloud applications?
A: They should centralise access decisions in a policy layer, then feed that layer the authenticated principal, requested action, target resource, and relevant context on every request.
Q: Why do authenticated identities still create breach risk in Zero Trust environments?
A: Zero Trust reduces implicit trust, but authenticated identities still create risk if they retain too much reach after login.
Q: What are the signs that authorization is becoming a weak point in a microservices environment?
A: The clearest signs are inconsistent access decisions, duplicated authorization logic across services, and policy drift when teams ship changes independently.
Practitioner guidance
- Map authorization decisions to runtime policy Inventory where access checks are currently embedded in application code, middleware, and service boundaries, then identify which decisions must move to a policy layer so they can be evaluated per request instead of per release.
- Separate authentication from permission logic Review cloud applications to confirm that login success, token validity, or client certificate validation does not implicitly grant access to sensitive functions or data without a fresh authorization decision.
- Standardise authorization logging Ensure every allow and deny decision is logged with the principal, action, resource, and context so auditors can trace why access was granted or blocked across distributed services.
Bottom line: Zero trust weakens quickly when authenticated identities can still act beyond their intended scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 7:13 am
Authorization is the control that decides whether zero trust is real or rhetorical. Authentication can tell you who or what is calling the system, but it cannot stop a verified identity from taking actions it should never have been allowed to perform. In cloud environments, that gap is where lateral movement, data exposure, and compliance failure begin. The practitioner conclusion is simple: if authorization is static, zero trust is incomplete.
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.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
A question worth separating out:
Q: What should teams do when cloud authorization is spread across many services?
A: They should treat scattered access logic as a governance problem and move toward a shared policy model with clear logging, version control, and review. That makes access decisions easier to test, keeps service behavior aligned, and reduces the chance that one application quietly drifts from the intended policy.
👉 Read our full editorial: Zero Trust authorization gaps in cloud systems and NHI access
This post was modified 5 days ago by NHI Mgmt Group