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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “From OPA to our own engine - the Cerbos journey”.
Key questions
Q: How should teams separate authorization from application code in business apps?
A: Teams should move access rules into a centralized policy layer and keep the application focused on business logic.
Q: Why do custom policy engines matter for authorization governance?
A: They matter because authorization is not only about correctness, but about how quickly teams can change policy, explain decisions, and keep enforcement consistent.
A: A tightly coupled model usually shows up when small policy changes require code changes, deployments, or manual edits across multiple services.
Practitioner guidance
- Define the authorization control plane Separate policy evaluation from application logic so access rules can be governed independently of feature code and released without application rewrites.
- Test for decision explainability Require that denied requests return enough policy context for developers and auditors to understand the decision path, not just the final outcome.
- Measure latency on the request path Benchmark authorization decision time under realistic load, because access checks sit in front of every protected operation and directly affect user experience.
Bottom line: Authorization architecture becomes a governance question when policy is separated from application code but still has to remain explainable and fast.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 6:20 am
Authorization is becoming a governance layer, not just an application feature. Once policy logic moves out of code, the control point becomes reusable across services, but also more visible as a shared dependency. That changes how IAM teams should think about ownership, testing, and change control. The practical conclusion is that authorization architecture deserves the same governance discipline as identity lifecycle and privileged access.
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.
A question worth separating out:
Q: Should IAM teams prioritise policy portability or engine specialisation?
A: Prioritise portability when many services need the same access rules, and specialisation when a single use case demands very low latency or custom decision output. The right answer depends on whether governance consistency or execution optimisation is the bigger operational constraint.
👉 Read our full editorial: Cerbos's policy decision engine shift and what it means for IAM