Cerbos vs EmpowerID

If you are comparing Cerbos with EmpowerID, you could be running EmpowerID for identity governance already. It handles joiners, movers and leavers, access certification, and often SAP.

The question is whether the fine-grained decisions inside your applications, APIs and AI agents should live in the same platform. Those are the decisions about which record a person can open, which payment they can approve and which tool an agent can call.

Since Omada acquired EmpowerID in September 2026, the answer also depends on how Omada brings the two product lines together.

Both products can make a runtime authorization decision. They differ in what they were built around. EmpowerID is an identity governance platform with authorization as one of its pillars. Cerbos is an authorization management platform that reads the roles and attributes your identity governance already manages.

So this comparison is less about replacing EmpowerID and more about where authorization should sit, who writes and tests the rules, and how far one set of rules reaches.

Cerbos vs EmpowerID at a glance

Question	Cerbos	EmpowerID
What it is	An authorization management platform. Decision points run next to every workload, Cerbos Hub manages policy, testing and audit, and Cerbos Synapse brings in context and connects gateways, data platforms and AI agents.	An identity governance platform, now sold as EmpowerID by Omada, covering identity lifecycle, access certification, privileged access and authorization on one Identity Fabric.
How access is decided	Per request, against the attributes of the person, the resource and the request at that moment.	A hybrid model. EmpowerID's documentation says it precalculates which users have which permissions, and ABAC policies add conditions known only at access time.
How policy is written	Short YAML policies with conditions in CEL, kept in Git or in Cerbos Hub policy stores.	Roles, access levels and PBAC policies managed in the platform. Its newer decision point documents YAML policy files with five inheritance levels and its own condition syntax.
How a change is tested	Test suites live next to the policies, and Cerbos Hub only builds a deployment when they pass.	EmpowerID says its app authorization contracts are projected into policy, grants and tests. Its developer documentation (October 2026) lists a lint script, a pre-commit hook and a manual testing checklist. We found no documented test runner that blocks a release.
Coverage	One set of policies across applications, API gateways and service meshes (Kong, Apigee, Envoy and Istio), data platforms and event streams, Kubernetes, MCP servers and AI agents.	Applications through its APIs, plus its own MCP and LLM gateways, which EmpowerID's site labels Early Access (October 2026). It lists gateways among its enforcement points without naming an API gateway, service mesh, Kafka, Kubernetes or data platform integration.
Audit evidence	Every decision is logged with its inputs and outcome and linked to the policy version that made it, collected by Cerbos Hub from every decision point.	EmpowerID's site describes signed receipts for governed actions. Its Trust page marks most of those proof claims as partially evidenced or not yet evidenced (October 2026).
Standards	Cerbos PDP and Cerbos Synapse both implement the AuthZEN Authorization API. Alex Olivier, Cerbos cofounder and CPO, co-chairs the OpenID AuthZEN Working Group.	Appears in the AuthZEN interoperability results, including the search scenarios.
Pricing	Public, by monthly active principals. $0 proof of concept, Development from $25 a month, Production from $933 a month, Enterprise custom.	Not published. Licensed by governed identity class and product scope, according to EmpowerID's FAQ (October 2026).
Company	Founded 2021, London.	Founded 2005, Dublin, Ohio. Acquired by Omada, announced 24 September 2026.

Keeping identity governance in EmpowerID while authorization moves to Cerbos

Identity governance and runtime authorization answer different questions. Governance answers who holds which role, who approved it and whether it should still be there. Runtime authorization answers whether this person, service or agent can take this action on this record right now. The identity teams we talk to usually keep the first in the governance platform they already trust and look for a separate answer to the second. The joiner, mover and leaver process assigns roles. Whether a role change reaches the checks buried in each application is a different matter.

EmpowerID is built around identity governance. Its documentation describes an Identity Warehouse on Microsoft SQL Server that inventories identities and entitlements from every connected system, and a connector estate that reaches SAP, Active Directory, Workday and ServiceNow. That breadth is what makes it a governance platform, and none of it needs to move.

