By NHI Mgmt Group Editorial TeamPublished 2025-06-26Domain: Governance & RiskSource: Zluri

TL;DR: SaaS management fails when organisations rely on spreadsheets, weak visibility, and inconsistent lifecycle controls for apps, users, groups, and vendors, leaving security and compliance gaps across the stack, according to Zluri. The deeper issue is that SaaS governance is really identity governance across human access, privileged accounts, and third-party exposure, not a procurement list.


At a glance

What this is: This is a SaaS governance article that frames visibility, lifecycle, access, and vendor risk as core controls for safer SaaS operations.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly have to govern SaaS entitlements, third-party access, and shadow IT as identity problems, not just application administration.

By the numbers:

👉 Read Zluri's SaaS management policies for visibility, lifecycle, and vendor risk


Context

SaaS management is really an identity governance problem once an organisation moves beyond simple licence tracking. The article’s central point is that spreadsheets, partial discovery, and inconsistent offboarding leave teams unable to answer a basic question: who and what can access SaaS data right now?

That gap matters across human access, service accounts, and third-party integrations because SaaS platforms often become the operational layer where permissions, data sharing, and vendor connectivity converge. For IAM, IGA, and PAM teams, the control failure is not just lack of inventory. It is lack of lifecycle discipline across the full SaaS identity surface.


Key questions

Q: How should teams govern SaaS access when employees change roles or leave?

A: Treat SaaS access as part of the identity lifecycle, not as a separate application task. Role changes should trigger permission review, and departures should trigger immediate licence revocation or transfer. The goal is to prevent dormant access, reduce over-privilege, and keep app entitlements aligned with current business need.

Q: Why do SaaS portfolios create so much hidden identity risk?

A: Because SaaS stacks grow faster than manual records can keep up with, especially when teams use spreadsheets and informal approvals. Hidden risk appears in unmanaged apps, external collaborators, orphaned groups, and stale permissions. The practical answer is continuous discovery paired with ownership and lifecycle controls.

Q: What do security teams get wrong about SaaS vendor risk?

A: They often treat vendor compliance as a procurement check instead of an ongoing governance issue. SaaS posture can change after onboarding, and new apps can be added without review. Security teams need continuous visibility into approved vendors, certification status, and unsanctioned subscriptions.

Q: How do organisations reduce SaaS risk without slowing business users down?

A: Use policy-driven guardrails that automate discovery, access review, offboarding, and group cleanup. That gives business users faster onboarding and better collaboration while keeping entitlements current. The balance comes from making identity controls operational, not manual.


Technical breakdown

SaaS discovery is an entitlement inventory problem

SaaS discovery is the process of finding every subscribed application, integration, and active user relationship across the environment. In practice, that means building a live inventory rather than relying on spreadsheets that age the moment they are created. Without discovery, teams cannot reliably model ownership, risk, or renewal impact because the SaaS stack is not a fixed asset list. It is a changing identity surface with hidden access paths, duplicate subscriptions, and unmanaged tools that create governance blind spots.

Practical implication: maintain a continuously updated SaaS inventory tied to owners, users, and access paths, not a static licence register.

User lifecycle controls determine whether SaaS access remains governed

User lifecycle management in SaaS covers joiners, movers, and leavers, including role changes, permission adjustments, training, and revocation. The important detail is that the same application can hold very different risk depending on whether access is temporary, role-based, or left behind after an employee exits. When revocation is delayed or incomplete, the application becomes a standing-access problem. That is why SaaS lifecycle work sits in the same governance family as access reviews and offboarding, even though the subject is software rather than a directory group.

Practical implication: connect SaaS offboarding and entitlement updates directly to HR and identity workflows so access is removed when the role changes.

Vendor and group governance expand the SaaS attack surface

The article also highlights vendor risk, group sprawl, and external sharing as governance issues, not just operational conveniences. SaaS groups can accumulate abandoned or overbroad membership, while external collaborators and vendors introduce access that often outlives the original business need. This is where SaaS management overlaps with PAM, third-party access governance, and data-sharing policy. If the organisation cannot review who sits in a group, who received external access, and which SaaS vendors remain trusted, it cannot claim effective control over the data they can reach.

Practical implication: apply review and recertification to SaaS groups and external access with the same discipline used for privileged and third-party accounts.



NHI Mgmt Group analysis

Spreadsheets are a symptom of governance failure, not just a tooling gap. Once SaaS portfolios span dozens or hundreds of applications, a static register cannot capture live ownership, access changes, or abandoned subscriptions. That means the organisation is making control decisions on stale data, which is how shadow IT and renewal waste become security exposure. The practitioner conclusion is simple: if the inventory is not live, the governance model is already behind.

