SaaS Churn

Expanded Definition

SaaS churn describes the continual replacement of business applications as teams trial one service, adopt it briefly, and then move to another. In NHI security, the concern is not procurement churn alone but the identity residue left behind: OAuth grants, API keys, service accounts, and webhook permissions that persist after the app is no longer actively used. Guidance varies across vendors on how much churn is “normal,” but no single standard governs this yet, so practitioners should treat it as a governance and discovery problem rather than a simple software refresh cycle.

This matters because each short-lived app can introduce a new trust relationship, a new data path, and a new set of secrets to inventory. The control challenge is closer to lifecycle management than application cataloging, and it aligns naturally with NIST Cybersecurity Framework 2.0 functions for asset visibility and access oversight. For NHI teams, churn also means an app can disappear from active use while its permissions remain fully valid. The most common misapplication is assuming SaaS offboarding happens automatically, which occurs when procurement closes the contract but security never verifies token revocation or connector removal.

Examples and Use Cases

Implementing SaaS churn controls rigorously often introduces operational friction, requiring organisations to weigh faster experimentation against the cost of continuous cleanup, review, and revocation.

• A marketing team pilots a collaboration tool for two weeks, then abandons it, but the integration token still has read access to shared files.
• A sales enablement app is replaced after a merger, yet the old OAuth grant remains active and continues to sync customer records until discovered during review.
• A development team tests a monitoring platform, creates a service account, and later migrates away, but the account is never deprovisioned because ownership was never reassigned.
• An operations group adopts a temporary file-transfer SaaS, then decommissions it after an incident, while webhook permissions and API keys remain in CI/CD secrets stores.

These patterns are visible in incidents such as the Salesloft OAuth token breach, where long-lived access outlasted operational intent, and they echo the discovery and control themes in the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

SaaS churn turns identity governance into a moving target. When apps are frequently swapped, security teams can lose track of where secrets live, which identities are still trusted, and which connectors have authority over sensitive data. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap becomes more severe when application turnover is high. Churn also amplifies third-party exposure, because each new app may extend data access beyond the enterprise boundary before controls are fully reviewed.

The result is a steady buildup of stale permissions, duplicated credentials, and undocumented integrations, all of which weaken zero trust and complicate incident response. This is why NHI governance needs continuous discovery, not periodic cleanup, and why the Ultimate Guide to NHIs frames visibility, rotation, and offboarding as core controls. The broader risk is illustrated by the BeyondTrust API key breach and the Snowflake breach, where identity and access persistence became an attack path. Organisations typically encounter the real cost only after an app is retired, at which point stale access, not the software itself, becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do third-party SaaS integrations create NHI risk and how should they be managed?
• How should teams secure non-human identities across cloud and SaaS?
• How should enterprises govern AI agents across multiple clouds and SaaS platforms?
• Why can a single SaaS app create such a large blast radius?