What breaks when RBAC is used for per-resource sharing?

RBAC starts to fail when different resources need different permissions for the same role holder. Teams respond by splitting roles endlessly or adding conditionals in application code, which makes authorization harder to audit, test, and reason about. ReBAC avoids that by tying access to the specific relationship between a user and a resource.

RBAC works best when a role maps to a stable bundle of permissions. Per-resource sharing changes that assumption because the same role holder may need different access on each object. At that point, RBAC becomes a poor fit for fine-grained authorization, especially when the resource itself, not the role, determines who should see or edit it.

Once you need to express exceptions like one document, one folder, one record, or one tenant object, role design starts to carry information it was never meant to hold. The result is usually role sprawl, special-case logic, and a growing gap between the access model on paper and the access decisions the system actually makes.

That is why teams often move from static role assignment toward relationship-based authorisation or other fine-grained models when sharing must follow the specific user-resource relationship rather than a broad job function.

What the Authorization Model Has to Express Instead

For per-resource sharing, the important question is not just “what role does this person have?” but “what is the relationship between this person and this resource?” That is a materially different authorisation problem. RBAC can describe coarse entitlements, but it struggles when access depends on ownership, membership, delegation, collaboration, or object-specific grants.

This is where more flexible models become useful. A role can still exist, but it should not be the only driver of access. Teams need a way to represent object-level permissions, inheritance boundaries, and exceptions without encoding every exception as a new role.

In mature environments, that usually means combining roles with policy or relationship checks, so the access rule stays tied to the resource instead of being multiplied across ad hoc role variants. IAM and IGA Basics is useful context here because role design, entitlement review, and access governance all become harder once you move beyond coarse group access.

A second useful perspective is the difference between broad entitlement models and object-specific controls. Role Mining and Role Design Guide helps explain why role creation alone is not a clean answer when access decisions vary by resource and quickly turn into role explosion.

Why This Becomes Hard to Operate and Audit

RBAC failure in per-resource sharing is not just an expressiveness problem. It becomes an operational one because every new exception increases the cost of testing, reviews, and change control. When many “almost the same” roles exist, it becomes difficult to tell whether a user has access because of a deliberate business rule or because a previous exception was never cleaned up.

Auditing also gets weaker. Reviewers have to reconstruct intent from role names and conditional code instead of seeing a direct statement like “user A can access resource B because of relationship C.” That makes access recertification slower and less reliable, especially in systems where resources are frequently created, transferred, shared, or retired.

Where the environment contains many shared or short-lived resources, lifecycle discipline matters as much as the authorization model. NHI Lifecycle Management Guide is relevant because the same lifecycle pressures that affect identities also affect permissions, ownership changes, rotation, and cleanup of stale access paths.

Top 10 NHI Issues also reinforces a broader operational lesson: when access scales beyond a simple static role model, visibility, ownership, and excessive permissions become persistent failure modes, not edge cases.

Risk and Threat Considerations

When RBAC is stretched to cover per-resource sharing, the biggest risk is not only overpermission, but also invisible overpermission. Teams often compensate by creating special roles, custom conditionals, or manual exceptions, and those exceptions are easy to forget, misapply, or leave in place after the original sharing need has passed.

Failure mechanism: A coarse role model is forced to represent object-specific access, so administrators encode exceptions in extra roles or application logic, which increases the chance of unintended access, stale access, and hard-to-review policy drift.

Impact: Authorization becomes harder to reason about and much easier to misconfigure. The practical result is weaker access assurance, slower reviews, and a larger blast radius when a role or conditional rule is wrong.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Per-resource sharing needs narrowly scoped access decisions and avoids blanket role rights.
	AC-3 — Access Enforcement	RBAC failures appear when object-level authorisation must be enforced consistently at runtime.
	IA-5 — Authenticator Management	Sharing models often depend on credential and session controls that should not be conflated with roles.
Recommendation — Limit access to the specific resource and action needed for each sharing case. Enforce object-specific authorisation decisions at the point of access. Keep credential lifecycle and role assignment separate from resource-sharing logic.
OWASP ASVS	V8 — Authorization	Per-resource access control is an authorization design problem, not just a role-mapping problem.
	V15 — Secure Coding and Architecture	Teams often push sharing exceptions into application code when RBAC stops scaling.
Recommendation — Verify that access checks are resource-specific, consistent, and resistant to bypass. Externalize fine-grained access logic so exceptions are testable and auditable.

Practitioner Guidance

What to prioritise: Separate “who the user is” from “what this user may do on this specific resource.” If the answer depends on the object itself, a pure role assignment model is already too blunt.

What to verify: Check whether access decisions are still explainable as a direct user-resource relationship after inheritance, delegation, and sharing exceptions are applied. If reviewers need to interpret code or role naming conventions to understand access, the model is too implicit.

Common mistake: Adding more roles to preserve RBAC purity. That usually postpones the design problem while making governance more expensive.

Practitioner takeaway: Per-resource sharing is a signal that authorization should move closer to the resource, not that RBAC should be stretched until it fractures.