Cerbos

(Explicit scenarios where alternatives may be better)

1. Very simple authorization needs

   • When an application only requires a small number of static roles and minimal audit requirements, the operational and modeling overhead of a dedicated authorization platform may not be justified.

2. Need for a single engine across many non-authorization policies

   • When an organization intends to use one policy engine for Kubernetes admission control, infra policy, and other non-authorization domains, OPA may be a better fit.

3. Relationship-based authorization at very large scale (Zanzibar)

   • For Google-Drive-like sharing models, nested groups, and very large-scale tuple checks, OpenFGA/Authzed/SpiceDB may better match the domain model.

4. Requirement for extensive third-party reviews and mature analyst coverage

   • If procurement requires abundant verified third-party reviews and broad analyst coverage, buyers should consider vendors with larger review footprints.

5. MAP-based pricing is unacceptable

   • When Monthly Active Principals as a pricing unit would create unacceptable cost exposure as non-human principals scale, consider open-source-only deployment or alternatives with different pricing models.

• Environments that only require simple role models (e.g., a handful of admin/user roles) where externalization may add unnecessary complexity.
• Organizations that require a combined authentication and authorization provider as a single product (Cerbos addresses authorization; an authentication provider/IdP is still required).
• Domains that are primarily relationship-graph oriented and where a Zanzibar-style approach (OpenFGA/Authzed) aligns better with requirements.

• Independent validation gaps: many performance and adoption claims are vendor- or team-posted; verified third-party reviews are limited in publicly accessible sources.
• Control-plane considerations: although PDPs run in-customer, buyers should evaluate Hub availability, caching behavior, and failure modes.
• Certifications vs compliance statements: Cerbos discusses support for HIPAA/PCI/GDPR/ISO controls, but only SOC 2 Type II was clearly documented publicly in the reviewed materials.

• G2: The Cerbos listing shows a limited review footprint, which reduces the platform's ability to provide a comprehensive buyer perspective.
• Capterra: A Cerbos product page exists and includes a review headline; full review content may require interactive access.
• Gartner Peer Insights: A direct, accessible listing was not identified in the sources reviewed; Cerbos may be unlisted or categorized differently.
• TrustRadius: No clear review page was located in the reviewed sources; treat as a limited footprint rather than definitive absence.

Independent review data is sparse, so churn drivers are inferred from trade-offs common to authorization platforms:

• Domains that are primarily relationship-based (Zanzibar) may prefer OpenFGA/Authzed.
• Use cases that require a general-purpose policy engine across infrastructure (admission control, infra policy) may favor OPA.
• MAP-based pricing can create cost sensitivity as non-human principals scale; buyers should model costs for their expected principal mix.

Important limitation: There is insufficient independent review volume to quantify churn drivers.

Cerbos publishes a Debite case study describing use across back office and front end. The case study indicates that the deployed authorization system required minimal ongoing operational attention after implementation.

Critical evaluation:

• Vendor-published materials provide qualitative descriptions of outcomes; metrics and long-term operational experience are not independently validated.
• Buyers should corroborate claimed outcomes through reference calls and request quantitative metrics where relevant (latency, incident reduction, engineer-hours saved).

Cerbos publishes an NTWRK case study describing how their platform supported authorization needs.

Critical evaluation:

• Vendor-published content is useful for understanding deployment patterns but should be validated with customer references for concrete metrics (latency impact, incident reduction, deployment timeline, engineer-hours saved).
• One claim in the case study contrasts authorization and authentication components; buyers should remember SAML/Cognito/Auth0 are primarily authentication/federation technologies, whereas Cerbos addresses authorization.

Cerbos is an authorization (authZ) platform that externalizes application permissions from code into centrally managed policies. It provides:

• Cerbos PDP (Policy Decision Point): an open-source, stateless decision engine that evaluates authorization requests against policies.
• PEPs (Policy Enforcement Points): SDKs/integrations used by apps/services to ask the PDP whether a request is allowed.
• Cerbos Hub (Policy Administration Plane/Point): a commercial control plane for authoring, testing, and distributing policies to PDPs, and for aggregating audit logs.

Cerbos targets fine-grained authorization use cases (RBAC/ABAC/PBAC patterns) across modern architectures: microservices, APIs, serverless/edge, and, per vendor positioning, AI agents/MCP servers.

Official description and architecture framing (PDP + Hub) are described on the vendor's product pages and public code repository.