SaaS security best practices for 2025: the governance gap

At a glance

What this is: This is a SaaS security best-practices analysis showing that the main risk is not one control failure but the governance gap created by interconnected apps, external sharing, shadow IAM and weak monitoring.

Why it matters: It matters because SaaS estates now blend human access, machine integrations and data sharing paths, so IAM teams need controls that govern the whole access graph rather than each app in isolation.

Context

SaaS security is the set of controls that protects data, identities and permissions inside cloud-delivered applications. In this article, the primary problem is governance drift: organisations can no longer assume one admin console or one IAM policy can govern every connected app, share, and integration path.

Valence Security frames the issue around SaaS sprawl, shadow IAM, external data sharing and SaaS-to-SaaS integrations. Those are operational realities for IAM, IGA and security teams because access now moves through local accounts, delegated tokens and user-managed connections that sit outside classic perimeter thinking.

The security challenge is not that SaaS lacks controls. It is that the controls are distributed across multiple tenants, identities and data flows, so visibility, ownership and revocation become harder to coordinate than the applications themselves.

Key questions

Q: What breaks when SaaS apps are used outside SSO and central IAM?

A: The main failure is lifecycle control. If an app is not tied to SSO or the identity provider, offboarding, recertification, and access logging may never reach it. That leaves active accounts, orphaned licenses, and audit gaps even when the business believes access was removed.

Q: Why do tenant-wide SaaS integrations create a higher security risk than limited app connections?

A: Tenant-wide integrations expand blast radius because a third party can reach email, calendars, files, and account controls across the environment. If that integration is abused, misconfigured, or compromised, the attacker can move from a narrow foothold to broad administrative impact. That is why governance, scope restriction, and continuous review matter more than simple app approval.

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: Why do SaaS sprawl and shadow IT create IAM risk?

A: They create IAM risk because each unmanaged application introduces another identity system, another set of privileges, and another place where access can persist after need changes. Without central visibility, teams cannot reliably enforce least privilege, review entitlements, or revoke access consistently across the SaaS estate.

Technical breakdown

Why SaaS misconfigurations become access problems

A SaaS misconfiguration is not just a wrong toggle. In practice it is any access-setting, API permission or sharing rule that exposes data or functions beyond the intended audience. Because SaaS platforms are multi-tenant and frequently integrated with external systems, a single bad setting can expose records, widen delegation, or create silent data paths that bypass the central IAM stack. The real issue is that SaaS permissions are often granted and managed at the application layer, while review and enforcement still live in separate identity processes. That mismatch creates configuration drift that traditional IAM inventories do not reliably catch.

Practical implication: treat SaaS configuration review as a standing governance activity, not a one-time hardening exercise.

How shadow IAM and local accounts bypass central governance

Shadow IAM appears when users create local accounts or alternate access paths that are not governed by the corporate identity system. Those accounts can survive employee departure, ignore central MFA policy, and keep access active after the original business need is gone. In SaaS environments, this matters because local accounts often coexist with SSO, external shares and delegated app access, so governance teams can think a user is covered when they are not. The result is an offboarding blind spot, not just an authentication gap. Once access exists outside the primary directory, recertification and revocation become much harder to enforce consistently.

Practical implication: inventory non-SSO accounts and connect them to the same joiner-mover-leaver process as directory-backed identities.

Why SaaS-to-SaaS integrations need their own control plane

SaaS-to-SaaS integrations use OAuth tokens, API keys, webhooks and automation platforms to let one application act in another. That creates a delegated trust chain, where compromise or overreach in one app can cascade into multiple systems. This is not the same as ordinary user access because the integration often has broader and less visible scope than a human session, and it may run continuously without direct supervision. The control problem is lifecycle and scope at the connection level: who approved the integration, what permissions it holds, and what happens when the business relationship changes. Without that, the integration layer becomes a hidden privilege mesh.

Practical implication: govern SaaS integrations as identities with their own approval, review and revocation lifecycle.

Threat narrative

Attacker objective: The objective is to turn one weak SaaS access path into broader access to sensitive data and connected business workflows.

