SaaS data sharing sprawl is creating a governance gap in 2025

At a glance

What this is: This analysis argues that SaaS collaboration has outgrown traditional security oversight, with long-lived external shares, personal email sharing, and dormant integrations creating unmanaged exposure.

Why it matters: It matters because SaaS sharing now behaves like an identity and access problem, which means IAM and NHI teams need governance, not just data classification, to reduce risk.

By the numbers:

• 58% of organizations experienced at least one SaaS-related security incident in the past year.
• 94% of external data shares in SaaS applications were inactive.
• 46% of external shares were sent to personal email accounts.

👉 Read Valence Security's analysis of SaaS data sharing risk in 2025

Context

SaaS data sharing becomes a governance problem when collaboration tools outlive the business context that created the access. Links, delegated shares, and external accounts often remain active long after the work is done, which means the control failure is not visibility alone but the absence of lifecycle discipline across shared access.

For IAM and NHI practitioners, this is the same structural issue seen in other identity domains: privileges are granted easily, reviewed inconsistently, and revoked too late. The article frames a familiar but under-managed pattern, and that starting point is typical in SaaS-heavy environments.

The article also points to a broader NHI concern: third-party integrations and API-based connections behave like non-human identities with their own trust and revocation requirements. That makes SaaS sharing part of the same governance surface as service accounts, OAuth grants, and automation tokens.

Key questions

Q: How should security teams control SaaS data sharing risk?

A: Security teams should treat SaaS sharing as an access governance problem. That means enforcing expiry on external links, requiring ownership for every share, reviewing dormant permissions regularly, and revoking unused integrations. DLP helps, but lifecycle controls matter more because persistent access creates exposure even when no active attack is visible.

Q: Why do SaaS sharing controls fail so often?

A: They fail because many organisations rely on policy, not enforcement. Users can create links, external shares, and personal-email transfers faster than security teams can review them, and those permissions often stay valid long after the work ends. Without continuous visibility and revocation, risk accumulates quietly.

Q: What is the difference between access review and sharing revocation?

A: Access review asks whether a share or integration should still exist, while revocation removes the access when it no longer has a valid purpose. Both are necessary, but revocation is the control that actually reduces exposure. Review without removal leaves standing access in place.

Q: Should organisations treat SaaS integrations like non-human identities?

A: Yes. SaaS integrations use OAuth tokens, API keys, and service accounts that function as non-human identities, so they need discovery, ownership, expiry, and offboarding controls. If teams leave them outside IAM governance, they become dormant trust relationships that can persist for months or years.

Technical breakdown

Why SaaS sharing behaves like an identity problem

Modern SaaS collaboration does not just move files around. It creates access grants through links, delegated permissions, OAuth connections, service accounts, and external accounts that can persist beyond the original business need. In practice, the security issue is not simply data exposure, but the control plane behind that exposure. When access is granted through application features rather than centrally governed entitlements, security teams lose the ability to enforce consistent review, expiry, and revocation. That is why SaaS sharing should be treated as a lifecycle and authorization problem, not only a content problem.

Practical implication: Map SaaS sharing paths to entitlement owners and review them like other privileged access channels.

Why open links and personal email create durable exposure

Open-link sharing removes authentication from the access decision, while personal email sharing moves sensitive data outside enterprise control. Both patterns weaken auditability because the organization cannot reliably verify who is receiving the data, how long access remains valid, or whether that access survives employee departure. The risk is amplified when links are forwarded, indexed, or stored on unmanaged devices. This is a classic standing-access problem: once the link exists, the burden shifts to the defender to discover and revoke it after the fact.

Practical implication: Require expiry, owner approval, and automatic revocation for all externally shared SaaS content.

How dormant integrations expand the non-human identity surface

SaaS ecosystems often rely on thousands of machine-to-machine relationships. OAuth tokens, API keys, and service accounts let apps exchange data without a human in the loop, which makes them non-human identities by function even when the business treats them as convenience settings. Dormant integrations are dangerous because they often retain access after the original use case has ended, and they can be difficult to inventory without dedicated discovery. That creates a hidden trust layer inside collaboration platforms, one that behaves like any other unmanaged credential set.

Practical implication: Inventory integrations continuously and revoke unused access on a defined schedule.

Threat narrative

Attacker objective: The attacker wants durable access to sensitive SaaS data through weakly governed sharing paths that are hard to detect and revoke.

1. Entry occurs through a SaaS sharing feature such as an open link, delegated external share, or dormant third-party integration.
2. Escalation happens when the share persists beyond the intended business use and reaches personal accounts, external parties, or compromised devices.
3. Impact follows when sensitive data is downloaded, forwarded, or exfiltrated without a reliable audit trail.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Persistent SaaS sharing creates identity debt, not just data risk. Once a link, share, or integration is created, the organisation inherits a standing-access obligation that outlives the original business task. That obligation compounds as collaboration sprawl grows across business units and personal workflows. Practitioners should treat every external share as a revocable entitlement with an owner and an expiry.

