Deel and Rippling show how weak access governance becomes a risk

At a glance

What this is: This is an analysis of the Rippling and Deel access dispute, showing how overbroad role access and weak governance can turn an insider into a high-impact risk.

Why it matters: It matters because IAM, IGA, PAM, and SaaS governance teams need controls that constrain what legitimate users can see and do before trust becomes exposure.

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%.

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

Context

Enterprise access control failures are not always technical breaches in the classic sense. Sometimes the problem is that a legitimate identity is allowed to see far more than its role should permit, which turns internal access into an integrity and confidentiality risk.

This case sits squarely in IAM and access governance, not just vendor management. The issue is whether RBAC, ABAC, exception handling, and logging actually limit what a real user can reach once they are inside the system.

The dispute is still evolving in public view, but the control lesson is familiar: when access is broader than job function, the organisation has already moved from policy to exposure.

Key questions

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. That can expose customer data, administrative functions, or internal workflows to the wrong external users. Broad roles also make access reviews less meaningful because the role itself no longer reflects a clear business need.

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. A legitimate user with broad access can leak customer records, pipeline data, or other sensitive material without triggering traditional intrusion controls. That makes least privilege and auditability core business protections, not just technical hygiene.

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. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.

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.

Technical breakdown

How RBAC fails when roles are too broad

Role-based access control assigns permissions to job functions, but the model only works when roles are tightly scoped and reviewed. If a payroll or operations role inherits broad customer visibility, the access model stops expressing business need and starts expressing convenience. In practice, role explosion, poorly maintained exceptions, and weak recertification allow legitimate users to accumulate rights that are never revisited. That creates an internal privilege surface that is hard to detect because the access looks authorised on paper.

Practical implication: map role definitions to actual job tasks and remove inherited access that cannot be justified by function.

Why ABAC and policy exceptions need stronger governance

Attribute-based access control adds context such as department, data sensitivity, geography, or purpose, but it still depends on clean policy logic and disciplined exception handling. If exceptions are created informally or left in place indefinitely, ABAC becomes another way to expand access without accountability. The technical risk is not the policy language itself. It is the gap between intended policy and real entitlement state, especially in SaaS environments where data views, exports, and delegated permissions can bypass the original design.

Practical implication: track every exception as an entitlement change and recertify it on a fixed governance cycle.

Why audit trails matter when legitimate access is abused

Audit logging should show who accessed what, when, and under which entitlement path. That is essential when the actor is inside the system and the question is not intrusion, but misuse or overreach. Without high-quality logs, teams cannot distinguish approved activity from policy violation, and investigations stall at the evidence stage. In SaaS settings, audit quality also determines whether a company can prove containment, assess blast radius, and support disciplinary or legal action.

Practical implication: verify that logs capture entitlement context, data objects accessed, and exception usage, not just login events.

Threat narrative

Attacker objective: The objective was to obtain confidential internal information and use it for competitive advantage.

1. Entry occurred through a legitimate employee identity allegedly recruited to share internal information, rather than through an external exploit.
2. Escalation came from overbroad access, which reportedly allowed the payroll manager to reach customer and pipeline data outside the job role.
3. Impact would include confidential data exposure, loss of trust, and potential competitive harm if internal information was shared outside the company.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity blast radius: The useful concept here is not simply least privilege, but identity blast radius, the amount of damage a legitimate identity can do if it acts outside expected intent. When payroll or operational roles can reach customer data, pipeline data, or other sensitive records, the blast radius has already expanded beyond acceptable bounds. That expansion usually happens through stale exceptions, role creep, and weak review processes. Teams should judge access models by the damage they would permit under misuse, not by whether the user technically authenticated.

RBAC and ABAC only work when they are operationally enforced. The article shows why policy language alone does not create governance. RBAC must be backed by precise role definitions, and ABAC must be backed by consistent policy evaluation, review, and evidence. Without those controls, access becomes a trust exercise rather than an identity control. For IAM and IGA leaders, the implication is that governance quality matters more than the label attached to the model.

Auditability is the difference between suspicion and proof. The article correctly points to logging and traceability as critical, because organisations need to know not just that access occurred, but whether it aligned with purpose and scope. If audit trails cannot reconstruct entitlement context, then the business cannot evaluate accountability, contain exposure, or support remediation. That makes logging part of the access control system, not a separate reporting layer. Practitioners should treat evidence quality as a control requirement, not an afterthought.

Third-party SaaS trust models are now part of internal access governance. Even when the incident looks like an employee issue, the real exposure sits in the SaaS control design that allowed broad visibility into customer and pipeline data. Modern IAM programmes need to connect role design, delegated access, exception handling, and monitoring across cloud applications, not just inside the corporate directory. The field is moving toward governance that measures what identities can actually do, not what their titles suggest they should do.

From our research:

• 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.
• For a broader view of the control failures behind this pattern, see Ultimate Guide to NHIs , Key Challenges and Risks and OWASP Non-Human Identity Top 10.

What this signals

Access governance is moving from a directory problem to a data exposure problem. When identity controls inside SaaS applications are weak, the question is not just who logged in, but who could browse, export, or share sensitive records once inside. That is why role design, exception review, and audit depth now matter as much as authentication.

Identity blast radius: teams should start measuring how much damage a legitimate identity can do if it is misused. A low-friction role can still be a high-impact role if it can reach customer data, pipeline data, or administrative views without enough guardrails.

The practical shift is to treat access reviews as evidence checks, not checkbox exercises, and to connect SaaS permissions back to business purpose and data sensitivity. For a wider governance baseline, practitioners should align access policy with the NIST Cybersecurity Framework 2.0 and the access control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• 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.
• Separate sensitive customer data by function Use data segmentation and view-level restrictions so operational roles cannot browse customer records or pipeline data by default.
• Reassess SaaS access against blast radius Measure how much damage a single legitimate identity could cause if misused, then reduce the reachable data set before the next review cycle.

Key takeaways

• The incident shows that broad legitimate access can be as dangerous as external compromise when roles are not tightly governed.
• The evidence points to a classic governance failure: weak role design, loose exceptions, and audit trails that cannot explain why the access existed.
• The control that would have mattered most is disciplined least privilege, backed by recertification, logging, and data segmentation.

Key terms

• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.

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.

👉 Clarity Security's full post covers the access-control failure, audit concerns, and business implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.