Shadow IT in SaaS creates security, compliance, and cost risk

At a glance

What this is: This is an analysis of how unsanctioned SaaS apps create security, compliance, and financial risk by bypassing identity and governance controls.

Why it matters: It matters because IAM, IGA, and security teams need visibility into every app and account that can store or move business data, including shadow SaaS.

👉 Read Zluri's analysis of security, compliance, and financial risks from shadow SaaS

Context

Shadow IT in SaaS is a governance problem before it is a technology problem. When employees adopt unsanctioned collaboration, storage, or workflow tools, the organisation loses the ability to enforce identity controls, monitor data flows, and recover accounts when people leave. That creates a direct IAM and IGA blind spot, because access exists outside the processes meant to govern it.

The article’s core point is that unmanaged SaaS usage undermines security, compliance, and budget control at the same time. For identity teams, the practical issue is not just whether an app is approved, but whether accounts, permissions, data locations, and offboarding are visible enough to govern. This is a lifecycle failure, not just an application procurement issue.

Key questions

Q: What breaks when employees use shadow SaaS for business data?

A: Shadow SaaS breaks governance because IT cannot reliably see the account, classify the data, or enforce permission limits. That means access reviews, audit evidence, and offboarding can all fail at the same time. The result is unmanaged exposure, not just a policy violation, and the risk persists until the app or data is discovered.

Q: Why do shadow apps create both compliance and security risk?

A: Shadow apps move sensitive data into unknown systems where retention, residency, logging, and access rules are hard to prove. The same blind spot that creates a data breach risk also creates a compliance failure, because regulators care about evidence of control. If the app is invisible, both security and audit assurance weaken.

Q: How do organisations know whether shadow SaaS is actually under control?

A: They should be able to show a current inventory of SaaS apps, the identities using them, the data they hold, and the owner responsible for offboarding and renewal. If any of those four elements is missing, the programme still has blind spots. Control exists only when discovery, ownership, and lifecycle actions are connected.

Q: Who is accountable when a shadow app leaks data or loses access after termination?

A: Accountability should sit with the business owner, the application owner, and the identity governance function together, because shadow SaaS failures cross procurement, access, and offboarding boundaries. If no single team owns those controls, the organisation will repeat the same failure at renewal, departure, or audit time.

Technical breakdown

Why shadow SaaS breaks identity governance

Shadow SaaS breaks governance because it creates identities and entitlements outside central control. A user can create a cloud account, store business data, share it externally, and keep using it without IT seeing the access path. That means recertification, offboarding, and privilege review may never touch the account. The security impact is broader than SaaS sprawl: it is fragmented identity ownership, inconsistent permission boundaries, and no reliable audit trail across business-owned apps.

Practical implication: build discovery and review processes that surface unsanctioned SaaS accounts before they become blind spots.

How shadow apps create data leakage and compliance exposure

Shadow apps increase leakage risk because sensitive files can move into unknown storage locations, then be shared through unmanaged links or third-party vendor access. Once that happens, compliance obligations such as retention, residency, and access logging become difficult to prove. The article also highlights a common failure mode: vendors or collaborators receiving edit access when view access would have been sufficient, which is a basic least-privilege violation with audit consequences.

Practical implication: tie app approval to data classification and permission review, not just procurement approval.

Why hidden SaaS drives cost and operational sprawl

Hidden SaaS creates duplicate subscriptions, broken collaboration, and poor supportability. Different teams adopt different tools for the same work, so data fragments across systems and IT loses the ability to troubleshoot, recover, or standardise usage. The financial issue is not just overspending. It is the accumulation of unmanaged renewals, redundant platforms, and business processes that cannot be sustained when a shadow tool fails or a staff member departs.

Practical implication: connect SaaS inventory to renewal control, help desk intake, and offboarding workflows.

Threat narrative

Attacker objective: The attacker or risk event ultimately gains access to sensitive business data or an unmanaged account path that the organisation cannot govern reliably.

