Zero trust authorization gaps in cloud-native identity controls

At a glance

What this is: This is an analysis of how adaptive, context-aware authorization closes the gap between Zero Trust theory and real-world IAM practice.

Why it matters: It matters because IAM teams have to govern not just login, but every access decision across NHI, autonomous, and human identity programmes.

By the numbers:

• 96% of orgs believed MFA could have prevented or minimized an identity-related breach.

👉 Read Cerbos' analysis of adaptive authorization for Zero Trust

Context

Zero Trust Architecture fails when organisations treat authentication as the finish line. In many environments, the real control gap appears after login, where static roles and broad entitlements still govern what a user, workload, or API token can do.

That gap is especially visible in cloud-native systems, where access decisions need to reflect device posture, location, behavior, and resource sensitivity in real time. For practitioners building on Zero Trust, the issue is not whether to verify identity, but how to keep authorization aligned with changing risk.

Key questions

Q: How should security teams implement dynamic authorization in cloud-native environments?

A: Start by moving the decision point out of the application and into a policy layer that can inspect request context before allowing access. Use attributes such as device posture, location, resource sensitivity, and action type to decide each transaction. Begin with the highest-risk systems first, then expand once policy testing, logging, and exception handling are reliable.

Q: Why do static roles fail under Zero Trust Architecture?

A: Static roles assume that one assignment can safely govern many future requests, but Zero Trust requires trust to be re-evaluated continuously. The same role may be safe for one device, one location, or one action and unsafe for another. That is why coarse RBAC often leaves broad access in place after authentication, which is exactly what Zero Trust is meant to avoid.

Q: What breaks when MFA is treated as the only Zero Trust control?

A: MFA improves confidence at login, but it does not control what happens after the session is established. If downstream authorization stays static, a valid token can still reach sensitive systems, even when the context changes. Teams end up with stronger entry checks but the same broad internal access model, which leaves the core Zero Trust gap untouched.

Q: What is the difference between adaptive authentication and adaptive authorization?

A: Adaptive authentication changes how identity is verified at sign-in, often by increasing friction when risk is higher. Adaptive authorization changes what the authenticated identity can do after sign-in by evaluating each request in context. Both matter, but only adaptive authorization governs the action itself, which is where Zero Trust either succeeds or fails in practice.

Technical breakdown

Static RBAC versus context-aware authorization

Role-based access control assigns permissions once, then reuses them regardless of situation. That works when access patterns are stable, but it breaks down when the same identity may be safe in one context and risky in another. Attribute-based and policy-driven authorization evaluate the request itself, not just the assigned role. They can combine user attributes, device posture, location, time, resource sensitivity, and action type to decide whether to allow, deny, or step up verification. In Zero Trust terms, this is how authorization becomes continuous rather than implicit. It also creates a cleaner separation between identity proofing and access governance, which is essential when applications need real-time decisions.

Practical implication: move high-value applications from coarse RBAC to policy-based decisions that can inspect request context before every action.

Why adaptive authentication is only the first control layer

Adaptive authentication changes how access starts, usually by applying extra verification when a login looks unusual. That helps reduce account compromise risk, but it does not govern what happens after the token is issued. A session can still carry broad rights long after the initial challenge is complete. Zero Trust therefore needs both a stronger entry control and a stronger in-session decision layer. In practice, this means MFA and conditional access should feed into downstream authorization logic, rather than being treated as a substitute for it. Without that second layer, the environment still relies on trust that was granted once and never revisited.

Practical implication: treat adaptive MFA as necessary but insufficient, and pair it with action-level authorization checks for sensitive systems.

Policy-as-code for distributed application estates

Modern authorization often has to work across microservices, SaaS, APIs, and legacy applications at the same time. Central policy engines help by externalizing the decision logic instead of embedding rules inside every app. That makes access decisions more consistent and easier to audit, especially when business rules need to change quickly. It also reduces the chance that one application becomes an exception that quietly weakens the whole model. In cloud-native estates, this approach supports continuous enforcement without requiring a full re-platforming effort. The architectural point is simple: Zero Trust becomes operational when the authorization rule is shared, testable, and enforceable everywhere.

