SaaS security best practices for 2025: the governance gap

At a glance

What this is: This is an analysis of SaaS security best practices for 2025, with the central finding that SaaS sprawl, shadow IAM, and integration risk require continuous governance rather than point-in-time controls.

Why it matters: For IAM and NHI practitioners, the article matters because SaaS apps now behave like a distributed identity layer, where access, sharing, and offboarding failures can expose both human and non-human credentials.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Valence Security's blog on SaaS security best practices for 2025

Context

SaaS security is now an identity and access problem as much as a data protection problem. Once organisations connect dozens of cloud applications, every shared dataset, delegated integration, and local account becomes part of the governance surface. That is why SaaS security best practices have to include visibility, entitlement control, and lifecycle management for both human access and NHI-related integrations.

The article frames a familiar but still undercontrolled pattern: SaaS convenience creates fragmented access paths that IAM teams do not always see. Shadow IAM, over-permissive external sharing, and weak offboarding are all symptoms of the same issue. The starting position described here is typical for modern enterprises, not exceptional, which is why the control model has to change.

For practitioners, the key shift is to treat SaaS as a continuous trust environment rather than a collection of separate applications. That means monitoring not only users, but also service-to-service connections, OAuth grants, and exposed data paths. The right question is no longer whether SaaS is secure by default, but whether governance can keep pace with how quickly access expands.

Key questions

Q: How should security teams govern SaaS applications that rely on integrations and shared data?

A: Treat SaaS governance as a combined identity, data, and integration problem. Start with a complete inventory of users, local accounts, OAuth grants, and service connections, then enforce least privilege, periodic access review, and rapid revocation for stale permissions. Continuous monitoring only works when findings trigger concrete entitlement changes.

Q: When do SaaS sharing settings become a real security risk?

A: Sharing becomes risky when access outlives the business need, crosses organisational boundaries, or is granted without ownership and review. The danger is not only exposure of a file or record, but the creation of persistent access paths that are hard to detect and even harder to revoke.

Q: What is the difference between SaaS posture management and IAM governance?

A: SaaS posture management finds misconfigurations and risky settings inside the applications, while IAM governance decides who should have access, for how long, and under what conditions. Strong programmes need both: posture signals tell you where exposure exists, and IAM controls determine whether that exposure should remain.

Q: Why do SaaS environments increase the blast radius of an identity compromise?

A: Because one compromised account or integration can unlock multiple applications, shared datasets, and delegated permissions. In a connected SaaS stack, access is often inherited across tools, so a single weak identity can become a pathway to broad, persistent exposure if lifecycle controls are not enforced.

Technical breakdown

Why SaaS misconfigurations become identity failures

SaaS misconfigurations are rarely just configuration mistakes. In practice, they create identity failures by granting excessive access, leaving stale shares active, or allowing unmanaged applications to inherit trust through integrations. Because SaaS platforms often centralise data from many business processes, a single weak control can expose data across multiple tenants, users, and connected tools. The security issue is not only the misconfiguration itself, but the way it alters who can act on data and under what conditions. That is why SaaS posture management and identity governance increasingly overlap.

Practical implication: classify SaaS misconfigurations as access-control defects, not only platform hygiene issues.

How SaaS-to-SaaS integrations create non-human identity risk

SaaS-to-SaaS integrations often rely on OAuth grants, API tokens, or service accounts that operate as non-human identities. These connections can persist long after the original business need changes, and they often have broader privileges than a human user would be allowed. The result is a hidden trust chain between applications, where an attacker who compromises one integration can move through related systems without needing to defeat interactive authentication. Governance must therefore extend to delegated access, app consent, and integration review, not just user login controls.

Practical implication: inventory OAuth grants and integration privileges the same way you inventory privileged accounts.

Why shadow IAM and weak offboarding increase SaaS blast radius

Shadow IAM appears when users create local accounts or application-specific access paths outside central identity controls. In SaaS environments, this often combines with incomplete offboarding, which leaves external shares, app passwords, and dormant accounts active after the user departs. The failure mode is cumulative: each unmanaged identity adds another path to data and another gap in revocation. In NHI terms, this is a lifecycle problem, because access that is easy to create but hard to revoke will eventually widen the blast radius of any compromise.

Practical implication: tie SaaS offboarding to automated entitlement revocation across all connected applications.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed SaaS identity or integration into broad, persistent access across the enterprise’s cloud application stack.

