Accountability should sit with IT and security together, because shared SaaS accounts are both an access management issue and a governance issue. IT usually owns discovery, provisioning, and remediation workflows, while security owns risk prioritisation and control requirements. Department leaders also need visibility, since they often know which tools are shared and why the workaround exists.
Who owns the job of finding shared SaaS accounts?
Finding shared SaaS accounts is less a single-team task than an operating model problem. IT is usually best placed to discover accounts, map them to users and applications, and drive remediation workflows. Security should define the control requirements, prioritise the riskiest cases, and make sure shared access is treated as a governance issue, not a convenience workaround.
That division matters because shared SaaS accounts often sit outside the normal joiner, mover, leaver process. They can survive when teams change tools, when departments adopt shadow IT, or when a vendor integration is built quickly and never cleaned up. If no one owns discovery, the organisation ends up with accounts that are known locally but invisible centrally.
Good ownership also needs department leaders in the loop. They are often the only people who know why a shared account exists, which team relies on it, and whether there is a real business need or just an old workaround. Without that context, remediation can break operations or leave the underlying access problem untouched.
What actually changes when IT and security share accountability?
The practical difference is that discovery and decision-making split cleanly. IT can inventory SaaS tenants, identify shared logins, trace authentication paths, and coordinate resets, account splits, or retirements. Security can decide which shared accounts are unacceptable, which ones need immediate containment, and which cases need compensating controls while the team plans a safer replacement. A useful way to think about this is as lifecycle control, not just cleanup, and the lifecycle is often where visibility and offboarding gaps show up first.
Shared SaaS accounts also create a traceability problem. When multiple people use one login, you lose reliable attribution, which makes investigations, access reviews, and incident response harder. The same account can also accumulate excessive privileges over time, especially if the shortcut was created to speed up access during a project and never revisited. That is why the issue belongs in both access management and governance discussions, not just in help desk queues. The distinction is visible in cases such as Dropbox Sign breach and Sisense breach, where compromised shared or backend access paths helped expose more than one downstream system.
If you need a simple rule, use this: IT owns finding and retiring the account, security owns the control decision, and the business owner owns the justification for keeping any exception. That keeps the organisation from treating a shared account as a technical oddity when it is actually a risk acceptance decision.
How to keep the cleanup from becoming a one-time purge
The most effective programs make shared account discovery continuous. Start with SaaS inventory, usage logs, identity provider data, and exception registers, then compare them against teams that still use generic or shared credentials. Once you find a shared account, require a named owner, a business purpose, an expiry date, and a retirement plan. Where an account truly must remain for a transition period, document the compensating control and the review date.
It also helps to measure the problem in a way leaders can act on. Track the number of shared SaaS accounts, the age of each exception, how many have been retired, and whether any still have broad access or no clear owner. NHIMG’s research indicates only 5.7% of organisations have full visibility into their service accounts, which is a strong reminder that discovery is usually the weak point, not policy wording. The organisations that reduce shared SaaS accounts fastest usually make ownership explicit, assign remediation dates, and review exceptions on a regular cadence rather than waiting for an audit.
Practitioner Guidance: Treat shared SaaS accounts as a governance backlog with security impact, not as a help desk cleanup item. The first question should be whether the account is still needed, not whether it is technically working; the second should be whether it can be replaced with named access without breaking a business process. If the answer is unclear, escalate to the department leader and require an expiration date before the exception continues.
Practitioner takeaway: The organisation should own the problem jointly, but IT should drive discovery and remediation, security should set the risk bar, and business leaders should justify any remaining shared access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Shared SaaS accounts rely on credentials and tokens that need central control. |
| NHI-03 — Lifecycle and Offboarding | Retiring shared SaaS accounts is an identity lifecycle and offboarding task. | |
| NHI-04 — Visibility and Inventory | Discovery depends on finding hidden shared accounts across SaaS tenants. | |
| Recommendation — Inventory shared SaaS credentials and retire or rotate them under a named owner. Define a retirement workflow with expiry, review, and documented exception handling. Build continuous inventory and reconcile accounts against business ownership. | ||
| CIS Controls v8 | 6.3 — Access to Systems and Services | Shared SaaS accounts are access paths that should be removed or tightly controlled. |
| 5.3 — Account Management | Account lifecycle control covers discovery, ownership, and retirement of shared accounts. | |
| Recommendation — Remove shared access paths and enforce named account use for SaaS services. Assign accountable owners and track shared-account retirement to completion. | ||
| NIST CSF 2.0 | GV.OC-02 — Roles, Responsibilities, and Authorities | The question is fundamentally about who owns detection and retirement of shared accounts. |
| PR.AA-01 — Identity Management, Authentication, and Access Control | Shared SaaS accounts are an access-control weakness that CSF addresses directly. | |
| DE.CM-01 — Monitoring for Anomalies and Events | Discovery of shared SaaS accounts depends on monitoring account use and anomalies. | |
| Recommendation — Assign clear accountability for shared-account discovery, approval, and retirement. Replace shared credentials with named, controlled access wherever possible. Monitor SaaS account usage patterns to uncover unowned or shared access. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Shared accounts weaken assurance about who is actually using the account. |
| AAL — Authenticator Assurance Level | Retiring shared accounts often means moving users to stronger authenticators. | |
| Recommendation — Use stronger identity assurance for named access instead of shared credentials. Require assurance-appropriate authenticators for each named user account. | ||
Related resources from NHI Mgmt Group
- Who is accountable for securing SaaS integrations that create blind spots across an organisation?
- Who should be accountable when a verified domain is shared across multiple SaaS organisations?
- Who is accountable when a compromised SaaS integration is used to move across multiple clouds?
- Who is accountable when AI agents use shared credentials across workflows?
