SaaS security demands proactive identity governance and visibility

At a glance

What this is: This is a SaaS security analysis arguing that modern application stacks need proactive identity governance, not reactive vendor reliance.

Why it matters: It matters because SaaS sprawl, third-party access, and orphaned subscriptions weaken control across human identities, NHIs, and delegated access paths.

By the numbers:

• By mid-2019, 4.1 billion records were left exposed, with more than 3,800 publicly disclosed breaches.
• 71% of businesses had orphaned SaaS subscriptions.
• 80% of survey respondents worldwide said biometric authentication can be effective for securing identity data, while adoption hovered around 22%.

👉 Read Zluri's analysis of proactive SaaS security and identity control

Context

SaaS security is an identity governance problem as much as an application security problem. When organisations hand control of business-critical data to cloud applications, they also inherit uncertainty around access, transparency, and lifecycle control, especially when identities are shared across employees, vendors, and third parties.

The central gap is not whether SaaS vendors provide baseline security, but whether internal teams can still see who has access, where data moves, and which subscriptions no longer belong in the environment. That is why SaaS security has to be treated as a governed identity surface, not as a set of isolated app settings.

Key questions

Q: How should security teams govern SaaS access across many business applications?

A: Security teams should govern SaaS access as a single identity surface rather than as separate app settings. That means maintaining an authoritative inventory, assigning ownership, reviewing third-party access, and linking every entitlement to a lifecycle event. Without that structure, orphaned access and hidden integrations will outlast the business need.

Q: Why do orphaned SaaS subscriptions create security risk?

A: Orphaned subscriptions create risk because they leave live access paths in place after the organisation has stopped using them. That produces unnecessary exposure, complicates offboarding, and can undermine compliance because security teams cannot prove that dormant access was actually removed.

Q: What do teams usually get wrong about third-party SaaS access?

A: Teams often focus on the app and ignore the identities behind the connection. In reality, tokens, service accounts, and delegated permissions are what move data, so governance must cover those identities directly. If ownership and review are missing, the trust boundary becomes invisible.

Q: How can organisations tell if SaaS governance is actually working?

A: SaaS governance is working when the app inventory is current, every external integration has a named owner, and offboarding removes access without manual chasing. If dormant subscriptions, unclear ownership, or unexplained data paths remain, the programme is measuring policy, not control.

Technical breakdown

SaaS identity sprawl and orphaned subscriptions

SaaS sprawl occurs when organisations accumulate apps faster than they can govern their access paths, contracts, and offboarding. Orphaned subscriptions are a symptom of that mismatch, where licences, accounts, or app instances remain active after the business need has ended. In practice, this creates hidden access points, weakens accountability, and makes it harder to know which identities still matter. The problem is not only cost waste. It is also a control failure because access reviews and deprovisioning cannot work reliably when the application inventory is incomplete.

Practical implication: build a complete SaaS inventory before you trust access reviews or offboarding workflows.

Third-party access and transparency gaps in SaaS

Many SaaS environments depend on third parties for integration, support, or data exchange, but that dependency often outpaces visibility. If teams cannot see which vendors, connectors, or federated identities can reach data, they cannot meaningfully enforce least privilege or monitor abnormal use. This is where SaaS governance intersects with NHI control, because APIs, service accounts, tokens, and delegated app access frequently become the real enforcement layer. Without clear ownership and logging, the trust boundary shifts outward and becomes harder to police.

Practical implication: map every third-party connector and delegated identity to an owner, purpose, and review cadence.

Why proactive SaaS security depends on continuous monitoring

A reactive model assumes the environment will stay stable long enough for periodic checks to catch problems. SaaS does not behave that way. Apps change fast, integrations expand quietly, and access drift accumulates between reviews. Continuous monitoring gives security teams a way to detect unnecessary access, suspicious sharing, and exposure that traditional point-in-time reviews miss. It also supports faster response when a vendor issue, user error, or credential problem affects multiple applications at once.

Practical implication: use continuous monitoring to detect access drift before it becomes a broad SaaS compromise.

Threat narrative

Attacker objective: The attacker aims to reach data or accounts through weakly governed SaaS access paths and then exploit the resulting visibility and control gaps.