1. Entry occurs through an overly permissive SaaS share, a stale OAuth grant, or a locally created account that bypasses central review.
2. Escalation happens when the attacker uses connected SaaS apps and inherited permissions to reach additional data sets or administrative actions.
3. Impact is unauthorized access to sensitive business data across multiple cloud applications, often with limited detection because the activity looks like normal application use.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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 now an identity governance problem, not just an app security problem. The article’s emphasis on misconfigurations, sharing, and monitoring is directionally right, but the deeper issue is that SaaS platforms have become part of the identity plane. When access is distributed across apps, users, and integrations, the control question shifts from hardening a single application to governing a living trust graph. Practitioners should therefore evaluate SaaS through the lens of access lifecycle, not only posture.

Shadow IAM is the SaaS analogue of shadow NHI. Local accounts, unmanaged grants, and unsanctioned app connections create access that central teams cannot reliably see or revoke. That creates an identity blast radius problem, because every hidden credential or integration becomes an unmanaged recovery path after compromise. The governance response should be inventory-first and revocation-driven.

External sharing is only half the risk; delegated access is the rest. Many teams focus on file-sharing settings while leaving OAuth consents, app-to-app permissions, and dormant integrations untouched. That is a partial model of exposure, because attackers increasingly prefer persistent delegated access over noisy interactive login. Practitioners should treat consent review as a standing control, not a periodic exception.

Continuous monitoring matters only if it is tied to action. SaaS environments generate enough activity to overwhelm manual review, so posture tools and log review must feed specific revocation, remediation, and re-approval workflows. Otherwise the organisation gains visibility without reducing dwell time. The practical benchmark is not how much SaaS telemetry exists, but how quickly it changes access decisions.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For the operational angle, see NHI Lifecycle Management Guide for lifecycle controls that reduce lingering SaaS and integration risk.

What this signals

Shadow IAM in SaaS is converging with shadow NHI. As organisations connect more applications, the practical control problem is less about adding another monitoring dashboard and more about knowing which identities can still act. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the trust boundary is already too wide for ad hoc governance. That is a lifecycle issue, not just a configuration issue, and it aligns closely with the control themes in the NHI Lifecycle Management Guide.

Practitioners should expect SaaS posture tools to become more valuable when they feed identity review and revocation workflows directly. The use case is not simply detection of bad settings, but reduction of standing access across connected applications. In Zero Trust terms, the organisation must be able to re-verify every grant, every connection, and every share as business context changes, consistent with the NIST Cybersecurity Framework 2.0.

For practitioners

• Inventory SaaS identities and integrations Build a complete register of SaaS users, local accounts, OAuth grants, API tokens, and service-to-service connections. Include application owners and business justification so dormant access can be identified during reviews.
• Revoke stale external shares and app consents Schedule regular audits for inactive shares, outdated permissions, and abandoned app consents across collaboration and CRM platforms. Remove anything that no longer has a documented business need.
• Automate SaaS offboarding across connected apps Tie employee exit and role-change workflows to revocation actions in every connected SaaS application, including local accounts and delegated access. Manual follow-up should be the exception, not the process.
• Treat SaaS posture findings as identity events Route misconfiguration alerts into IAM and SOC workflows so high-risk findings trigger entitlement review, not just ticket creation. Prioritise exposures that combine broad sharing with privileged integrations.
• Monitor integrations for privilege drift Track changes to OAuth scopes, token age, and app-to-app trust relationships so integrations are reapproved when their access expands. This helps prevent quiet privilege growth inside SaaS ecosystems.

Key takeaways

• SaaS security failures often begin as access governance problems, not isolated application defects.
• Connected apps, stale shares, and unmanaged integrations can turn one exposed identity into a broad enterprise blast radius.
• The practical response is continuous inventory, revocation, and review across both human and non-human access paths.

Key terms

• Shadow IAM: Shadow IAM is access created or managed outside central identity controls, often through local accounts, app-specific permissions, or unsanctioned integrations. In SaaS environments it becomes a hidden governance layer that can persist after an employee leaves or a business need ends, making revocation and audit much harder.
• SaaS-to-SaaS integration: A SaaS-to-SaaS integration is a trust relationship between two cloud applications that allows one system to act on behalf of a user or service. These connections commonly use OAuth grants, API tokens, or service accounts, and they expand the attack surface when their privileges are broader or longer-lived than intended.
• 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.

Deepen your knowledge

SaaS identity governance and integration risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment depends on connected cloud applications, the course helps translate that risk into a workable control model.

This post draws on content published by Valence Security: SaaS Security Best Practices and Strategies for 2025. Read the original.