Hidden SaaS app risk exposes the identity surface in modern enterprises

At a glance

What this is: This is a SaaS risk analysis that argues hidden app usage, third-party integrations, and weak governance expand the organisation’s attack surface.

Why it matters: It matters because unmanaged SaaS creates identity, data, and lifecycle blind spots that affect NHI, human access, and downstream control decisions across IAM, IGA, and PAM.

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.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Zluri's analysis of the hidden security risks in SaaS app sprawl

Context

SaaS risk is not just a software inventory problem. It is an identity governance problem created when employees adopt applications, connect them to corporate data, and leave IT without a complete view of who or what can access sensitive information.

For IAM, the issue spans human identity, service account access, and NHI governance because the control failure is often the same: access is granted outside approved lifecycle processes, then persists through unsanctioned apps and third-party integrations.

When app sprawl is invisible, security teams cannot reliably judge data exposure, compliance scope, or downstream privilege. That makes SaaS usage one of the clearest examples of identity surface expansion in modern enterprises.

Key questions

Q: How should security teams govern unsanctioned SaaS apps in the enterprise?

A: Security teams should govern unsanctioned SaaS by discovering every app in use, assigning an owner, and mapping its data access before allowing it to remain connected. The key is to treat each app as a governed identity surface, with approval, review, and offboarding tied to actual business use rather than informal adoption.

Q: Why do shadow IT apps create more risk than simple software sprawl?

A: Shadow IT apps create more risk because they introduce hidden access paths to data, identity providers, and downstream services. The problem is not only that the software is unapproved, but that its permissions and integrations can persist outside lifecycle control, leaving security and compliance teams unable to see or revoke exposure cleanly.

Q: What do security teams get wrong about SaaS visibility?

A: Teams often assume visibility means control, but discovery alone does not reduce risk. A SaaS app can be fully known and still remain dangerous if no one owns it, no one reviews its permissions, and no one removes its access when business need changes. Visibility is the starting point, not the control outcome.

Q: Who should be accountable for risky SaaS integrations and app offboarding?

A: Accountability should sit with the business owner of the app, supported by IAM, security, and compliance teams. Risky integrations need an explicit owner because the authority to connect data sources is also the responsibility to remove access, prove compliance, and confirm that delegated permissions have been revoked.

Technical breakdown

How unsanctioned SaaS creates identity surface sprawl

Unsanctioned SaaS becomes an identity problem when employees connect accounts, tokens, and app permissions without a governed onboarding path. Each app can inherit access to data stores, collaboration systems, or directory-linked identity providers. The result is not just extra software, but extra identities, extra trust relationships, and extra places where access can persist after the original business need is gone. Because the apps are outside standard procurement and security review, the organisation often loses the ability to map ownership, entitlements, and data flow with confidence.

Practical implication: establish discovery and ownership mapping for every SaaS app before it is allowed to connect to corporate identity or data systems.

Why third-party integrations turn SaaS into an access chain

A connected SaaS ecosystem creates a chain of delegated access. If one app can read, modify, or sync data from another system, the security boundary shifts from the application itself to the permissions behind the integration. That means a weakly controlled app can become a pathway into storage, collaboration, or directory services. In identity terms, the integration often functions like an NHI: it has credentials, scopes, and ongoing authority that are easy to overlook if teams only review human users. This is where governance must examine both the primary app and every connected trust relationship.

Practical implication: review app-to-app permissions as if they were privileged non-human identities, not just software features.

Why compliance failure follows unmanaged app usage

Compliance breaks when data moves into systems that were never assessed for policy, retention, encryption, or jurisdictional handling. An unsanctioned app can collect regulated data, transmit it without sufficient controls, or retain it outside approved records management processes. The security issue and the compliance issue are the same event viewed from different angles. If the organisation cannot identify every app in use, it cannot reliably prove where regulated data lives or who can access it. That makes audit evidence, policy enforcement, and incident response all weaker at the same time.

Practical implication: tie SaaS discovery to compliance control mapping so every app is checked against data handling, retention, and encryption requirements.

Threat narrative

Attacker objective: The objective is to reach sensitive corporate data through an ungoverned SaaS trust chain and use that access for theft, exposure, or further compromise.

1. Entry occurs when an employee adopts an unsanctioned SaaS app and connects it to corporate workflows or data without security review.
2. Escalation follows when the app receives linked access to files, directories, or other systems through permissive integrations or inherited credentials.
3. Impact emerges as data is exposed, moved laterally across connected services, or handled in ways that violate policy and compliance requirements.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Identity surface sprawl is the real hidden risk in SaaS adoption. The article describes app shadowing, third-party integrations, and unmanaged usage, but the deeper issue is that every unsanctioned app creates a new identity boundary without a corresponding governance owner. That expands the organisation's attack surface beyond what CMDB-style software inventory can show. Practitioners should treat SaaS discovery as identity discovery, not just asset discovery.

