Who is accountable when risky SaaS access settings cause exposure?

Why This Matters for Security Teams

Risky SaaS access settings are rarely a single-tenant mistake. They usually emerge when an app owner approves a broad integration, identity policy is inherited from a template, and monitoring assumes the setting will be reviewed later. That creates shared accountability, but shared accountability without named ownership becomes no accountability at all. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group research on Ultimate Guide to NHIs both point to the same problem: exposure often persists because the sponsor, policy owner, and detector are not clearly named.

The risk is not limited to one misconfigured permission. SaaS connectors, delegated admin roles, and third-party app grants can expose mailboxes, files, CRM records, or ticketing systems long before a review cycle catches up. That is why accountability must map to the business owner for the application, the identity team for the access model, and security for detection and escalation. In practice, many security teams encounter the failure only after an OAuth grant, admin setting, or sharing rule has already widened access.

How It Works in Practice

The operational answer is to treat SaaS exposure as an ownership chain, not a single control failure. The business or platform owner accepts the risk of the application and its data scope. The identity team defines the access policy, reviews group membership, and decides whether the integration should use least privilege or broader delegated rights. Security monitors for anomalous grants, risky token scopes, and changes to sharing or admin settings, then escalates when those settings drift.

That model works best when the organisation has a clear register of app sponsors, service owners, and integration approvers. It should also include evidence of who can change the setting, who reviews it, and who can revoke it. In NHI Management Group’s 52 NHI Breaches Analysis, the recurring pattern is that exposure is not caused by one missing control but by a chain of weak ownership and delayed remediation. Industry guidance from the NIST Cybersecurity Framework 2.0 reinforces this: governance, access control, monitoring, and response all need explicit accountability.

• Assign a named sponsor for every SaaS integration and document the data it can reach.
• Separate approval for initial access from approval for expanded scopes or admin rights.
• Track delegated grants, OAuth consents, and sharing settings as inventory items, not one-time approvals.
• Set review and revocation triggers for stale, unused, or overbroad access.

This breaks down most often in federated SaaS environments where the provider, tenant admin, and app owner all believe another party owns the setting because the technical control spans multiple consoles.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, so organisations have to balance speed of SaaS adoption against review discipline. That tradeoff is real, especially when business teams want to connect tools quickly and identity teams are expected to approve every exception. Best practice is evolving, but current guidance suggests that the answer is not to centralise every decision; it is to define where ownership starts and where escalation must occur.

Edge cases usually appear when a SaaS app is user-managed, when a third-party vendor administers the connection, or when a connector is reused across multiple business units. In those environments, the sponsor of the connection must be explicit, because “everyone can approve it” is the same as no one owning it. The same pattern shows up in shared workspaces and embedded apps, where a default permissive setting can expose content outside the intended boundary. NHI Management Group research on the Guide to the Secret Sprawl Challenge highlights why adjacent credential and configuration sprawl makes these exposures persist.

Security leaders should also distinguish between accountability for the misconfiguration and accountability for the resulting exposure. The owner of the app is accountable for accepting the risk, identity is accountable for the policy model, and security is accountable for detection and response. That division is clear in theory and often blurred in procurement-led SaaS rollouts.

Related resources from NHI Mgmt Group

• Who is accountable when offboarding leaves SaaS access active?
• Who is accountable when former employees still have SaaS access after offboarding?
• Who is accountable when a former user still has SaaS access?
• Who is accountable when SaaS access persists after a tool is no longer needed?