Lifecycle management in SaaS security exposes NHI governance gaps

At a glance

What this is: This blog post argues that SaaS lifecycle management is a security control problem, with offboarding, dormant integrations, and external data shares all creating persistent access risk.

Why it matters: It matters to IAM and NHI teams because removing human access does not automatically revoke the tokens, API keys, or shares that continue to carry authority.

By the numbers:

• According to the 2024 State of SaaS Security report, 93% of security teams claim to have automated processes for offboarding ex-employees and contractors.
• According to the 2024 State of SaaS Security report, 65% of integrations in platforms like Microsoft 365 are inactive but still hold valid API keys or OAuth tokens.
• According to the 2024 State of SaaS Security report, 94% of external data shares are inactive, with no recent access by external users.

👉 Read Valence Security's analysis of SaaS lifecycle management risks

Context

SaaS lifecycle management is the discipline of controlling access, integrations, and sharing across the full life of an application. In practice, the gap is that human offboarding often outpaces non-human deprovisioning, so tokens, API keys, local accounts, and external links remain active after the business need has ended. That creates a direct NHI governance problem, not just a SaaS administration issue.

Valence Security uses lifecycle management to frame a familiar security failure pattern: the organisation removes the obvious account, but leaves the attached machine access and data paths in place. That is a typical weakness in SaaS-heavy environments, especially where shadow IAM, ad hoc OAuth grants, and unmanaged shares accumulate outside central identity controls.

Key questions

Q: How should security teams handle SaaS offboarding when non-human identities are involved?

A: Security teams should revoke the human account in the IdP and separately verify every SaaS-local account, OAuth grant, API key, and external share tied to that user. The safest approach is lifecycle closure by access object, not by person alone, because SaaS platforms often preserve authority outside central directory controls.

Q: Why do dormant SaaS integrations create so much identity risk?

A: Dormant integrations remain dangerous because they often keep valid secrets or delegated consent after the business process ends. If the permissions include read, write, or admin-like actions, a forgotten integration becomes a standing non-human identity that can be abused without alerting the original owner.

Q: What is the difference between SSO offboarding and full SaaS lifecycle revocation?

A: SSO offboarding removes a user from the corporate identity system, while full SaaS lifecycle revocation also disables local SaaS accounts, tokens, integrations, and shares that exist inside the application. The difference matters because many SaaS access paths are created outside the directory and survive after SSO closure.

Q: When should organisations review external data shares as part of identity governance?

A: Organisations should review external shares whenever a user leaves, a project ends, a proof of concept closes, or a business owner changes. Shared links and folders are access artifacts, so they need ownership, expiry, and removal checks just like any other privilege-bearing credential.

Technical breakdown

Why SaaS offboarding fails when non-human identities stay active

SaaS offboarding usually focuses on disabling the human user in the identity provider, but SaaS platforms often contain their own local accounts, OAuth grants, API tokens, and delegated permissions. Those artifacts can survive because they are not always tied to the same lifecycle event as the employee record. The result is a split control plane: one system says access is removed, while another still allows the application or integration to act. In NHI terms, the real risk is not just forgotten credentials, but forgotten authority that continues to execute under an existing trust relationship.

Practical implication: inventory SaaS-native accounts and tokens separately from SSO-linked identities, then tie revocation to the offboarding workflow.

How dormant SaaS-to-SaaS integrations become NHI exposure

Dormant integrations are often created during proof-of-concept work, automation pilots, or temporary business workflows. Even when the business process ends, the integration may retain valid secrets or OAuth consent that can still read mail, move files, or call APIs. This is structurally similar to long-lived machine identity risk: the credential persists longer than the use case, and the access scope is often broader than the owner remembers. Because integrations can be shared across teams and tools, the blast radius may extend beyond the original application boundary.

Practical implication: classify every SaaS integration by owner, purpose, permission scope, and expiry so dormant access can be revoked or revalidated quickly.

Why external shares need lifecycle controls, not only access reviews

External data shares are another form of access artifact that outlives the original need. A link, folder share, or recording permission can continue exposing data even after the project closes or the recipient relationship changes. Traditional access reviews are weak here because they tend to look at named users, not at continuously reachable shared objects. In a SaaS environment, those shares behave like unmanaged entitlements with their own lifecycle, which means they need monitoring, expiry, and cleanup logic just like credentials do.

Practical implication: treat shared links and externally reachable objects as governed entitlements with expiry, ownership, and revocation requirements.

Threat narrative

Attacker objective: The objective is to exploit retained SaaS authority after offboarding so the attacker can access data or operate inside connected services without needing a fresh compromise.