1. Entry begins when attackers or insiders exploit exposed SaaS surfaces such as misconfigured shares, weak authentication or unmanaged local accounts.
2. Credential or token abuse follows when delegated access, overpermissive OAuth connections or shadow IAM accounts provide a path past central controls.
3. Escalation occurs as SaaS-to-SaaS integrations and inherited permissions widen access across connected applications and data stores.
4. Impact is data exposure, unauthorized access or broad compromise across multiple SaaS tenants and business workflows.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

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

NHI Mgmt Group analysis

SaaS security is no longer an application problem, it is a governance problem across identities, integrations and data paths. The article’s real lesson is that control ownership is fragmented across the SaaS stack, while risk behaves like a connected graph. That means the operating model for IAM, IGA and security must shift from app-by-app review to cross-app governance.

Shadow IAM is the clearest example of governance drift in SaaS environments. Local accounts, unsanctioned app access and bypassed SSO create a parallel identity estate that central teams do not reliably see. The implication is simple: if the directory is the only governed identity source, the programme is already incomplete.

SaaS-to-SaaS integration is a delegated trust problem, not just a connectivity feature. OAuth tokens, API keys and automation links can carry more privilege than the user who approved them. That makes integration lifecycle, scope control and revocation part of the identity security baseline, not an adjacent security task.

External sharing and overprivileged access show that least privilege in SaaS must be enforced at the data layer as well as the identity layer. In modern SaaS estates, access reviews that ignore shares, guest access and inherited permissions will understate real exposure. Practitioners need to govern the access graph, not just the user list.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Security Platform Buyer's Guide

What this signals

Shadow SaaS and shadow IAM should be treated as an identity governance problem, not a discovery problem. Once users can create local accounts, external shares and delegated connections outside central control, visibility alone does not close the gap. The programme has to decide which access paths are allowed to exist outside the directory and which ones must be brought back under lifecycle control.

SaaS discovery needs to extend to service-account visibility and integration inventory at the same time. Only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any environment where app-to-app trust is built on tokens and automation. Practitioners should assume hidden access paths exist until the full connection map proves otherwise.

For practitioners

• Audit shadow IAM paths Find local SaaS accounts, alternate login methods and unsanctioned app connections, then map each one back to an owner and a business purpose.
• Review external shares and guest access Check inactive links, permissive folder sharing and external collaborators across the highest-value SaaS applications, then revoke access that no longer matches current need.
• Treat integrations as governed identities Maintain an inventory of OAuth tokens, API keys, webhooks and automation links, with explicit approval, scope review and revocation ownership.
• Extend recertification beyond the directory Include local accounts, shared folders and app-level permissions in access reviews so the review reflects the actual SaaS access graph.
• Monitor for anomalous SaaS behaviour Track unusual login patterns, data access spikes and new third-party connections so the team can detect drift before it becomes exposure.

Key takeaways

• SaaS risk in 2025 is driven by governance gaps across sharing, integrations and local accounts, not by a single control failure.
• The strongest evidence in the article is that SaaS environments now combine shadow IAM, delegated access and hidden data paths that central IAM does not fully see.
• Teams should extend review, monitoring and revocation to the full SaaS access graph, including integrations and external shares.

Key terms

• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a machine-to-machine connection that lets one cloud application access another through delegated credentials. In NHI governance terms, it creates a persistent identity, a permission scope, and a lifecycle obligation that must be reviewed like any other access relationship.
• Shadow IAM: Shadow IAM refers to identity and access paths created outside the central identity program, usually through local SaaS accounts, ad hoc OAuth grants, or application-specific permissions. These entitlements often survive offboarding because they are not governed by the same lifecycle controls as directory-backed access.
• External data sharing: External data sharing is the exposure of files, records, or application data to users outside the intended internal trust boundary. In SaaS environments it often persists through stale links, default permissions, or forgotten shares, so it must be governed as an access lifecycle problem rather than a one-time setting.
• Software As A Service Security Posture Management: Software as a Service Security Posture Management is the continuous assessment and control of security settings, access, and data exposure across SaaS applications. It focuses on misconfigurations, excessive permissions, risky integrations, and weak governance. The discipline maps SaaS controls to policy, detects drift, and supports remediation before exposure becomes an incident.

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.