SaaS lifecycle management is identity lifecycle management in another form. The article treats joiners, movers, leavers, and permission changes as a SaaS operations problem, but the underlying discipline is lifecycle control across identities and entitlements. This aligns directly with NIST CSF access governance and the broader lifecycle logic used in IAM programmes. The implication is that SaaS offboarding, role changes, and licence transfers should be governed through the same process owners as identity certification and deprovisioning.

External sharing creates third-party identity risk even when the app is not framed as NHI infrastructure. Consultants, partners, and outsourced workers are still identity subjects with scoped access, and SaaS is often where that access becomes difficult to track. The article’s logic shows why least privilege is not enough if external access is never reviewed or removed. The practitioner conclusion is to treat SaaS collaboration links, guest users, and vendor access as governed identities, not informal business exceptions.

Vendor trust in SaaS must be validated continuously, not assumed at procurement time. The article’s security and compliance policy section correctly identifies the common failure mode: teams assume the SaaS vendor already meets the organisation’s standards. That assumption breaks when apps are added without IT approval or when vendor security posture changes after onboarding. The implication is that SaaS governance needs an ongoing trust model, with compliance and certification checks tied to the application lifecycle.

Abandoned groups and overbroad permissions are the hidden persistence layer of SaaS risk. Group-based access can simplify collaboration, but it also creates a durable entitlement structure that survives project changes and staffing churn. When those groups are not reviewed, they become a permanent access path. The practitioner conclusion is that group governance in SaaS should be folded into access recertification, not managed as a separate administrative task.

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.
  • Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, according to the same research.
  • For broader lifecycle context, see NHI Lifecycle Management Guide for how discovery, rotation, and offboarding fit together.

What this signals

SaaS management will keep converging with identity governance. As more business processes move into SaaS, the control plane shifts from procurement lists to entitlements, groups, and external access. Teams that still treat SaaS as an application admin function will miss the governance issues that live in lifecycle and third-party relationships.

Third-party connectivity is the pressure point that will keep expanding. OAuth-connected apps, guest users, and partner access create the same oversight problems seen in other identity domains, which is why discovery and recertification need to become continuous rather than periodic. For a broader control baseline, the 52 NHI Breaches Analysis is a useful lens on how unmanaged identity paths persist into incident patterns.

Spreadsheets are becoming a liability signal. Once the organisation cannot answer who owns an app, who can access it, and which vendor relationships remain active, governance has already slipped. That is why SaaS operations should be measured against live ownership, revocation speed, and review coverage, not against the number of tools recorded.


For practitioners

  • Build a live SaaS inventory Replace spreadsheet-based tracking with a continuously updated inventory that records each application, owner, business purpose, and active user relationship.
  • Tie SaaS offboarding to identity workflows Connect employee exit events and role changes to licence revocation, permission updates, and subscription transfer so access does not outlive the business need.
  • Review external SaaS access on a schedule Apply access recertification to consultants, partners, and other external users, and remove access when the collaboration no longer requires it.
  • Govern SaaS groups as entitlements Identify abandoned, redundant, and empty groups, then validate membership and permission scope against current project and department needs.
  • Validate vendor compliance continuously Track vendor security certifications and policy status after onboarding, and flag new subscriptions that appear without IT approval.

Key takeaways

  • SaaS management becomes a governance problem when visibility, ownership, and revocation are handled manually.
  • Lifecycle control across users, groups, and external collaborators is the difference between orderly SaaS use and persistent access risk.
  • Continuous discovery and vendor review matter because SaaS trust changes after onboarding, not only at purchase time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4SaaS permissions and external access map directly to least-privilege governance.
OWASP Non-Human Identity Top 10NHI-03The article centres on credential and access lifecycle control across SaaS resources.
NIST Zero Trust (SP 800-207)Continuous verification is relevant where SaaS access and vendor trust change over time.

Inventory SaaS identities and enforce lifecycle actions for stale access, orphaned apps, and excess privilege.


Key terms

  • SaaS Discovery: SaaS discovery is the process of finding every application, integration, and user relationship that exists across a cloud software estate. It is the starting point for governance because you cannot control access, ownership, or risk if the application footprint is incomplete or stale.
  • SaaS User Lifecycle: SaaS user lifecycle is the set of identity events that govern access from joiner to mover to leaver. It includes provisioning, permission changes, training, and revocation, and it becomes a security control when it is connected to identity workflows rather than handled ad hoc by application owners.
  • Shadow IT: Shadow IT is software or service use that occurs outside approved governance and visibility channels. In SaaS environments it often appears as unsanctioned apps, unmanaged subscriptions, or hidden integrations that can access company data without the review, logging, or offboarding controls the organisation expects.
  • Third-Party Access: Third-party access is any external identity relationship that allows consultants, vendors, partners, or contractors to reach company systems or data. It needs the same lifecycle discipline as internal access because the risk comes from scope, duration, and revocation, not from whether the user is inside or outside the organisation.

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: SaaS Management 10 Policies to Ensure Reliable SaaS Management. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org