What should organisations review first when SaaS sprawl is getting out of control?

Start with the applications that have active logins but unclear ownership or low utilisation. Those are usually the fastest path to risk reduction because they often expose unmanaged access, redundant contracts, and stale entitlements at the same time.

Why This Matters for Security Teams

saas sprawl is rarely just a procurement problem. It becomes a security and governance issue when applications accumulate without clear ownership, when former pilot tools quietly retain logins, and when low-use services continue to hold active entitlements. That combination creates redundant spend, but more importantly it expands the number of places where secrets, tokens, and delegated access can be abused. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Key Challenges and Risks, which is a useful warning sign for the broader identity sprawl problem.

The first review should therefore focus on applications that can still authenticate but no longer have a clearly accountable business owner. Those are the systems most likely to hide stale access paths, orphaned integrations, and duplicate contracts. The security team’s goal is not simply to cut tool count, but to find where governance has drifted away from reality. NIST Cybersecurity Framework 2.0 treats asset and access visibility as a baseline capability for managing risk. In practice, many security teams discover the true extent of SaaS sprawl only after a vendor renewal, a breach review, or a failed offboarding event has already exposed the gap.

How It Works in Practice

A workable first pass starts by building a list of applications with active sign-ins, API connections, and SSO or SCIM provisioning, then sorting that list by ownership clarity and utilisation. Apps with active logins but no named business owner should be reviewed before higher-profile tools, because they are the easiest to leave behind during reorganisations and the hardest to govern later.

A practical review usually includes:

• Confirm who approved the app, who receives alerts, and who can disable access.
• Check whether the app is tied to SSO, local credentials, shared accounts, or third-party OAuth grants.
• Identify dormant users, stale roles, and service integrations that outlive the original use case.
• Compare licence count, login frequency, and data sensitivity to determine whether the app is essential or merely persistent.

This is where NHI governance and SaaS governance overlap. If an application relies on API keys, tokens, or service accounts, review those non-human identities alongside the app itself. The same pattern appears in incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach, where access persisted beyond the point of operational need. The highest-value review is the one that finds an application still trusted by the business, but no longer trusted by the organisation. These controls tend to break down when SaaS ownership is split across IT, procurement, and business units because no single team can confidently revoke access or retire the service.

Common Variations and Edge Cases

Tighter SaaS review cycles often increase administrative overhead, so organisations have to balance speed of cleanup against the risk of disrupting legitimate workflows. Current guidance suggests prioritising by risk, not by volume, because a low-use app can still be a critical pathway into data or identity systems.

The usual edge cases are the ones that look harmless at first:

• Finance, HR, and sales tools that integrate deeply with directory services or exports.
• Legacy apps with low login counts but permanent admin tokens.
• Department-owned SaaS purchased outside central procurement, where ownership records are incomplete.
• Vendor-managed portals where access is delegated, but revocation depends on manual ticketing.

There is no universal standard for SaaS sprawl cleanup, but best practice is evolving toward continuous ownership attestation, not annual spreadsheet reviews. That means naming a system owner, verifying actual usage, and setting a retirement path for apps that no longer justify their access footprint. For organisations trying to sequence the work, the most practical next step is to remove unclear ownership before chasing low utilisation alone, because usage data without accountability does not reduce risk on its own. The Ultimate Guide to NHIs — Standards is a useful reference point for aligning identity control expectations with that cleanup effort.

Related resources from NHI Mgmt Group

• How can organisations tell whether identity sprawl is getting out of control?
• Should organisations prioritise external exposure or internal credential governance first?
• How can organisations decide which NHIs to remediate first?
• Should organisations treat Skills as a new class of non-human identity control?