Finding accounts from people who left four to eight months ago still active in your systems is not an edge case. It's the predictable outcome of a specific architectural gap: your SSO-driven deprovisioning works for the applications that are federated, and has no reach into the ones that aren't.

At 25-30 applications outside your federation, you're past the point where manual tickets to app owners is a viable control. The audit finding you got last time will repeat unless the process changes — not because your team is careless, but because manual processes that depend on every app owner remembering to act on every ticket, every time, reliably produce gaps. The audit found accounts from people who left four to eight months ago because that's how long it takes for the gap to become visible.

Here's how organizations managing similar mixed environments have actually solved this.

Why OneLogin-Driven Deprovisioning Has a Hard Boundary

OneLogin's deprovisioning model works by pushing a status change to applications that are connected via SAML or OIDC. When a user is deactivated in OneLogin, federated applications receive that signal and revoke access. It's clean, fast, and auditable.

The boundary is the federation itself. Applications that authenticate users through basic auth, local credential stores, or custom internal authentication mechanisms never receive that signal. OneLogin doesn't know what accounts exist in those systems, can't push a deprovisioning event to them, and has no way to confirm whether access has been removed. From OneLogin's perspective, those applications are invisible.

The gap isn't a OneLogin failure — it's a structural feature of how federation works. Solving it requires a different approach than extending your SSO coverage, because these applications either can't support SAML/OIDC or aren't going to be migrated. The solution has to work with the applications as they exist.

How Do You Discover Applications Outside Your Federation?

Before you can govern non-SSO applications, you need to know which ones exist and which users have access to them. OneLogin logs show you the federated application landscape. They don't show you the vendor portals that employees access through bookmarked URLs, the legacy tools with local authentication, or the departmental purchases that never came through IT.

Discovery for unfederated applications requires different signal sources. Browser and desktop agents monitor application launches and URL access patterns to surface tools that employees are actively using — including basic auth portals and internal custom apps that produce no SSO log entries. Financial and expense data is a complementary signal: corporate card spend and procurement records often surface vendor portals and departmental tools that bypassed IT oversight entirely.

The value of this discovery layer is that it closes the visibility gap before the next audit rather than finding gaps during it. If you don't know an application exists in your environment, you can't govern it. Once it's discovered, it can be catalogued, ownership can be assigned, and governance workflows can be applied — even without technical integration.

How Do You Automate Offboarding for Apps Without APIs?

The pattern that produces four-to-eight-month stale accounts is a manual process with no accountability mechanism: IT sends a ticket to an app owner, the app owner may or may not action it, and there's no follow-up unless someone notices during an audit. Replacing this with a governed manual task workflow changes the accountability structure without requiring the underlying application to support any integration.

Structured Manual Tasks

When an offboarding workflow is triggered for a departing employee, the system auto-populates the full list of applications that user has access to — federated and non-federated — based on discovery data. For applications that can be deprovisioned via API, the workflow executes automatically. For applications without API access, the workflow generates a structured manual task with a unique identifier, a deadline, and an assigned app owner.

The critical difference from an informal email is closure. The app owner has to mark the task complete before the offboarding record closes. That completion record, with a timestamp, is the evidence of timely access removal that auditors need. An email thread with no confirmed resolution isn't a control. A task with a required completion step and an audit trail is.

Jira Integration for Existing Service Desk Workflows

For teams already operating in Jira, these manual tasks can automatically generate Jira tickets assigned to the appropriate app owner — so the accountability mechanism integrates into existing workflows rather than requiring app owners to operate in a new system. The governance layer maintains the centralized audit trail; your team works in the tool they already use.

This approach is what moves you from “we notified the app owner” — which is what your current process produces as evidence — to “access was revoked on this date, confirmed by this person, with this task ID” — which is what auditors need to clear the finding.

What Compensating Controls Work for Non-SSO Applications?

For applications that can't be integrated technically, compensating controls demonstrate that you're managing the risk even though you can't eliminate it through automation.

Primary Source Mapping

One effective compensating control is tagging your SSO system — OneLogin, in your case — as the primary source of truth for user status in your non-SSO applications. The logic is: if a user is deactivated in OneLogin, any active accounts they hold in non-federated applications should be flagged as a risk requiring immediate review.

This doesn't remove the access automatically — it can't, because there's no integration. But it surfaces the gap proactively: when OneLogin status changes to inactive, the system flags those non-federated accounts as orphaned access, alerting IT before an auditor finds them. The gap between deactivation and confirmed removal in non-SSO apps can be measured in hours or days rather than months.

Periodic Access Reviews

Access reviews for non-federated applications give you a periodic confirmation that the access the app owner knows about is still appropriate — and that the app owner is actually checking. The structure matters. A spreadsheet sent via email produces no reliable evidence. A formal certification campaign, where each app owner reviews each user record and documents an approve-or-revoke decision with a mandatory justification, produces a timestamped, non-editable record that satisfies the “periodic access reviews” control auditors look for.

Running these campaigns on a defined schedule — quarterly for high-risk applications, semi-annually for lower-risk ones — demonstrates a risk-based approach. The campaign report becomes your audit evidence that access is being reviewed, not just assumed.

Is There a Path to Automating Legacy Apps Without SSO Changes?

For organizations looking for a longer-term solution that doesn't require the underlying applications to adopt SAML or OIDC, browser-based automation is worth understanding as an approach.

Rather than requiring an API, browser automation technology interacts directly with an application's web interface — navigating to the user management page, locating the account, and performing the deactivation the same way an admin would manually. For browser-accessible legacy applications, this can bring them into the automated offboarding workflow without any changes to the application itself.

This approach has limitations: it's more brittle than API-based integration (UI changes in the application can break the automation), and it doesn't work for thick-client or non-browser-accessible systems. But for browser-based vendor portals and internal tools that are otherwise ungovernable without API support, it's a meaningful middle option between full federation and pure manual process.