1. Entry occurs when an employee signs up for an unsanctioned SaaS app or shares business data into a personal cloud account without IT oversight.
2. Escalation follows when the app stores credentials, exposes shared content, or grants third-party collaborators broader access than intended.
3. Impact arrives as data leakage, audit failure, account loss after termination, or duplicate SaaS spend that weakens operational control.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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, not just an application sprawl problem. The article shows that once employees create business-critical access paths outside sanctioned processes, lifecycle control becomes partial at best. Access reviews cannot certify what they cannot see, and offboarding cannot revoke what it does not inventory. The practitioner implication is that SaaS discovery must be treated as a governance control, not an inventory convenience.

Least privilege collapses when app adoption outruns permission design. The article’s strongest compliance point is that external vendors and collaborators may receive edit access where view access would have been sufficient. That is a direct violation of access minimisation, not a minor configuration issue. The implication is that permission boundaries must be assessed at the data-sharing layer, not only at procurement or SSO setup.

Lifecycle ownership is the missing control in shadow IT environments. The article repeatedly points to the risk of employees leaving, subscriptions lapsing, and data becoming unrecoverable. Those are not isolated operational failures. They show that no one owns joiner, mover, and leaver management for shadow SaaS. The practitioner implication is that app lifecycle must be bound to identity lifecycle, or the business will keep losing control at termination.

Compliance failure starts when data moves into unknown places. HIPAA, GDPR, PCI DSS, ISO 27001, and SOC 2 all depend on knowing where data lives and who can access it. Shadow apps break that chain of evidence by design. The implication for security leaders is that compliance assurance now depends on continuous visibility into SaaS usage, not annual review cycles.

Financial waste and security waste are the same shadow IT symptom. Redundant tools, lapsed renewals, and fragmented collaboration are usually treated as budget issues, but they are also identity issues because unmanaged accounts and data paths remain active without control. The implication is that procurement, IAM, and security operations need one shared control plane for SaaS adoption and retirement.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which underscores how quickly hidden access paths outpace governance.
• For practitioners building a broader control model, the Ultimate Guide to NHIs is the natural next step for lifecycle, rotation, and offboarding detail.

What this signals

Shadow SaaS is a preview of where identity governance is weakest. Once users can create business access paths outside approved workflows, the problem stops being isolated to procurement and becomes a control design issue. Teams that already struggle with SaaS visibility should treat discovery, ownership, and offboarding as one governance process, not three separate ones.

The most durable programmes will connect app intake to lifecycle control and data classification at the same time. That means treating unknown storage locations, unmanaged sharing, and abandoned subscriptions as identity events, not just IT hygiene issues.

The governance signal is clear: if your organisation cannot explain who owns an app, who can access the data, and what happens at termination, then the control plane is incomplete. The 52 NHI Breaches Analysis is useful here because it shows how quickly unmanaged identities become breach pathways.

For practitioners

• Map all SaaS identities and data paths Discover unsanctioned apps, tie them to user identities, and identify where business data is stored or shared outside approved systems.
• Bind app approval to access scope Require view-versus-edit permission review, third-party sharing review, and data classification checks before an app is approved for business use.
• Link offboarding to shadow app recovery Check departure workflows for personal cloud storage, external sharing links, and business content living in user-owned accounts.
• Connect renewal control to SaaS inventory Use the same system that tracks approved applications to catch redundant subscriptions, lapsed renewals, and tools purchased outside IT.

Key takeaways

• Shadow SaaS turns ordinary application choice into an identity governance problem because accounts, permissions, and data move outside central control.
• The article shows that compliance, security, and cost failures share the same root cause: unmanaged access paths that IT cannot see or revoke.
• Practitioners need one lifecycle model for approved and shadow SaaS, or discovery, offboarding, and renewal will keep failing in different ways.

Key terms

• Shadow SaaS: Shadow SaaS is software used for business work without full IT visibility or approval. In identity terms, it creates accounts, permissions, and data paths that sit outside normal governance, which makes lifecycle control, auditability, and revocation much harder than in sanctioned systems.
• SaaS lifecycle governance: SaaS lifecycle governance is the set of controls that track software from request to retirement. It links ownership, access, renewal, and offboarding so that applications do not become long-lived blind spots. In practice, it is the control layer that shadow IT often bypasses.
• Least privilege: Least privilege means granting only the access needed for a specific task or business role. For SaaS, this includes limiting sharing rights, external collaboration, and administrative permissions. When users receive broader edit access than necessary, the organisation increases both breach exposure and audit risk.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Shadow IT Risks. Read the original.