Unmanaged SaaS integrations behave like non-human identities with no lifecycle control. The access path is not just the app itself, but the credentials, scopes, and delegated permissions it uses to move data. This is why discovery, entitlement review, and offboarding must cover app-to-app trust chains as well as human users. The practical conclusion is that integration governance belongs inside IAM and IGA, not only in SaaS administration.

Shadow IT becomes a compliance problem when data handling obligations cannot be mapped to the apps in use. The article links unsanctioned apps to policy and regulatory exposure, and that is the correct direction of travel. If the organisation cannot prove which app holds which data, then encryption, retention, and access reviews are already incomplete. Practitioners should read SaaS sprawl as evidence that control coverage has diverged from actual usage.

Identity governance for SaaS must extend to approval, ownership, and offboarding, not just sign-in controls. The article's focus on visibility is necessary but not sufficient, because visibility alone does not revoke access or constrain risky sharing. Mature programmes need ownership assignment, usage thresholds, and review cycles tied to business purpose. The practitioner takeaway is that SaaS governance should be managed as a lifecycle discipline across both human and non-human access.

Hidden SaaS risk is a cross-domain governance issue, not a single-control failure. The same unsanctioned app can create identity sprawl, data leakage, and audit failure at once. That means IAM, security operations, compliance, and procurement all need to work from one authoritative app inventory. Practitioners should assume that unmanaged SaaS will surface as multiple control failures before it appears as a breach.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That pattern makes NHI Lifecycle Management Guide the natural next read for teams formalising ownership, rotation, and offboarding.

What this signals

Identity surface sprawl: SaaS governance is moving from app approval to continuous entitlement oversight, because every unsanctioned connection can become an unmanaged access path. Teams that still separate SaaS management from IAM will miss the control point where shadow IT becomes policy drift.

The practical signal for programmes is that discovery and lifecycle control now need to converge. If an app can access corporate data, it belongs in the same governance workflow as other non-human identities, with ownership, review cadence, and offboarding tied to actual usage.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader access problem is already structural, and SaaS sprawl only widens the exposure window.

For practitioners

• Build a complete SaaS discovery inventory Use SSO logs, finance systems, direct integrations, and browser or endpoint telemetry to identify every SaaS app that has touched corporate accounts or data. Reconcile app ownership and business purpose before permitting further integration.
• Classify every connected app by trust and data access Assign risk levels based on what each app can read, modify, or sync, then review the permissions behind those integrations as privileged access paths. Treat app-to-app connections as governed trust relationships, not convenience features.
• Tie SaaS offboarding to access revocation When an app is no longer approved or no longer needed, remove its integrations, tokens, and user grants, then verify that data sharing and synchronization have stopped. Link this to the wider NHI lifecycle management process where app credentials are involved.
• Align SaaS usage with compliance controls Map each app that handles regulated or sensitive data to retention, encryption, residency, and audit requirements. If an app cannot be mapped cleanly, move it into review or restriction until the control gap is closed.

Key takeaways

• Hidden SaaS usage is an identity governance problem because unapproved apps create unmanaged access paths to corporate data and systems.
• The scale of exposure is already material, with third-party access and poor secret handling making delegated trust chains hard to see and harder to revoke.
• The response is not just discovery but lifecycle control, including ownership, permission review, integration offboarding, and compliance mapping.

Key terms

• Shadow IT: Shadow IT is software or cloud services used without formal approval, visibility, or governance from the security team. In identity terms, it matters because the application can still carry credentials, access scopes, and data-sharing relationships that outlive the original business need.
• SaaS discovery: SaaS discovery is the process of identifying every cloud application used in an organisation, including sanctioned and unsanctioned tools. Effective discovery ties usage back to owners, identities, integrations, and data flows so security teams can assess risk and enforce policy.
• Delegated access: Delegated access is permission granted to one system or app to act on behalf of a user or another system. In SaaS environments, it often creates non-human access paths that must be reviewed like privileged identities because the connection can persist and widen exposure.
• Identity surface: Identity surface is the full set of accounts, credentials, tokens, integrations, and trust relationships that can access a system or data set. For SaaS governance, the surface expands every time a new app connects to identity providers or shared data sources.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Uncovering the Hidden Risks of SaaS in Your Organization. Read the original.