Unmanaged apps undermine JML because lifecycle actions only work when every account is known and tied to a governed system. If employees open accounts directly with vendors, offboarding can miss live access, leaving the organisation with orphaned accounts and incomplete evidence.
How unmanaged SaaS breaks JML control points
Joiner, mover, leaver processes depend on a governed inventory: who has access, to which app, under what owner, and through which control path. Unmanaged SaaS creates a shadow layer outside that inventory, so lifecycle actions stop being complete. The organisation may still process HR events correctly, but the actual access state no longer follows the record.
That breaks joiners when people create duplicate vendor accounts outside the standard onboarding flow, movers when role changes do not trigger entitlement updates, and leavers when offboarding only removes access the organisation already knows about. The result is not just delay, it is loss of control over the true account population.
For identity governance, the key issue is that JML is only as good as system coverage. If a SaaS app is not federated, not discovered, or not tied to an authoritative source, then provisioning, recertification, and deprovisioning become partial controls rather than end-to-end controls. A governed process can only remove access it can see.
Where unmanaged apps create hidden access and orphaned accounts
Unmanaged SaaS usually undermines JML in three ways: direct sign-ups bypass the access request workflow, local admin roles bypass central role design, and vendor-side accounts survive after employment changes. That leaves orphaned accounts, stale permissions, and poor evidence for audits or investigations.
It also creates role drift. A mover event may be recorded in HR and IAM, but the person keeps the old SaaS role because the application was never onboarded to provisioning. In practice, that means excessive access persists in the business tool while the organisation believes the employee has already moved to a new function.
This is especially damaging when the SaaS app holds data, approvals, customer records, or integration credentials. If access is not discoverable and governed, then account ownership becomes ambiguous and revocation depends on manual memory rather than a repeatable lifecycle control.
Why unmanaged SaaS weakens assurance, not just offboarding
JML failures in unmanaged SaaS are an assurance problem as much as an access problem. The organisation loses reliable evidence that an identity was provisioned correctly, changed when its role changed, and removed when the person left. That weakens access reviews, incident response, and segregation-of-duties checks because the control record no longer matches reality.
It also increases blast radius when credentials or tokens are reused across services. If the same user reuses the SaaS login for exports, integrations, or delegated administration, a missed leaver step can leave active paths into business data long after HR has closed the employment record.
Unmanaged apps are therefore a lifecycle blind spot: they do not just create extra work, they erode trust in the JML process itself. Once teams know that some apps sit outside the control plane, every access certification becomes less reliable.
Risk and Threat Considerations
Unmanaged SaaS creates a durable exposure because the organisation cannot revoke what it cannot enumerate. That makes offboarding failures, orphaned access, and stale privileges more likely, and it gives insiders or attackers a quieter place to retain access after an employee change.
Failure mechanism: Employees create or retain vendor accounts outside governed provisioning, so HR-driven joiner, mover, leaver actions never reach the live SaaS account, token, or role state.
Impact: The organisation can lose access control over customer data, approvals, exports, and integrations, while also weakening audit evidence and increasing the chance of post-exit misuse or lateral abuse.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | JML depends on complete account lifecycle control across SaaS apps. |
| IA-5 — Authenticator Management | Unmanaged SaaS can leave live credentials and tokens behind after offboarding. | |
| PS-4 — Personnel Termination | Leaver failures are a core failure mode when SaaS access survives employment exit. | |
| Recommendation — Inventory, provision, and disable all SaaS accounts through a governed account-management process. Track, rotate, and revoke SaaS credentials and tokens when users change or leave. Ensure termination procedures include SaaS access revocation and evidence of completion. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unmanaged SaaS commonly leaves orphaned accounts after offboarding fails. |
| NHI-05 — Overprivileged NHI | Unmanaged SaaS often preserves stale roles and excessive privileges after movers. | |
| NHI-09 — NHI Reuse | Shadow SaaS accounts and reused credentials extend access beyond the governed lifecycle. | |
| Recommendation — Remove all SaaS identities and secrets during offboarding, then verify the deletion. Review SaaS entitlements after role changes and remove privileges that are no longer needed. Eliminate duplicated SaaS identities and require unique, owned accounts for each system. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The topic is about access control that fails when SaaS is outside the managed identity plane. |
| Recommendation — Bring each SaaS app under centralized identity and access control before relying on JML. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Unmanaged SaaS breaks the identity inventory and ownership needed for lifecycle governance. |
| Recommendation — Maintain an accurate identity and account inventory across all SaaS applications. | ||
Practitioner Guidance
What to verify: Confirm that each business-critical SaaS app is tied to an owner, a source of truth, and a documented deprovisioning path. If an app cannot be discovered in access review or offboarding testing, treat it as a control gap rather than an edge case.
Decision rule: If the app supports production data, administrative functions, or integrated workflows, it needs the same JML discipline as a managed internal system. If it cannot support automated lifecycle actions, require compensating controls such as periodic account attestation and explicit offboarding evidence.
What practitioners underestimate: The biggest failure is often not missed termination, but silent role drift after movement events. The safer test is whether you can prove the app’s live account state changed when the person’s job changed, not whether a policy says it should.
Practitioner takeaway: JML only works when the application estate is complete; unmanaged SaaS turns lifecycle management into partial coverage, which is why discovery, ownership, and revocation evidence matter as much as the HR event itself.
Related resources from NHI Mgmt Group
- Why do service accounts and API keys complicate joiner-mover-leaver processes?
- What breaks when joiner, mover, leaver processes are handled differently for technical accounts?
- How do distributed identities fit with joiner mover leaver processes?
- What breaks when joiner-mover-leaver processes are applied to AI agents?