Notifications
Clear all
Topic starter
11/06/2026 11:13 pm
TL;DR: Authorization is the control point that decides what users can do, according to Cerbos. It then compares RBAC, ABAC, DAC, MAC, and ReBAC as different ways to express access rules and context; the core issue is not the vocabulary of access control but whether policy, context, and review can keep pace with a growing system.
NHIMG editorial — based on content published by Cerbos: Authorization design patterns and access control models
Questions worth separating out
Q: How should teams choose between RBAC and ABAC for application authorization?
A: Use RBAC when access maps cleanly to business roles and the number of exceptions is low.
Q: What breaks when authorization is hard-coded into application logic?
A: Hard-coded authorization becomes difficult to audit, test, and change consistently across services.
Q: How do security teams know if authorization is actually working?
A: Look for decisions that are explainable, repeatable, and reviewable.
Practitioner guidance
- Define the authorization model before implementation Map which decisions belong to RBAC, ABAC, DAC, MAC, or ReBAC before writing code so teams do not mix control styles without governance ownership.
- Centralise policy decisions where possible Move access logic into a decision layer that can be tested, reviewed, and changed independently of application code, especially across multiple services.
- Review exceptions as part of access governance Track temporary grants, owner overrides, and role exceptions as first-class access events so exceptions do not become permanent privilege drift.
What's in the full article
Cerbos' full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step explanations of each authorization model and where it fits in application design
- Concrete examples of RBAC, ABAC, DAC, MAC, and ReBAC in everyday software scenarios
- The article's own discussion of scalability, performance, and maintenance trade-offs in custom authorization
- Developer-oriented framing that shows how policy, context, and decision logic interact in practice
👉 Read Cerbos' guide to authorization design patterns and access control models →
Authorization patterns: where access control still breaks down?
Explore further
12/06/2026 7:48 am
Authorization design fails when teams treat policy as an application detail rather than an identity control plane. The article shows that rules, context, and decision engines are the real enforcement boundary, not the surrounding UI or login flow. That makes authorization a governance issue as much as an engineering one, especially when access must be reviewed across users, service accounts, and delegated systems. Practitioners should treat policy ownership and decision traceability as core control requirements.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot consistently verify who or what still has access.
A question worth separating out:
Q: What is the difference between centralized authorization and owner-controlled access?
A: Centralized authorization applies consistent policy across the environment, while owner-controlled access lets resource owners grant and revoke permissions directly. Centralization improves consistency and auditability. Owner control increases flexibility but can create tracking problems and uneven enforcement when the system grows.
👉 Read our full editorial: Authorization design patterns define the real boundary of secure apps