Cerbos sits downstream of it. Your application reads the roles, groups and organizational scope from the tokens EmpowerID issues and passes them to Cerbos with each request, as our EmpowerID integration describes. Where a decision needs something the token does not carry, Cerbos Synapse fetches it at decision time, from EmpowerID itself or from the system that owns it. So EmpowerID keeps governing who holds a role, and Cerbos evaluates what that role can do in every application, gateway and agent, with a record of each decision.

That split also takes your authorization layer off one vendor's integration schedule. KuppingerCole expects the Omada and EmpowerID integration to take 12 to 18 months, and advises EmpowerID customers to confirm support commitments and how their customizations carry forward. Your authorization rules do not have to wait on that answer.

Precalculated access and per-request decisions in EmpowerID and Cerbos

EmpowerID's documentation says it precalculates which users have which permissions, and evaluates ABAC conditions that are only known at access time on top of that. Precalculated access is built for governance. It lets a reviewer see who can do what before anyone asks, which is what certification campaigns need.

That is ultimately runtime authorization, with precalculated grants as the starting point and conditions checked when the request arrives. Cerbos has no precalculated layer. It evaluates every request against the principal, the resource and the request as they are at that moment, the record’s current state, the amount on this payment, the customer’s region and which agent is acting for which person.

When the question is "which records can this person see", Cerbos returns the answer as a filter through query plans, which your database applies. Documented adapters cover Prisma, Drizzle, Mongoose, Convex, SQLAlchemy and LangChain with ChromaDB. For an estate-wide certification report, keep it in EmpowerID, where the governance data already lives.

Where authorization policy lives in Cerbos and EmpowerID, and who can test it

Once authorization governs hundreds of applications, the rules belong to security, identity and engineering at once, and an auditor will ask to see the rule that was in force on a given day. The policy has to be something each of them can read, and a change has to be tested before it reaches production.

EmpowerID models access through platform objects. Management roles scope administration to locations, access levels bundle operations, and each PBAC policy grants a single right or role to an assignee, with conditions on its Field Types, the attributes it keeps for each identity. Its newer decision point, documented under the earlier EmpowerNow name, stores policies as YAML files with five inheritance levels, from application up to global, and its own condition syntax. EmpowerID says its app authorization contracts are projected into policy, grants and tests, and that documentation lists a lint script, a pre-commit hook example and a manual testing checklist (October 2026). We found no documented test runner or promotion pipeline that stops a failing change from shipping.

In Cerbos, a policy is a short YAML file with conditions in CEL, an open expression language Kubernetes and Envoy also use. Here a regional manager approves purchase orders in their own region, up to their limit.

apiVersion: api.cerbos.dev/v1
resourcePolicy:
 version: default
 resource: purchase_order
 rules:
   - actions: ["approve"]
     effect: EFFECT_ALLOW
     roles: ["regional_manager"]
     condition:
       match:
         all:
           of:
             - expr: P.attr.region == R.attr.region
             - expr: R.attr.amount <= P.attr.approval_limit

A test suite sits next to the policy and lists the decision you expect for each person and action. Cerbos Hub runs the suites before it builds each deployment and only builds when they pass, keeps the history of which build every decision point ran, and rolls back in one step. Policies live in Git or in Cerbos Hub policy stores, so every change has an author, a reviewer and a timestamp. Where EmpowerID uses five inheritance levels, Cerbos uses scoped policies, where a business unit or tenant can narrow what the organization allows and can be prevented from widening it.

People who do not write YAML every day work in the Cerbos Hub playground, where a permissions matrix shows who can do what before a change is proposed.

Authorization across applications, gateways, data platforms and AI agents

The same rule has to hold wherever the data can be reached, through the application, the API in front of it, the analytics platform behind it and the agent working on someone's behalf. Rules that live in one place and not the others leave gaps nobody sees until an audit.

