How should security teams choose between PBAC and Zanzibar for application authorization?

How to think about the authorization problem PBAC and Zanzibar solve

PBAC and Zanzibar both answer the same core question, who can do what, but they do it with different operating assumptions. PBAC is usually the better fit when authorization needs to reflect current context and policy logic across a changing application. Zanzibar is better when the challenge is at scale, with very large resource graphs and fine-grained relationships that must be evaluated consistently.

The practical distinction is less about labels and more about permission shape. PBAC is policy-centric, so teams can express rules around user state, request context, resource attributes, and business conditions without tightly coupling every decision to a centralized relationship model. Zanzibar is relationship-centric, so it shines where access depends on many explicit relationships, such as owner, viewer, editor, member, or delegated access, and where those relationships must be queried efficiently across a large graph.

Teams should therefore start by asking whether the app is driven more by contextual policy decisions or by persistent relationship traversal. If the answer changes often, policy evaluation tends to age better. If the application has a very large number of resources and a need to resolve deeply nested sharing or membership chains, a Zanzibar-style authorization service is usually the more natural fit.

Where PBAC tends to fit better, and where Zanzibar earns its complexity

PBAC works well when authorization logic must keep pace with product changes, risk signals, and dynamic attributes. It is a strong choice for SaaS applications, internal business systems, and APIs where the decision depends on current context such as tenant, device posture, request location, subscription state, or operational mode. In those environments, policy logic is easier to evolve than a schema of explicit object relationships.

Zanzibar becomes attractive when authorization is not just about deciding against a single object, but about answering many relationship questions at scale. That includes file sharing, collaboration platforms, document trees, social graphs, and other systems where a permission may come from direct assignment, inherited membership, or nested delegation. The benefit is consistency and expressive graph-based authorization, but the trade-off is a more centralized permission system that must be designed, operated, and synchronized carefully.

One useful check is whether your team is trying to encode business logic or model a permission graph. If the hard part is policy variation, PBAC usually fits. If the hard part is relationship expansion across many entities, Zanzibar usually fits. For many applications, the right answer is not either or, but a split architecture where coarse policy gates sit in front of a relationship-based authorization core.

Risk and Threat Considerations

Authorization design failures usually show up as over-permissioning, inconsistent decisions, or brittle synchronization between the source of truth and the application. PBAC can drift if policies become too complex or if teams spread rules across too many services. Zanzibar can concentrate risk if the central authorization layer becomes a high-value dependency, especially when stale relationship data or poor schema governance can produce incorrect access decisions.

Failure mechanism: A policy model that is too flexible can become inconsistent and hard to audit, while a relationship graph that is too centralized can turn authorization into a single point of failure or a high-blast-radius dependency. In both cases, the failure is not the abstract model itself, but weak ownership, poor change control, or insufficient testing of edge-case permission paths.

Impact: Users may gain unintended access, legitimate access may break during product changes, and security teams may lose confidence in whether the authorization layer is actually enforcing least privilege. At scale, those failures become difficult to detect because authorization bugs often look like normal application behavior until data exposure or access disputes appear.

Practitioner Guidance

What to prioritise: Map the permission model before you choose the engine. If you can describe access in terms of reusable policy conditions, RBAC-style inheritance, and current context, PBAC is usually the simpler long-term choice. If you need object-level sharing across many resources and relationship queries are the dominant problem, Zanzibar-style authorization deserves serious evaluation.

What to verify: Check how the system will be tested, reviewed, and changed. PBAC should have clear policy ownership and simulation coverage for edge cases. Zanzibar should have disciplined schema design, reliable propagation of relationship changes, and a clear answer for how stale reads are handled during authorization decisions. In both cases, the team should be able to explain why a specific user got a specific decision.

Practitioner takeaway: Choose the model that matches the dominant complexity, not the one that sounds more advanced. Most teams should prefer PBAC unless the application truly needs Zanzibar’s relationship graph at scale, because operational clarity matters as much as expressive power.

Related resources from NHI Mgmt Group

• How should security teams choose between RBAC, ABAC, and PBAC for NHI access?
• How should teams choose between RBAC and ABAC for application authorization?
• How should security teams choose between IaC scanning and application security testing?
• How should security teams choose between gateway and token authorization for AI agents?