SaaS discovery and integration governance now define exposure control

At a glance

What this is: This is Valence Security’s 2025 SaaS security overview, and its central finding is that shadow apps, misconfigurations, and trusted integrations combine to create silent data exposure paths.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams all have to govern SaaS identities, OAuth scopes, and offboarding gaps before trusted connections become attack paths.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Valence Security's post on SaaS security risks and discovery controls

Context

SaaS environments fail when teams treat connected apps as low-risk utilities instead of governed identities and data pathways. The primary security problem is not just the application itself, but the combination of shadow SaaS, excessive permissions, dormant accounts, and unmanaged external sharing that quietly expands access.

For IAM practitioners, this is an identity governance problem across both human and non-human actors. OAuth-connected apps, service accounts, and stale super-admin privileges all need the same lifecycle discipline that security teams already apply to joiner-mover-leaver processes, recertification, and privileged access.

The Valence Security post uses Halloween framing, but the operational point is straightforward: attackers do not need to defeat SaaS if trusted integrations, account ownership, and data exposure rules are already loose. That is typical in mature SaaS sprawl environments, not an edge case.

Key questions

Q: What breaks when SaaS integrations are not governed as non-human identities?

A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls. The practical failure is blast radius, not just access. One over-scoped token or service account can expose multiple downstream platforms, especially when ownership, rotation, and review are missing.

Q: Why do over-permissioned SaaS accounts increase exposure so quickly?

A: Because excessive roles and stale admin accounts turn a single compromise into broad access across files, integrations, and external sharing paths. In SaaS, privilege is often inherited through defaults, so the blast radius expands faster than teams expect when governance is not continuously refreshed.

Q: How do security teams know if SaaS identity controls are actually working?

A: Look for evidence that lower-assurance identities are fully segregated from sensitive backend paths, not just authenticated differently. A control is working when a breach at one trust tier cannot reach another tenant's data, administrative functions, or session context. If lateral reach remains possible, the control is cosmetic.

Q: What is the difference between SaaS configuration and SaaS governance?

A: SaaS configuration is the on or off state of a feature. SaaS governance is the policy, ownership, monitoring, and cleanup process that determines whether the feature can be used safely. A disabled setting may reduce exposure, but only governance ensures identities, content, and exceptions are managed over time.

Technical breakdown

Shadow SaaS discovery and OAuth-connected app visibility

Shadow SaaS emerges when employees connect unsanctioned applications with OAuth or similar delegated access and IT never gains a complete inventory. The identity problem is that the app becomes a persistent access path even when no one formally owns it. Discovery matters because you cannot govern scopes, data access, or lifecycle state for apps you have not identified. In practice, SaaS discovery must map who connected the app, what data it can reach, and whether the integration still serves a business purpose.

Practical implication: build an inventory of unsanctioned apps and their OAuth scopes before they become unmanaged access paths.

Misconfigurations, stale admin accounts, and excessive privilege in SaaS

SaaS misconfigurations turn default sharing settings, overbroad roles, and dormant admin accounts into direct exposure mechanisms. These failures are identity failures as much as configuration failures because the privilege model does not match current business need. Least privilege in SaaS is only real when admin ownership, sharing defaults, and access reviews are continuously maintained. Stale super-admin accounts are especially risky because they preserve high-impact access long after the original need has expired.

Practical implication: continuously recertify admin roles and remove dormant privileged accounts before they remain as standing exposure.

SaaS-to-SaaS integrations as non-human identities

SaaS-to-SaaS integrations often behave like non-human identities, because they depend on tokens, scopes, and service accounts rather than human logins. Once a token is harvested, the attacker can use trusted connections to move through SaaS systems without breaking perimeter controls. This changes the governance question from simple authentication to lifecycle control over connected identities. If the integration remains active after the original trust relationship should have ended, the access window stays open.

Practical implication: treat integration tokens and service accounts as governed NHIs and review their scopes, ownership, and expiry state.

Threat narrative

Attacker objective: The attacker objective is to exploit trusted SaaS relationships to gain persistent access and move data without triggering normal perimeter-based controls.

1. Entry begins when users create shadow SaaS connections or attackers obtain OAuth tokens from a compromised integration path.
2. Escalation occurs when over-permissioned scopes, stale admin accounts, or silent service accounts provide broader access than the business intended.
3. Impact follows when trusted SaaS connections are used to export data, bypass perimeter assumptions, and persist after the original access event.

Breaches seen in the wild

• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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

NHI Mgmt Group analysis

