SaaS vendor risk demands continuous monitoring, not onboarding checks

At a glance

What this is: This is a vendor risk management article arguing that SaaS security depends on continuous monitoring, not just onboarding checks, with particular emphasis on compliance, offboarding, and shadow IT.

Why it matters: It matters because SaaS sprawl creates identity, access, and data exposure across human, NHI, and lifecycle controls that IAM, IGA, and PAM teams must govern together.

By the numbers:

• A business with 250 employees uses close to 300 SaaS apps.
• GDPR fines can cost an organization up to 4% of its revenue.

👉 Read Zluri's analysis of SaaS vendor risk, offboarding, and shadow IT

Context

SaaS vendor risk becomes an identity governance problem when organisations no longer know which apps, accounts, and data paths remain active after onboarding. The issue is not only procurement discipline. It is the absence of continuous visibility into who can still access what, which vendor relationships have changed, and where compliance obligations now sit across the environment.

For IAM, IGA, and PAM teams, the practical challenge is lifecycle control across third parties and the identities they introduce. The article frames vendor monitoring, offboarding, renewal management, and shadow IT detection as the controls that keep SaaS sprawl from turning into security and compliance drift.

That lens maps directly to the broader NHI problem space. Where service accounts, API keys, and SaaS-connected identities persist beyond their intended use, the same governance failure appears: access outlives accountability and ownership becomes unclear.

Key questions

Q: How should security teams govern SaaS vendors beyond the onboarding phase?

A: Security teams should treat SaaS governance as a continuous lifecycle process. That means maintaining a live inventory, reviewing access and data flows regularly, and tying renewals to actual usage and business risk. Onboarding approval alone does not protect against shadow IT, stale entitlements, or vendor changes that alter the security posture.

Q: Why do SaaS vendors create compliance risk for IAM and IGA teams?

A: SaaS vendors create compliance risk because they can introduce new access paths, data handling obligations, and retention issues outside the original approval decision. When those relationships are not continuously monitored, organisations lose visibility into who still has access, which data is exposed, and whether the vendor relationship still matches policy.

Q: What breaks when SaaS offboarding only removes SSO access?

A: Partial offboarding leaves residual risk because application-level permissions, active sessions, and data custody may still persist. A user can appear removed from the identity provider while remaining reachable in the application or through transferred data paths. Effective offboarding must verify that access is removed everywhere it exists.

Q: Who is accountable when shadow IT causes a security or compliance issue?

A: Accountability usually sits with the business owner, procurement, and security governance functions together, because shadow IT is both a control failure and a visibility failure. If the organisation cannot identify the app, assign ownership, and document data handling, then accountability was never fully established in the first place.

Technical breakdown

Why continuous SaaS monitoring matters for identity governance

SaaS risk is dynamic because vendor exposure changes after onboarding, not just at purchase time. New integrations, unused subscriptions, shadow IT, and changing business dependencies can all create access paths that were never visible in the initial approval process. In identity terms, the control problem is not simply whether an app was approved. It is whether the organisation can still see, validate, and justify every active relationship that app creates across users, data, and linked services.

Practical implication: build continuous vendor and application inventory reviews into identity governance, not just procurement workflows.

Secure offboarding for SaaS accounts and application access

Offboarding is a lifecycle control, not an administrative cleanup step. When users leave or services are terminated, access must be removed from all authentication layers, not only the SSO layer, and data must be transferred or backed up before removal. The article’s example shows why partial revocation fails: an account can remain usable if only one control plane is changed. This is the same failure mode that appears in broader NHI governance when credentials, tokens, or app-level permissions outlive the business need.

Practical implication: treat SaaS offboarding as a multi-step revocation process that includes authentication, application access, and data custody.

Shadow IT, SaaS sprawl, and the hidden access surface

Shadow IT expands the identity surface because employees can create new software relationships outside central oversight. Once those tools become part of team workflows, they can carry data, permissions, and business processes that the security team cannot reliably see. That makes the risk both operational and compliance-related. The governance issue is not the presence of cloud apps alone. It is unmanaged adoption that bypasses review, monitoring, and renewal decisions, leaving the organisation with unowned access and uncontrolled data movement.

Practical implication: detect unmanaged SaaS usage early and tie it to access reviews, renewal decisions, and data handling controls.

Threat narrative

Attacker objective: The objective is to exploit unmanaged vendor and SaaS dependencies so access, data, or business continuity fail before the organisation can intervene.

1. Entry occurs when employees adopt SaaS tools or third-party vendors that are not fully visible to IT and security teams, creating unmanaged access paths and data flows.
2. Escalation happens when those tools retain active access, stale subscriptions, or incomplete offboarding, allowing permissions and data exposure to persist beyond the business need.
3. Impact is realised through compliance failure, data leakage, operational disruption, and avoidable financial loss when vendor risk is not continuously monitored.

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