1. Entry begins when organisations allow uncontrolled SaaS expansion, orphaned subscriptions, or weak identity hygiene to leave active access paths in place.
2. Escalation follows when users, vendors, or integrated services retain more access than they need, making data sharing and lateral movement easier across applications.
3. Impact arrives as exposed records, compliance failures, account takeovers, or broader loss of governance over where business data lives and who can reach it.

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

SaaS security is really identity governance for a distributed application surface. The article is right to frame SaaS as a place where control can be lost even when basic vendor security exists. Once data, users, vendors, and app integrations spread across the stack, the real issue becomes who owns access, reviews it, and removes it when business use ends. Practitioners should treat SaaS inventory and access governance as one discipline, not two separate problems.

Orphaned SaaS subscriptions are a lifecycle failure, not just a licensing problem. When unused subscriptions remain active, the organisation keeps a live access path that no longer has a business purpose. That is an access governance defect because the identity outlives the need. The implication is that joiner-mover-leaver processes must include SaaS entitlements and not stop at human account administration.

Third-party SaaS access creates an NHI-style trust problem even when the subject is a business application. APIs, tokens, delegated app permissions, and service accounts often carry the actual rights, not the human user interface. That means visibility into who or what can reach data matters more than the app brand itself. Practitioners should assume that the most consequential control point may be non-human identity, even in a SaaS-first environment.

Identity blast radius: the real security question is not whether one app is safe, but how far a single access failure can travel across the stack. The article's emphasis on cross-application visibility points to a broader governance reality: one weak subscription, connector, or credential can expose many systems at once. That is why SaaS governance must be measured by containment, not by individual app assurance. Practitioners should design for limited blast radius, not isolated compliance checkboxes.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why identity inventory and ownership matter before access reviews can be trusted.
• For a broader control baseline, NIST Cybersecurity Framework 2.0 remains the right anchor for govern, identify, protect, detect, respond, and recover planning.

What this signals

SaaS security programmes are converging with NHI governance because the most important trust relationships often sit behind the application layer. When tokens, delegated permissions, and service accounts are not mapped to owners, teams lose the ability to prove who can reach what, and that undermines both access reviews and incident response.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, hidden access remains the real operational risk in SaaS-heavy environments. The programme signal is clear: visibility must extend to the identities and credentials that make the stack function.

For practitioners

• Inventory every SaaS application and owner Create and maintain a complete app register that includes business owner, technical owner, data type, authentication method, and offboarding path. Use it to find orphaned subscriptions and close apps that no longer have an approved business purpose.
• Map third-party access paths to concrete identities Document every vendor integration, delegated permission, API token, and service account that can reach SaaS data. Assign each one an owner, a review date, and a revocation path so hidden access does not survive contract or business changes.
• Enforce continuous access review across the SaaS stack Do not rely on periodic spreadsheets or one-time approval records. Use monitoring to detect access drift, privilege creep, and dormant accounts so review teams can act on current evidence rather than stale entitlement lists.
• Tie SaaS controls to identity lifecycle events Trigger deprovisioning, credential revocation, and subscription cleanup when employees change roles, leave, or when vendors are offboarded. The goal is to remove access as soon as the business relationship no longer justifies it.

Key takeaways

• SaaS security fails when organisations treat vendor-managed applications as if internal identity governance no longer applies.
• Orphaned subscriptions, third-party integrations, and hidden credentials create the access paths that attackers and compliance failures exploit.
• Teams need continuous inventory, ownership, and lifecycle control to shrink blast radius across the SaaS estate.

Key terms

• Orphaned SaaS Subscription: A SaaS subscription that remains active even though the business need, owner, or user relationship has ended. These subscriptions keep licences, access paths, and sometimes data exposure alive, creating unnecessary security and compliance risk because nobody is actively accountable for them.
• Delegated SaaS Access: Access granted indirectly through an integration, token, service account, or third-party connection rather than through a person signing in directly. It matters because the actual security boundary is often the delegated identity, not the user interface that triggered it.
• Identity Blast Radius: The amount of damage a single identity, credential, or access path can create if it is abused or mismanaged. In SaaS environments, blast radius grows when one integration or account can reach multiple applications, datasets, or administrative functions without tight governance.

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: Miscellaneous Let’s talk about SaaS security and why you must be proactive. Read the original.