Notifications
Clear all
Topic starter
24/06/2026 9:14 pm
TL;DR: Moving from OPA to a custom policy decision engine delivered up to 17x faster authorization decisions, clearer reasoning, and lower memory and CPU overhead, according to Cerbos. The deeper lesson is that authorization platforms win when they separate policy from code without forcing teams to absorb engine complexity.
NHIMG editorial — based on content published by Cerbos: the story of moving from OPA to a custom policy decision engine
By the numbers:
- Cerbos says its specialized engine performs up to 17x faster than its previous OPA-based implementation.
Questions worth separating out
Q: How should teams decide between a general policy engine and a purpose-built authorization layer?
A: Choose the model that matches your operating burden.
Q: Why does authorization explainability matter in IAM programmes?
A: Explainability matters because access control is only governable when teams can show why a request was allowed or denied.
Q: What breaks when authorization is handled inside application code?
A: Policy logic embedded in code is harder to standardise, test, and govern across teams.
Practitioner guidance
- Map authorization decisions to a dedicated control plane Keep policy evaluation out of application code for high-risk access paths, then define service-level objectives for decision latency, audit logging, and rollback behaviour.
- Test explainability before scaling policy enforcement Validate that every allow and deny can be traced to a readable rule set, because access reviews and incident debugging depend on clear decision reasoning.
- Benchmark the runtime cost of authorization Measure p95 decision time, CPU usage, and memory footprint under realistic load so policy enforcement does not become the bottleneck that developers bypass.
What's in the full article
Cerbos's full article covers the implementation detail this post intentionally leaves for the source:
- The specific reasons the team started with OPA and where that approach began to limit product evolution
- The architecture choices behind the Cerbos Policy Decision Point and how it wraps policy evaluation
- The operational changes that came with custom decision reasoning and audit output
- The performance and resource trade-offs the team says it saw after moving away from the OPA-based implementation
👉 Read Cerbos's analysis of its move from OPA to a custom authorization engine →
Cerbos's move from OPA to a custom engine: what changes for IAM?
Explore further
25/06/2026 6:20 am
Policy engines have become an identity control plane, not a developer convenience. The article shows that authorization is no longer a thin application layer concern. Once permissions are expressed centrally, the policy engine becomes the place where governance, auditability, and runtime enforcement intersect. For IAM teams, that means authorization design now carries the same operational weight as authentication architecture and privileged access controls.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- That gap persists alongside an average of 6 distinct secrets manager instances per organisation, which fragments control and complicates governance.
A question worth separating out:
Q: How can security teams measure whether policy-based authorization is working?
A: Track decision latency, deny reason quality, audit completeness, and the percentage of access paths that still bypass the central policy layer. If developers are re-implementing checks in code or support teams cannot explain denials quickly, the authorization model is not yet operating as intended.
👉 Read our full editorial: Cerbos's policy decision engine shift and what it means for IAM
