Unsupported SaaS apps complicate offboarding because the identity team cannot rely on the normal connector model to remove access or verify entitlement changes. If the application lacks an API or only exposes partial data, teams must use manual steps or custom scripts, which are slower and easier to miss. That creates a governance gap between leaving the company and actually losing access.
Why This Matters for Security Teams
Unsupported SaaS apps turn offboarding into a coverage problem, not just an HR workflow. When an application has no reliable connector, identity teams lose the normal evidence trail for entitlement removal, token revocation, and account verification. That matters because access can survive the employee relationship even when the directory record is closed, especially in apps that accept local logins, personal email recovery, or manually created API keys.
This is one reason offboarding belongs in the broader lifecycle controls discussed in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NHI Lifecycle Management Guide: visibility and revocation are inseparable. NIST also frames this as a governance issue, not merely an IT task, in the NIST Cybersecurity Framework 2.0, where identity and access management must be repeatable, auditable, and aligned to risk.
In practice, many security teams discover unsupported-app exposure only after a former employee is still able to sign in, export data, or approve workflows days after termination.
How It Works in Practice
The operational challenge is that unsupported SaaS apps sit outside the normal provisioning and deprovisioning path. A mature offboarding process usually depends on SCIM, SAML, directory sync, or an admin API to remove the user, invalidate sessions, rotate secrets, and confirm the change. When none of those exist, the team falls back to manual admin portals, browser automation, ticket-driven follow-up, or ad hoc scripts. Those methods can work, but they are slower, harder to standardize, and much easier to miss.
For SaaS exposure, that missing control becomes especially serious when the departing employee created their own local account, stored recovery methods, or configured app-specific tokens that are not centrally visible. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful proxy for how often revocation still depends on manual effort rather than enforced lifecycle control. The same lifecycle gap is visible in breach analysis such as the Snowflake breach and the Salesloft OAuth token breach, where token handling and downstream access were central to the blast radius.
- Build a complete SaaS inventory, then tag apps by support level: SCIM-enabled, API-enabled, admin-console only, or unsupported.
- For unsupported apps, define a compensating control runbook with named owners, evidence requirements, and a required completion check.
- Capture account identifiers, recovery emails, delegated admins, and app-specific tokens during onboarding so they can be targeted at offboarding.
- Use conditional access, session expiry, and secrets rotation to reduce the value of any access that cannot be removed immediately.
The guidance breaks down in heavily decentralized environments where business units buy SaaS directly and the security team has no authoritative app inventory, because revocation cannot be verified for tools that were never formally registered.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, so organisations have to balance speed against certainty when an app has no native lifecycle controls. The tradeoff is most visible in high-growth companies, mergers, and shadow-IT heavy environments, where every manual exception adds delay and creates a place for access to linger.
There is no universal standard for this yet, but current guidance suggests unsupported apps should be treated as higher-risk exceptions, not routine gaps. If the app holds sensitive data, approves payments, or can export records, the offboarding bar should be stricter than for low-risk collaboration tools. That usually means shorter temporary access windows, stronger approval chains, and explicit evidence that the account, sessions, tokens, and recovery paths were removed.
NHIMG data on former employee tokens remaining active after offboarding highlights why these edge cases matter: the problem is not only account closure, but the full revocation chain behind it. For organisations using the Top 10 NHI Issues as a governance lens, unsupported SaaS apps belong in the same risk conversation as unmanaged secrets and orphaned service accounts, because both create access that outlives its intended owner.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unsupported SaaS apps often leave orphaned identities and stale access behind. |
| NIST CSF 2.0 | PR.AA-5 | Identity proofing and access revocation are central to closing SaaS access gaps. |
| NIST AI RMF | GOVERN | Unsupported apps create governance blind spots that need ownership and accountability. |
Inventory and revoke every app-linked identity at offboarding, then verify no residual access remains.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
