Notifications
Clear all
Topic starter
12/06/2026 10:03 pm
TL;DR: Resource-based authorization shifts access decisions from broad roles to the specific object in context, improving least privilege, auditability, and multi-tenant isolation, according to Cerbos. The real lesson is that mature IAM programmes need layered policy logic, not role sprawl.
NHIMG editorial — based on content published by Cerbos: Resource-based authorization and the limits of role-only access
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should teams implement resource-based authorization in a microservices environment?
A: Start by deciding which service owns each resource and which attributes determine access, such as owner, tenant, or state.
Q: Why does resource-based authorization reduce over-provisioning compared with RBAC?
A: Because it lets you grant access only to the specific object and action instead of giving a broad role far more reach than the user needs.
Q: What do security teams get wrong about multi-tenant authorization?
A: They often rely on application logic or UI boundaries instead of making tenant separation an explicit policy condition.
Practitioner guidance
- Map sensitive actions to resource context Define which operations must be evaluated against ownership, tenant, sensitivity, or state before the action can proceed.
- Centralise decision logic for distributed services Route access checks through a shared policy engine or service so microservices evaluate the same rules against the same resource attributes.
- Build tenant boundaries into policy, not just data models Require tenant identifiers and ownership attributes in authorization decisions for every shared-resource workflow.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Implementation examples for tying policy checks to specific resource types and request flows
- Practical comparisons of RBAC, ABAC, and resource-based policy design choices
- Integration patterns for policy evaluation in microservices and distributed application stacks
- Decision logging and policy review considerations for regulated environments
👉 Read Cerbos' guide to resource-based authorization and policy design →
Resource-based authorization: what it means for IAM teams?
Explore further
13/06/2026 12:34 am
Resource-based authorization is the point where role design stops being sufficient and identity governance becomes object governance. RBAC can tell you who belongs to a class of users, but it cannot by itself express whether a given document, order, or patient record should be accessible in this moment. That is why resource-level policy becomes essential once applications hold mixed tenant, ownership, or sensitivity states. Practitioners should treat object context as a first-class control surface, not as a late-stage exception.
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.
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%.
A question worth separating out:
Q: Who should own resource-level authorization decisions in an engineering organisation?
A: Product teams can define business intent, but platform or security engineering should own the policy model, testing, and review process. That division keeps access logic consistent, makes audits easier, and prevents every service team from inventing its own version of the same rule.
👉 Read our full editorial: Resource-based authorization and the limits of role-only access
