Notifications
Clear all
Topic starter
11/06/2026 11:03 pm
TL;DR: Application-specific authorization is presented as a shift from general-purpose policy evaluation to clearer policy locality, schema validation, derived roles, and structured outputs to reduce brittle rules and simplify migration, according to Cerbos. The governance lesson is that app authorization breaks down when policy logic is too general, too distributed, or too hard for teams to test consistently.
NHIMG editorial — based on content published by Cerbos: migrating application authorization from OPA and Rego to Cerbos
Questions worth separating out
Q: How should teams migrate application authorization from OPA without breaking access decisions?
A: Use shadow mode first.
Q: Why do resource-centric authorization policies improve governance?
A: Resource-centric policies make access rules easier to find, review, and audit because the logic for one protected object lives in one place.
Q: What breaks when authorization rules depend on inconsistent input data?
A: Rules become unreliable because the engine may evaluate missing, malformed, or differently named attributes in different ways across applications.
Practitioner guidance
- Standardise authorization around resources Group rules by protected resource, then define the small set of actions and conditions that apply to each one.
- Introduce schema validation for policy inputs Define principal and resource schemas before migration so inconsistent attributes are caught before evaluation.
- Run parallel decision testing before cutover Execute OPA and the new authorization engine side by side, log allow and deny outcomes, and reconcile mismatches before enforcing the new path.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Rego-to-Cerbos translation patterns for role-based, attribute-based, and contextual access rules.
- SDK-level integration examples showing how the decision call is constructed in an application.
- A phased migration sequence with shadow mode, audit mode, feature flags, and progressive cutover.
- Practical handling of complex Rego logic, inconsistent inputs, and embedded business rules that must be refactored.
👉 Read Cerbos' guide to migrating application authorization from OPA to Cerbos →
OPA to Cerbos migration: what changes for application access control?
Explore further
12/06/2026 7:33 am
Application authorization is an identity governance problem, not just a policy-engine choice. When authorization logic is scattered across services, teams lose the ability to review, test, and certify access decisions consistently. That makes policy ownership, not syntax, the central control issue. Practitioners should treat authorization as part of the access governance lifecycle, with clear accountability for who defines, validates, and changes rules.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who should own application authorization policy changes?
A: The teams responsible for the application and its access model should own policy changes, with security providing governance and review. If policy logic is embedded everywhere, ownership becomes ambiguous and changes are harder to certify. Clear ownership is part of access control assurance, not just good engineering practice.
👉 Read our full editorial: OPA to Cerbos migration sharpens application authorization governance