Shadow SaaS is an identity governance failure before it is a discovery problem. If security teams cannot see which applications are connected, they cannot govern scopes, ownership, or offboarding. The real risk is not the app alone, but the fact that it can remain a trusted access path outside formal control. Practitioners should treat unsanctioned SaaS as unmanaged identity infrastructure, not just shadow IT.

SaaS integrations behave like non-human identities and should be governed that way. OAuth tokens, service accounts, and delegated app connections carry the same lifecycle risks as other NHIs: over-scoping, persistence, and unclear ownership. The article’s Salesforce/Drift example is a reminder that trusted integrations can become long-lived attack paths if they are not reviewed and removed on schedule. The right governance lens is NHI lifecycle control, not application inventory alone.

Misconfiguration and over-privilege in SaaS create identity blast radius. When sharing defaults, admin roles, and external links are too broad, every compromise becomes more damaging than it should be. The blast radius is determined by how much privilege and data exposure the platform permits by default. Practitioners should measure SaaS posture by how quickly excessive access can be reduced, not by how many apps have been catalogued.

Identity lifecycle discipline now has to extend across human and machine SaaS access. Dormant human accounts, orphaned admin roles, and stale service accounts are different symptoms of the same governance weakness. The programme-level conclusion is that joiner-mover-leaver controls no longer stop at HR-managed accounts. They must cover SaaS identities, delegated integrations, and the data-sharing pathways attached to both.

Ultimate Guide to NHIs: Lifecycle Processes for Managing NHIs is the clearest framework for turning SaaS integration governance into operational lifecycle control. The article’s own checklist points in the same direction: discover, govern, secure, and remediate. That sequence is now the minimum viable model for trusted SaaS access, especially where OAuth and service accounts create persistent exposure.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For a lifecycle control lens, NHI Lifecycle Management Guide shows how visibility, rotation, and offboarding fit together.

What this signals

Shadow SaaS is now a lifecycle problem, not just a discovery problem. Once a connected app exists, the question becomes who owns it, what it can reach, and when it should be removed. Teams that do not extend access review and offboarding processes to integrations will keep rebuilding the same exposure window in different tools.

Identity blast radius is the right way to think about SaaS posture. The issue is not whether a platform is sanctioned, but how much access and data it can expose if a token, role, or sharing rule is abused. That means programme owners should measure scope reduction and stale-account cleanup as operational outcomes, not just catalogue completeness.

With only 5.7% of organisations having full visibility into their service accounts, the control gap is already large enough to support silent SaaS integration risk. Security teams should align SaaS governance to NIST Cybersecurity Framework 2.0 and the CSA Cloud Controls Matrix where identity, audit, and third-party access intersect.

For practitioners

• Inventory every SaaS connection and shadow application Map unsanctioned apps, identify the users who connected them, and document the data each integration can reach. Prioritise apps with OAuth scopes, external sharing, or access to regulated data.
• Recertify privileged SaaS roles and dormant accounts Run recurring access reviews for super-admins, app owners, and service accounts that support SaaS workflows. Remove accounts that no longer have an active business owner or current operational need.
• Govern integration tokens as NHI credentials Track scopes, expiry, ownership, and revocation for every SaaS-to-SaaS integration token. Revoke integrations that cannot be tied to a named business function or reviewed on a defined cadence.
• Tighten external sharing and link exposure rules Apply expiration dates to shared links, restrict sharing to approved domains, and alert on data exposed through public or personal email routes. Treat external shares as part of SaaS identity exposure, not just data loss risk.
• Use posture automation to close exposure windows Pair SaaS discovery with automated remediation for risky settings, stale accounts, and overbroad permissions. The goal is to shorten the time between exposure detection and access removal.

Key takeaways

• Shadow SaaS, misconfiguration, and stale integrations create identity-driven exposure that traditional app inventories do not solve.
• Trusted SaaS connections can become long-lived attack paths when OAuth scopes, service accounts, and admin roles are not lifecycle-managed.
• The practical response is to govern SaaS access as NHI and IAM work together, with discovery feeding recertification, revocation, and posture cleanup.

Key terms

• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Dormant Privileged Account: A dormant privileged account is an administrative identity that still exists and can often still authenticate, even though its original business purpose has ended. These accounts are dangerous because they preserve standing access long after ownership, review, or offboarding should have removed them.

What's in the full article

Valence Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step SaaS discovery workflow for finding unsanctioned apps and connected integrations
• Operational checklist for reviewing OAuth scopes, external sharing, and dormant administrative access
• Practical remediation sequence for fixing misconfigurations and offboarding unneeded accounts
• Quick survival checklist that maps discovery, governance, and remediation into a single workflow

👉 The full Valence Security post covers SaaS discovery, integration governance, and risky sharing cleanup in more operational detail.

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.