1. Entry occurs when an attacker finds an unrevoked SaaS account, dormant OAuth grant, or lingering integration token that still has valid access.
2. Escalation occurs when that identity has inherited permissions broader than the original business task, allowing mailbox, file, or admin-like actions.
3. Impact follows when the attacker uses retained SaaS authority to access data, manipulate records, or pivot through connected services.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Lifecycle management is now an NHI control problem, not a back-office SaaS hygiene task. Once SaaS apps hold their own accounts, tokens, and delegated shares, offboarding becomes an identity governance problem that extends beyond the HR event. Security teams that only remove SSO access are leaving a second control plane untouched. Practitioners should treat SaaS lifecycle governance as part of identity security architecture, not as an application-admin cleanup exercise.

Shadow IAM is the more durable risk because it hides outside central identity workflows. Local SaaS accounts and directly issued OAuth grants can survive even when corporate identity records are closed. That makes them harder to find, harder to review, and easier to miss during mergers, contractor exits, and temporary integrations. The practical conclusion is that visibility must cover SaaS-native entitlements, not just directory-connected identities.

Dormant integrations create identity blast radius because their permissions often outlive their purpose. A forgotten API key or test application can still read, write, or forward data long after the original use case is gone. In NHI governance terms, the problem is not simply exposure, but retained authority across connected systems. Teams need lifecycle enforcement that pairs ownership with expiry and periodic revalidation.

External shares should be governed as revocable access objects, not as passive collaboration convenience. Shared links and external folders are effectively credentials to data, and they need the same discipline applied to any other privileged access artifact. That means ownership, expiry, review, and automated cleanup. Organisations that keep treating them as low-risk collaboration features will continue to accumulate hidden access paths.

Lifecycle maturity is becoming a benchmark for SaaS security posture. The field is moving toward continuous control over accounts, integrations, and shares because point-in-time offboarding is not keeping pace with SaaS sprawl. That makes SaaS lifecycle management a proxy for broader NHI governance maturity. Practitioners should measure whether their controls remove authority, not just deactivate users.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a lifecycle-focused view, see NHI Lifecycle Management Guide, which helps teams turn revocation into an operational control rather than an afterthought.

What this signals

Shadow IAM is where SaaS lifecycle programmes will keep failing if teams only instrument directory offboarding. The control gap is not theoretical. With 91.6% of secrets still valid five days after notification in our research, late revocation remains a structural weakness, and SaaS-native tokens can behave the same way when no one owns them end to end. Teams should design for continuous discovery and closure of non-human access paths, not periodic cleanup.

As SaaS environments expand, the programme-level question is whether identity governance extends into application-native access objects. That means the reader’s next control milestone is not just reviewing users, but governing shares, service connections, and delegated permissions with the same discipline applied to privileged accounts. The OWASP Non-Human Identity Top 10 is a useful reference point for organising that work.

For practitioners

• Implement SaaS-native offboarding checks Map every termination workflow to SaaS-local accounts, OAuth grants, API keys, and delegated shares so revocation is not limited to the corporate IdP. Use one closure process for the human account and another for the attached non-human access.
• Build a dormant integration review queue Review integrations by owner, business purpose, last use, and permission scope so inactive connections can be revalidated or removed. Prioritise integrations that can read mail, modify files, or call admin APIs.
• Treat external shares as governed entitlements Assign an owner, expiry expectation, and revocation path to shared links, folders, and recordings. Monitor for open links and stale external access paths that continue after the business need has ended.
• Correlate IdP, HR, and SaaS telemetry Join identity lifecycle events with SaaS audit logs so offboarding can trigger follow-up checks for tokens, integrations, and shares created by the departed user. This is the fastest way to expose shadow IAM.

Key takeaways

• SaaS lifecycle management is an NHI governance issue because access often survives the removal of the human user.
• Dormant integrations, unmanaged local accounts, and external shares all create persistent authority that can outlast the original business need.
• Security teams should revoke access objects, not just users, and tie offboarding to continuous discovery of SaaS-native credentials and shares.

Key terms

• Shadow IAM: Shadow IAM refers to identity and access paths created outside the central identity program, usually through local SaaS accounts, ad hoc OAuth grants, or application-specific permissions. These entitlements often survive offboarding because they are not governed by the same lifecycle controls as directory-backed access.
• Dormant Integration: A dormant integration is a SaaS-to-SaaS connection that is no longer actively used but still holds valid credentials or consent. It matters because the integration can continue to access data or trigger actions even after the business owner assumes it is retired.
• External Data Share: An external data share is any link, folder permission, recording access, or shared object that allows people outside the organisation to view or use information. In SaaS environments these shares behave like access artifacts and need ownership, expiry, and revocation controls.
• SaaS-Native Access: SaaS-native access is permission that exists inside the application itself rather than in the corporate directory. It includes local accounts, delegated grants, API tokens, and sharing rights, and it is often the reason SSO offboarding is necessary but not sufficient.

Deepen your knowledge

SaaS lifecycle management and non-human identity revocation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your organisation is trying to close the gap between SSO offboarding and SaaS-native access, it is worth exploring.

This post draws on content published by Valence Security: Lifecycle Management in SaaS Security: Navigating the Challenges and Risks. Read the original.