Continuous SaaS visibility is not a procurement feature, it is a governance requirement. Once employees can create, renew, and embed third-party tools into business workflows faster than security can review them, the identity surface expands outside formal control. The article correctly points to monitoring, but the deeper issue is that static approval models cannot keep up with live vendor relationships. Practitioners should treat SaaS inventory as an identity control plane, not a spreadsheet.

Vendor offboarding is a lifecycle failure when access removal is partial. The article’s deprovisioning example shows the real risk: revoking SSO alone does not guarantee that application access, device sessions, or retained data paths are gone. That is the same governance pattern seen in broader NHI environments, where access outlives business need. The practitioner conclusion is that offboarding must be verified at every control layer.

Shadow IT is the human-side mirror of unmanaged NHI sprawl. Employees adopt tools outside policy, then those tools accumulate access, data, and workflow dependency without proper ownership. That is how governance gaps become durable. A named concept here is identity shadow surface: the set of SaaS apps, linked accounts, and delegated accesses that exist outside approved visibility. Teams need to govern it as part of access and compliance management.

Compliance risk and identity risk are converging in SaaS ecosystems. The article frames fines and penalties, but from an identity perspective the more important point is that regulatory exposure often begins with stale access and missing lifecycle controls. NIST CSF and zero trust thinking both assume assets, access, and trust relationships are continuously known. When SaaS vendors are not continuously monitored, that assumption breaks. Practitioners should align SaaS oversight with identity governance rather than treat it as separate vendor management.

Financial and operational risk are downstream symptoms of access governance failure. The article’s examples of cost overruns, service disruption, and renewal mistakes all trace back to the same root issue: organisations cannot govern what they cannot see. That makes renewal control, entitlement review, and third-party inventory part of the same security problem. The field should stop separating SaaS risk from identity risk and start managing both as one lifecycle discipline.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why continuous discovery matters before access drift becomes exposure.
• That visibility gap is one reason to review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that sit beneath SaaS governance.

What this signals

SaaS vendor governance is converging with identity governance because the practical control problem is the same: you cannot secure access you cannot inventory. The organisations that will reduce risk fastest are the ones that connect procurement, access review, and offboarding into one operating model rather than three separate queues.

Identity shadow surface: as SaaS sprawl grows, unmanaged tools become part of the identity perimeter even when they never appear in formal architecture diagrams. That changes the programme requirement from periodic review to continuous discovery, especially where regulated data or external sharing is involved.

For teams building against NIST Cybersecurity Framework 2.0, the signal is clear. Governance and inventory functions need to include SaaS applications, third-party access, and lifecycle enforcement, because the trust relationship is now part of the asset surface as much as the account surface.

For practitioners

• Build continuous SaaS inventory governance Maintain a live record of approved apps, linked accounts, and vendor dependencies so renewal, risk, and access decisions reflect current reality rather than onboarding history.
• Verify offboarding across all access layers Remove SaaS access from SSO, application-level permissions, active sessions, and associated data custody in one controlled workflow before closing the vendor relationship.
• Tie shadow IT discovery to access review Route unmanaged app discovery into recurring access reviews and procurement checks so hidden SaaS use cannot accumulate as ungoverned business access.
• Separate renewal approval from contract renewal dates Use usage, business criticality, and data exposure to decide whether a SaaS relationship should continue, rather than treating the renewal date as the only control point.
• Map third-party tools to data handling obligations Classify which SaaS apps handle regulated or sensitive data, then assign monitoring and ownership so compliance obligations are owned before an incident or audit forces the issue.

Key takeaways

• SaaS risk becomes a governance failure when organisations rely on onboarding checks instead of continuous visibility and lifecycle control.
• The biggest exposure comes from partial offboarding, shadow IT, and renewals that are disconnected from actual usage and business risk.
• Teams should manage SaaS vendors as part of identity governance, with inventory, access review, and verification built into one control loop.

Key terms

• SaaS vendor risk: The exposure created when third-party software providers handle data, access, or workflows that affect an organisation’s security and compliance posture. In practice, the risk comes from changing dependencies, hidden integrations, and lifecycle failures that can outlive the original approval decision.
• Shadow IT: Software or cloud services adopted outside formal IT approval and monitoring. Shadow IT creates blind spots in identity governance because the organisation may not know which users, data paths, or access grants exist until a problem forces discovery.
• Offboarding: The controlled removal of access, data paths, and operational dependence when a user, tool, or vendor relationship ends. In identity programmes, offboarding is only complete when the application, session, and data custody layers have all been verified as closed.

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 Mitigate SaaS Vendor Risks with Zluri. Read the original.