EmpowerID covers applications through its APIs and its own gateways for agents. Its Governed Authorization page lists gateways and search among its enforcement points, and we found no named integration with an API gateway, service mesh, Kafka, Kubernetes or a data platform such as Snowflake, Databricks or Trino (October 2026).

Cerbos covers each of these from one set of policies and one audit log.

• Applications call Cerbos through an SDK in eight languages, one call in place of permission checks scattered through the code.
• API gateways and service meshes such as Kong and Apigee can call out to Cerbos PDP from their request filters, whilst Cerbos Synapse has native endpoints to be an external authorization service for Envoy and Istio.
• Data platforms and event streams get Cerbos answering Trino's authorization calls, so a query returns only the rows and columns a person may see, and Kafka's, so only approved services read or write a topic.
• Kubernetes admission requests follow the same policy language.
• Applications you cannot change are governed at the gateway in front of them, with no code changes.

AI agent authorization in Cerbos and EmpowerID

Agents follow access, not instructions. An agent can do anything its credentials allow, regardless of the prompt. So the control has to sit at the action, with the person behind the agent checked in the same decision.

EmpowerID's MCP Gateway is designed to pin approved tool schemas, check delegation on every governed call and keep OAuth tokens at the gateway so the agent never holds them. EmpowerID's site labels Agent Governance and Execution, the MCP Gateway and the LLM Gateway as Early Access, and says availability "varies by edition, deployment, and release" (October 2026).

Cerbos checks every agent tool call against policy before it runs, down to the arguments the agent passes, wherever you enforce it.

• In the agent harness, through hooks, as with Claude Code, where the settings roll out through device management so nobody switches them off locally.
• At an MCP gateway or proxy, or in the MCP server itself.
• At an AI gateway such as LiteLLM or agentgateway, where the same policies cover tool calls and which models an agent may use, as we describe in governing AI agents at the gateway.

The agent's token and the person's token can travel in the same request, so a policy condition can require both, across several hops of delegation. Cerbos evaluates the request and does not hold credentials, which stay in your secrets manager or gateway. You can start before writing any policy, with audit logging on, and every call passes through and is logged with the person, the tool and its arguments. Write the policy from that record, then narrow access, read-only on financial systems or a cap on payment amounts, and each change applies on the next call. We call this the dimmer switch, turning an agent's access down or up while the work keeps running. A security team can approve an agent rollout with controls it can show an auditor, rather than blocking it.

Audit logs and compliance evidence in Cerbos and EmpowerID

What a security team needs is a fast answer to "show me the policy that was in effect at the time", for any decision, months later.

Cerbos logs every decision with the request inputs and the outcome, linked to the policy version that made it. Cerbos Hub collects those logs from every decision point into one searchable trail, filtered by person, resource, action or outcome, and you can export them into your own archive or SIEM. The execution trace shows every rule and condition a decision went through. Hub keeps logs for three months on Development, a year on Production and as long as you need on Enterprise. With the Git history of every policy change alongside, the evidence for an access question is a search.

EmpowerID's site describes a signed receipt for every governed action. Its Trust page marks most of those proof claims as partially evidenced or not yet evidenced, with coverage that "varies by path and connector" (October 2026). Ask any vendor which decisions its evidence covers today, on which paths, and how an auditor reads it.

Cerbos holds a SOC 2 Type II attestation. The decision and policy change records are what give your own SOC 2, ISO 27001, HIPAA, PCI DSS or DORA audits their evidence.

Where Cerbos and EmpowerID run decisions

EmpowerID describes its Governed Authorization as distributed decision points with identical semantics, offered as SaaS or a dedicated single tenant deployment, on-premise or in a private, public or sovereign cloud. Its documentation does not say what a decision point does when it loses contact with the central platform. Ask about that, and about what each decision point needs in your cluster.

Cerbos decision points run wherever the workload does, as a shared service, a sidecar, a DaemonSet, a serverless function or in the browser through WebAssembly. They are stateless, so they scale by adding instances. Cerbos Hub sends policy to them encrypted with each deployment's own credentials. If Hub is unreachable, running decision points keep serving the last policy they received, and new ones start from the last built copy. Cerbos Hub runs hosted, or on-premise and air-gapped for enterprise customers.