Practical implication: externalize authorization into centrally managed policies so teams can enforce the same rule set across applications and services.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Static access models are the wrong control plane for Zero Trust. RBAC, network zones, and one-time login checks were designed for a world where trust could be inferred after initial verification. That assumption fails in cloud-native environments because the risk of a request changes faster than the role assigned to the identity. The implication is that IAM teams must stop treating post-login access as a fixed entitlement state.

Continuous verification only works when authorization is evaluated at the action level. Authentication answers who or what is asking. It does not answer whether a sensitive transaction should proceed in this context, at this moment. Zero Trust becomes operational only when policy can inspect the request itself, not just the account that made it. Practitioners should treat this as an authorization design problem, not an MFA problem.

Identity has become the new perimeter because the old perimeter no longer governs cloud execution paths. When users, APIs, and services move across SaaS, remote endpoints, and distributed workloads, location-based trust loses meaning. That is why identity governance now has to span human users and machine identities under the same policy discipline. The practical conclusion is that access control must follow the action, not the network.

Policy-driven authorization creates the named concept of context-aware trust enforcement. This is the point where trust is no longer granted by role or session alone, but continuously recalculated against device, location, behavior, and resource sensitivity. That concept matters because it is the only way to align Zero Trust with day-to-day operations in modern application estates. Security teams should recognize it as a governance model, not just a tooling pattern.

From our research:

• 96% of orgs believed MFA could have prevented or minimized an identity-related breach, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why post-login access governance remains difficult to operationalise.
• For the standards view, Ultimate Guide to NHIs , Standards maps Zero Trust and authorization controls to the frameworks teams actually use.

What this signals

Context-aware trust enforcement: the practical shift in Zero Trust is moving from identity verification at the gate to continuous decisions inside the workflow. For IAM programmes, that means policy must be measured by how often it governs real access decisions, not by how widely MFA has been rolled out.

With 97% of NHIs carrying excessive privileges, the same governance pattern that weakens human access also weakens machine access when authorization stays static. Teams should expect the boundary between IAM and workload governance to keep blurring as application access becomes more dynamic.

For implementation detail, NIST SP 800-207 Zero Trust Architecture remains the clearest external reference for aligning identity, device, and request context. The reader-level signal is that policy-as-code and centralized authorization will increasingly shape auditability as much as security.

For practitioners

• Replace coarse post-login trust with action-level policy checks Require sensitive applications to evaluate each request against context such as device posture, location, and resource sensitivity before granting access. Keep the policy decision outside the application where possible so it can be reused and audited consistently.
• Use adaptive MFA as an entry control, not a complete Zero Trust model Keep conditional access for risky logins, but do not stop there. Feed those signals into downstream authorization so the same session can be restricted when the action becomes higher risk.
• Externalize policy logic across distributed systems Centralize authorization rules for microservices, SaaS apps, and legacy front ends so teams can change access behavior without rewriting every application. That reduces exception sprawl and makes reviewable policy the norm.
• Prioritise high-value assets and risky transactions first Start with systems where the cost of over-permissioning is highest, such as customer records, production actions, or privileged administration. This lets you prove the model before expanding it to lower-risk workflows.

Key takeaways

• Zero Trust fails when organisations stop at authentication and leave authorization static.
• The evidence shows that identity controls alone do not close the gap once access becomes contextual and continuous.
• Practitioners need policy-driven authorization, not just MFA and ZTNA, to make Zero Trust operational.

Key terms

• Dynamic Authorization: An access control model that evaluates each request in context rather than relying only on a preassigned role. It considers signals such as device posture, location, sensitivity, and action type, which makes it better suited to cloud-native and Zero Trust environments.
• Adaptive Authentication: A sign-in control that adjusts verification requirements based on risk signals like unusual location, device changes, or behavior anomalies. It strengthens the entry point, but it does not replace downstream authorization because it only decides how identity is proven, not what the session can do next.
• Attribute-Based Access Control: An authorization approach that grants or denies access based on attributes attached to the user, resource, environment, or action. It is more flexible than static role models because it can reflect real-time context and support finer-grained Zero Trust enforcement.

Deepen your knowledge

Dynamic authorization and policy-based Zero Trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to move from static roles to contextual access decisions, it is worth exploring.

This post draws on content published by Cerbos: the third part of its Zero Trust series on adaptive, context-aware access controls. Read the original.