Open-link sharing is a control bypass disguised as convenience. If access is granted to anyone with a URL, the organisation has effectively shifted from identity-based authorisation to possession-based access. That model is incompatible with modern governance expectations because it erases authentication, narrows auditability, and makes abuse difficult to attribute. Security teams should prioritise link expiry and revocation over after-the-fact detection.

Third-party integrations are the NHI layer inside SaaS collaboration. OAuth tokens, API keys, and service accounts create machine access paths that often receive weaker review than human accounts. The problem is not that integrations exist, but that many are created once and forgotten. NHI governance should extend into SaaS apps, where dormant machine access becomes a long-tail exposure source.

Data sharing controls now need lifecycle management, not just policy statements. Policies that prohibit risky sharing do little if the platform cannot enforce expiry, review, and offboarding automatically. The field is moving toward governance that combines visibility, entitlement ownership, and continuous revocation. Practitioners should assume that unmanaged sharing will continue unless the control plane is designed to remove it on purpose.

Shadow SaaS sharing is becoming a parallel shadow AI problem. The same organisational patterns that allow unmanaged external sharing also allow unmanaged automated access paths to multiply quietly. That convergence means IAM teams cannot separate SaaS governance from NHI and agentic access governance. Teams should build one access review model that can cover people, integrations, and autonomous systems.

From our research:

• 94% of external data shares in SaaS applications were inactive, according to the Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For lifecycle control patterns that extend beyond SaaS sharing, see NHI Lifecycle Management Guide.

What this signals

Persistent sharing is now a standing-access problem that should be governed alongside NHI sprawl. When 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, the operating assumption should be that access paths will outlive the use case unless the platform can remove them automatically. Security programmes should align SaaS sharing with entitlement lifecycle management.

Identity blast radius is the right lens for SaaS collaboration. The issue is not only who can see a file, but how far a single share can propagate across email, links, devices, and third-party apps before anyone notices. That makes NIST Cybersecurity Framework 2.0 a useful control map for govern, identify, protect, detect, respond, and recover functions when applied to SaaS data paths.

In practice, teams should expect SaaS governance to converge with NHI governance and agentic access controls. The same discovery, ownership, and revocation logic that works for machine credentials should now be extended to sharing links and integrations, because the threat model is already blended.

For practitioners

• Implement expiry on all external shares Require time-bound external links and delegated shares, with automatic revocation when the collaboration window closes.
• Inventory dormant SaaS integrations continuously Build a recurring review for OAuth tokens, API keys, and service accounts inside SaaS apps, and revoke unused integrations on a defined schedule.
• Block personal email sharing for sensitive data Use DLP and policy enforcement to prevent sharing to personal domains unless an exception is explicitly approved and logged.
• Assign clear owners for every shared data path Tie each share, link, and integration to a business owner responsible for approval, review, and removal when the use case ends.
• Extend NHI governance into SaaS collaboration Treat SaaS integrations as non-human identities and apply the same discovery, entitlement review, and revocation discipline used for other machine credentials.

Key takeaways

• SaaS data sharing has become an access governance issue because links, external shares, and integrations often remain valid long after the business need ends.
• Valence Security’s survey findings show that inactive shares and personal-email transfers are common, which means unmanaged collaboration paths are already part of the attack surface.
• Security teams should enforce expiry, ownership, discovery, and revocation across SaaS sharing and treat integrations as non-human identities.

Key terms

• SaaS data sharing: SaaS data sharing is the movement of files, records, or content through collaboration features, links, delegated permissions, and application integrations. In security terms, it is an access problem because every share creates a standing path that must be owned, reviewed, and eventually removed.
• Open-link sharing: Open-link sharing grants access to anyone who has the URL, often without requiring the recipient to authenticate first. This creates a possession-based access model that weakens auditability and makes accidental forwarding, indexing, and unmanaged reuse much more likely.
• Dormant integration: A dormant integration is a third-party SaaS connection that still holds access even though the original business use has ended. These relationships often rely on OAuth tokens, API keys, or service accounts, so they should be governed as non-human identities with expiry and offboarding controls.
• Identity blast radius: Identity blast radius is the scope of damage that can result when one account, token, or share is abused. In SaaS environments, it includes how far access can spread across users, files, external recipients, and connected applications before the organisation detects and revokes it.

Deepen your knowledge

SaaS data sharing governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity controls into collaboration platforms and machine access, it is worth exploring.

This post draws on content published by Valence Security: Taming the Wild West of SaaS Data Sharing. Read the original.