Standards, portability and lock-in with Cerbos and EmpowerID

Both vendors back AuthZEN, the OpenID Foundation's Authorization API for how enforcement points ask for decisions. EmpowerID appears in the published interoperability results, including the search scenarios. The OpenID Foundation’s AuthZEN certification is not live yet, so those results are the evidence to ask any vendor for. Cerbos PDP and Cerbos Synapse both implement the AuthZEN API. Alex Olivier, our cofounder and CPO, co-chairs the AuthZEN Working Group, so read our view on it with that in mind. A standard request format means your enforcement points do not have to change if your decision service does, which is the practical way to keep this choice reversible.

If you ever change decision service, the policies are what you carry across. Cerbos policies are readable YAML with CEL and their own test suites, and the decision engine at the core of the platform, Cerbos PDP, is open source under Apache 2.0. EmpowerID's policies live in its platform objects or its own YAML dialect, and its platform is closed source.

Cerbos and EmpowerID pricing

Cerbos publishes its pricing, based on monthly active principals, the people and services that get an authorization decision in a month.

• Proof of concept. $0, with a week of unified audit logs.
• Development. From $25 a month, with three months of audit logs.
• Production. From $933 a month, with unlimited workspaces, decision points and tenants, and a year of audit logs.
• Enterprise. Custom, adding SSO, self-hosted Cerbos Hub, custom audit log retention and phone support.

EmpowerID does not publish pricing. Its FAQ says it licenses by governed identity class and product scope, based on governed person populations, with perpetual on-premise licenses as well as subscriptions (October 2026). Ask how authorization is priced if you take it without the governance modules, or the reverse.

Cerbos at enterprise scale

The Cerbos platform runs more than 2 billion authorization checks a month. Utility Warehouse uses it to govern access across 4,500 services and millions of non-human identities. Analysts cover it too, in our posts on Gartner's AuthZEN research and on KuppingerCole's policy based access management and generative AI defense reports, and more.

When EmpowerID may still fit

If the program you are buying is identity governance itself, provisioning, certification, separation of duties, privileged access or SAP identity management, that is EmpowerID's ground, and Cerbos does not replace it. Keep it there, and move the runtime decisions in your applications, gateways and agents to Cerbos, which the migration guide walks through.

Moving authorization from EmpowerID to Cerbos

The move covers authorization only. EmpowerID keeps governing identities and roles, and your applications keep reading its tokens. Teams write each rule from its intent, with a test that proves it, then run Cerbos beside EmpowerID on the same requests until every decision matches. Most of the work is listing the attributes and roles each decision uses today and deciding whether the token, the application or Cerbos Synapse supplies each one.

The migration guide maps EmpowerID's roles, access levels, PBAC policies and inheritance levels to Cerbos and translates a policy with passing tests.

Choosing between Cerbos and EmpowerID

For an organization that wants fine-grained authorization across applications, gateways, data platforms and AI agents, without tying it to an identity governance suite, Cerbos is the stronger choice. Each decision is made per request against current data. The policy is readable and tested before it ships. One set of rules covers the API, the data platform and the agent. And the price is published.

As Je Sum Yip, Chief Engineer at Human Managed, put it, "Having to modify authorization is a five-minute job now."

Try Cerbos with your own policies. Your identity team keeps governing roles in EmpowerID and can see what each role is allowed to do, in one place. Your engineers replace the permission checks in every service with one call. Your security team can pull the policy behind any decision when an auditor asks. To plan the move from EmpowerID, book a call with our team and leave with a migration plan your security and audit teams can review.

---

Go deeper:

• Securing AI agents and non-human identities in enterprises (eBook), for governing what agents can do at the action
• EmpowerID alternatives
• Migrating authorization from EmpowerID to Cerbos
• How Cerbos works