How can security teams tell whether a SaaS application is still worth keeping?

Why This Matters for Security Teams

Keeping a SaaS application is not just a procurement question. It is an identity and access question, a data exposure question, and often a hidden integration question. Dormant apps can still hold OAuth grants, API keys, service accounts, and admin roles long after the business value has faded. That means the real risk is not the license line item but the unresolved trust the app still has across the stack.

Current guidance from the NIST Cybersecurity Framework 2.0 supports treating asset governance as an ongoing control, not a one-time inventory task. NHIMG research shows why this matters in practice: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. When a SaaS app is kept alive without clear ownership, those identities often remain active even when no one can explain their purpose.

In practice, many security teams discover unnecessary SaaS risk only after an OAuth token, API key, or admin grant has already been used outside the original business need.

How It Works in Practice

The strongest way to judge whether a SaaS application is still worth keeping is to combine usage evidence, business ownership, and integration depth. License counts alone are weak signals because a lightly used app may still be central to a critical workflow, while a heavily licensed one may duplicate another platform and add little value. Security teams should start with three questions: who owns it, what depends on it, and what identities or secrets does it still control?

That means reviewing sign-in activity, workflow dependency, and the age and scope of connected integrations. If the app has not been used recently, has no current owner, and still holds privileged tokens or connectors, it is usually a retirement candidate or at least a renewal challenge candidate. This is especially important for SaaS tools that connect via OAuth, because the token can outlive the user who originally approved it. NHIMG research on the Salesloft OAuth token breach and BeyondTrust API key breach shows how credentials tied to SaaS integrations can become durable attack paths long after the original use case has weakened.

A practical review process usually includes:

• Confirming an accountable business owner and an accountable technical owner.
• Measuring real usage over a meaningful period, not just renewal-period sampling.
• Identifying all integrations, tokens, and service accounts tied to the app.
• Checking whether the app duplicates another approved platform.
• Verifying whether offboarding is possible without disrupting downstream systems.

This aligns with identity hygiene principles in The State of Non-Human Identity Security, where 85% of organisations lacked full visibility into third-party vendors connected via OAuth apps. These controls tend to break down when the SaaS is embedded in shadow IT workflows, because no one can reliably trace every dependent process or hidden integration.

Common Variations and Edge Cases

Tighter SaaS rationalisation often increases operational friction, requiring organisations to balance cost reduction against workflow continuity and integration risk. That tradeoff is real, especially when a low-usage application supports executive reporting, a regulated process, or a legacy system that is difficult to replace.

There is no universal standard for this yet, but current guidance suggests treating edge cases differently from ordinary shelfware. A rarely used application may still be justified if it is the only system with a required compliance function, a contractual obligation, or a hard dependency from another platform. Conversely, an app with frequent logins can still be a good retirement candidate if the activity is entirely administrative, duplication-heavy, or driven by temporary project work.

Security teams should be cautious where the app owns privileged automation, especially in environments with shared service accounts, contractor access, or a chain of connected SaaS tools. In those cases, the decision is not “keep or remove” based on usage alone. It is “can the organisation safely revoke the app’s trust without breaking downstream access.” If the answer is unclear, the app should move into a controlled review queue rather than auto-renew.

For broader governance context, the NIST framework is useful for aligning ownership and lifecycle control, while NHIMG’s research on NHI lifecycle management remains especially relevant when SaaS subscriptions quietly preserve old secrets, old permissions, and old assumptions.

Related resources from NHI Mgmt Group

• How can security teams tell whether helpdesk-led access governance is working?
• How can security teams tell whether GitOps is really improving governance?
• How can security teams tell whether MSP admin access is overprivileged?
• How can teams tell whether SaaS sprawl is becoming an identity governance problem?