Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Deel and Rippling access governance: what IAM teams should notice


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15984
Topic starter  

TL;DR: Rippling’s allegations against Deel highlight how a payroll manager reportedly accessed customer and pipeline data far beyond role scope, underscoring that weak RBAC, poor ABAC enforcement, and thin auditability can turn routine SaaS access into a governance failure, according to Clarity Security. Least privilege is only effective when roles, exceptions, and logging are actually enforced.

NHIMG editorial — based on content published by Clarity Security: Rippling and Deel access governance analysis

By the numbers:

  • Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.

Questions worth separating out

Q: What breaks when RBAC is too broad in multi-tenant B2B systems?

A: When RBAC is too broad, partner users can move beyond the tenant, application, or task they were meant to reach.

Q: Why do over-permissioned identities increase business risk even without malware?

A: Because the harm comes from what the identity can reach, not from how it authenticates.

Q: How can teams tell whether access governance is actually working?

A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems.

Practitioner guidance

  • Tighten role-to-task mapping Review whether each SaaS role corresponds to a real job function and remove inherited permissions that are not required for daily work.
  • Track and recertify exceptions Put every RBAC or ABAC exception into a formal review queue so temporary access does not become permanent entitlement creep.
  • Expand audit logging context Require logs to capture the entitlement path, data object accessed, and exception state so investigations can prove scope, not just presence.

What's in the full article

Clarity Security's full analysis covers the operational detail this post intentionally leaves for the source:

  • Role-by-role access interpretation for the Deel and Rippling dispute, including how the payroll function maps to expected permission scope.
  • Practical examples of RBAC and ABAC enforcement gaps that can let legitimate users reach customer or pipeline data.
  • The article's own recommendations for logging, access review, and exception handling in SaaS environments.
  • The broader business and reputational implications of weak access governance for customer trust and internal accountability.

👉 Read Clarity Security's analysis of the Deel and Rippling access dispute →

Deel and Rippling access governance: what IAM teams should notice?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 15569
 

Broad role access is a governance failure, not a people problem. The central issue in this case is that a legitimate identity allegedly had access well beyond its business need. That is a failure of entitlement design, role maintenance, and exception governance. In IAM terms, the organisation permitted a normal user path to become a high-risk data path, which means the control plane failed before any misuse occurred. The practitioner lesson is to treat excess access as a structural defect, not an isolated insider event.

A few things that frame the scale:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having 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, which shows how uneven identity confidence remains.

A question worth separating out:

Q: Who is accountable when a non-human actor abuses delegated SaaS access?

A: Accountability should sit with the business owner of the integration, the platform team that approved the grant, and the security function that monitors its use. If no one owns the delegation lifecycle, then the organisation has created access that can persist without meaningful oversight.

👉 Read our full editorial: Deel and Rippling show how weak access governance becomes a risk



   
ReplyQuote
Share: