SaaS management platform selection exposes identity governance gaps

At a glance

What this is: This is a SaaS management selection guide that argues discovery, automation, risk scoring, and offboarding determine whether the platform can actually govern SaaS access and sprawl.

Why it matters: It matters because SaaS management decisions increasingly shape identity visibility, lifecycle control, and access risk for human, NHI, and delegated third-party identities.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's guide to SaaS management platform selection mistakes

Context

SaaS management platforms sit at the intersection of application inventory, access governance, and lifecycle control. When discovery is weak or automation is partial, organisations end up managing SaaS sprawl with incomplete visibility, manual reviews, and inconsistent revocation across users and service-style identities.

The primary IAM issue is not just finding apps. It is whether the platform can expose who and what has access, keep that access aligned to business need, and support offboarding when identities or vendors change. That makes SaaS management a governance control, not just an operational dashboard.

Key questions

Q: How should teams evaluate SaaS management platforms for identity governance?

A: Teams should evaluate whether the platform can discover all apps, connect that inventory to authoritative identity data, and support reliable lifecycle actions. The test is not interface quality. It is whether the platform can expose access paths, trigger revocation when people or vendors change, and distinguish low-risk usage from high-blast-radius permissions.

Q: Why do SaaS platforms need offboarding workflows, not just app inventory?

A: Because inventory alone does not remove access. A SaaS platform becomes a governance control only when it can revoke user, admin, and delegated app access as part of offboarding or ownership change. Without that, organisations keep paying for unused access while leaving stale permissions in place.

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

A: They often treat the score as the answer instead of the starting point. A useful score should be unpacked into permissions, data sensitivity, compliance posture, and third-party exposure. If the model cannot explain why an app is risky, it is not helping the governance decision.

Q: How do organisations reduce SaaS sprawl without creating more manual work?

A: They should automate onboarding, approvals, and revocation around authoritative sources of truth, then use that automation to clean up dormant apps and duplicate licenses. The goal is not more workflow steps. It is fewer handoffs, fewer exceptions, and faster removal of access that no longer has a business purpose.

Technical breakdown

Discovery engines and the identity blind spot

A discovery engine is the control layer that identifies SaaS applications, connected accounts, and access relationships from multiple telemetry sources. Without continuous discovery, security teams only see the tools they already know about, which leaves shadow apps, stale entitlements, and unmanaged delegated access outside governance. In practice, discovery quality determines whether the platform can support inventory, risk ranking, and review workflows. If discovery is shallow, every downstream workflow starts from incomplete data and the programme inherits that blind spot.

Practical implication: validate whether discovery can surface hidden apps, connected identities, and stale access before using the platform for governance.

Automation for onboarding, offboarding, and approvals

Automation in SaaS management is not just convenience. It is the mechanism that turns lifecycle policy into repeatable access changes across joiner, mover, and leaver events. Manual provisioning and deprovisioning creates delay, inconsistency, and forgotten access, especially when multiple departments own app usage. Automated approvals and playbooks reduce dependency on ticket-driven follow-up, but only if they are tied to authoritative identity and app data. Otherwise, the platform automates noise instead of governance.

Practical implication: tie onboarding, offboarding, and approval workflows to authoritative identity sources and test that revocation happens without manual chase.

Risk scoring, compliance, and SaaS access governance

Risk scoring is useful only when it reflects actual exposure such as app sensitivity, privilege level, compliance posture, and known security signals. A SaaS platform that scores apps without explaining why can mislead teams into treating the score as a control rather than a decision aid. Governance teams need to know whether the scoring model accounts for read, modify, and delete permissions, third-party exposure, and the sensitivity of the data the app can reach. That is what turns scoring into prioritisation.

Practical implication: use SaaS risk scores as triage input, then verify permissions, data access, and third-party exposure before accepting the ranking.

Threat narrative

Attacker objective: The objective is to exploit weak SaaS governance to retain or expand access beyond intended business need and use that access to reach sensitive systems or data.

1. Entry occurs when SaaS apps are adopted faster than the organisation can discover and classify them, creating ungoverned access paths and shadow usage.
2. Escalation follows when unused licenses, overbroad permissions, or missing offboarding controls preserve access after role changes or vendor transitions.
3. Impact is broader SaaS sprawl, avoidable exposure of sensitive data, and inconsistent compliance enforcement across the application estate.

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

Discovery debt is the first governance failure in SaaS management. When the platform cannot reliably find every app, connected account, and access path, the organisation is not managing SaaS at all. It is managing a partial inventory and calling it control. That blind spot weakens access reviews, obscures privilege creep, and makes lifecycle decisions structurally incomplete. Practitioners should treat discovery quality as the prerequisite for every other governance function.

Automation failure is usually lifecycle failure in disguise. Manual onboarding and offboarding may look operational, but the real issue is that access changes are not happening fast enough to match business movement. That creates standing access, delayed revocation, and inconsistent approvals across departments. In an NHI context, the same failure mode appears when service-style identities are not revoked or rotated on schedule. The practitioner implication is to view lifecycle orchestration as a control boundary, not a workflow convenience.

Risk scoring without privilege context creates false confidence. A score that does not distinguish read access from modify or delete access misses the actual blast radius of an app. The same is true for third-party access, where vendor-managed connections can hide broad downstream reach. This is where SaaS management intersects with NHI governance and zero trust thinking. Practitioners should insist that scoring models explain the permissions and data paths behind the number, not just the number itself.

Vendor and app governance now overlap with identity governance. SaaS procurement decisions shape who can access what, for how long, and through which delegated path. That means IT, finance, procurement, and security are all governing identity outcomes even when they think they are evaluating software. The field should stop treating SaaS management as a separate category from IAM, because lifecycle, access, and review controls are the same discipline applied to a different asset surface. Practitioners should align procurement, access, and offboarding into one governance model.

Identity blast radius is the right concept for SaaS sprawl. The issue is not how many apps exist, but how far a single stale entitlement, mis-scoped approval, or unrevoked connection can extend. Once access is distributed across departments and linked applications, the blast radius grows faster than any manual review cycle can contain. Practitioners should use blast radius as the lens for prioritising app reviews, offboarding, and permission cleanup.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For the lifecycle angle, see NHI Lifecycle Management Guide for offboarding, rotation, and visibility controls that reduce identity drift.

What this signals

Identity drift is the operating risk that SaaS management products now inherit. When discovery, offboarding, and approvals are fragmented, the programme accumulates stale access faster than human review cycles can clear it. That makes lifecycle orchestration a board-relevant governance issue, not a tool-selection detail.

Because only 5.7% of organisations have full visibility into their service accounts, visibility gaps are already the norm in identity programmes. SaaS governance should be designed to close that gap across both human and non-human access paths, not assume a clean inventory from the start.

The next maturity step is to connect procurement, access review, and revocation into one control chain. A platform that cannot show where access came from, who owns it, and how it will be removed will not support zero-trust operating assumptions.

For practitioners

• Map discovery coverage to actual app and identity sources Test whether the SaaS platform can enumerate all sanctioned apps, shadow apps, connected accounts, and delegated access from HR, SSO, finance, and endpoint data. Do not accept a dashboard that cannot show where its inventory came from.
• Tie offboarding to authoritative identity events Require revocation workflows to trigger from joiner-mover-leaver changes, vendor terminations, and app ownership changes. Confirm that revoked access includes SSO links, API connections, and any lingering app permissions, not just user logins.
• Separate privilege severity from simple app counts Review whether the platform distinguishes read-only access from modify and delete permissions, and whether it flags third-party exposure. Prioritise cleanup where access can alter data or extend into downstream systems.
• Use risk scores as a triage layer, not a control Validate each high-risk app score against actual permissions, compliance requirements, and data sensitivity before acting. Scores should accelerate decisions, but they should not replace a permission review or an ownership check.

Key takeaways

• SaaS management is an identity governance problem when discovery, ownership, and offboarding are incomplete.
• Risk scoring is only useful when it explains privilege, data access, and third-party reach.
• Practitioners should judge SaaS platforms by whether they can remove stale access as reliably as they surface it.

Key terms

• Discovery engine: A discovery engine is the mechanism a SaaS management platform uses to find applications, connected accounts, and access relationships across multiple data sources. Its value is measured by completeness and freshness, because incomplete discovery leaves shadow apps and stale access outside governance.
• Identity blast radius: Identity blast radius is the amount of damage one access path can create if it is mis-scoped, stale, or abused. In SaaS environments it grows through delegated access, shared ownership, and connected apps, making cleanup and offboarding a control priority rather than an administrative task.
• Lifecycle orchestration: Lifecycle orchestration is the coordinated automation of joiner, mover, and leaver actions across apps, owners, and approvals. In SaaS governance it ensures access changes happen at the same speed as business movement, reducing manual error and lingering permissions.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: SaaS Management Top 8 Mistakes to Avoid while Choosing a SaaS Management Platform. Read the original.