The situation you've described — Okta handling SSO well, 40 applications that were never properly integrated, orphaned accounts discovered months after offboarding, a security incident that took days to scope because you couldn't quickly map access in non-SSO systems, and a SOC 2 audit finding for inadequate visibility — is one of the most common identity governance problems in hybrid environments. It's also one of the hardest to solve because the tools designed for this problem (traditional IGA platforms) typically assume what you've already established isn't the case: that everything has APIs and connectors.

The approaches that actually work start from accepting that your environment has three distinct categories of non-SSO applications, each requiring a different integration path.

Why Traditional IGA Fails Here

Traditional IGA platforms are built on a connector catalog model: every application being governed needs a pre-built connector with read/write API access. For the 300-500 applications in their catalog, this works. For the custom internal tools engineering built over five years, the legacy systems acquired from another company, and the vendor portal that only supports username/password — there is no connector, and building a custom one requires professional services and ongoing maintenance.

Your script-based approach identified the right instinct: if you can pull user lists from these systems, you can at least see the state. The limitation you encountered is the same one scripts always have: they're point-in-time snapshots that require maintenance when the system changes, they produce data that has to be reconciled against something authoritative, and they don't close the loop on remediation or produce audit-ready evidence.

The architecture that actually works for non-SSO, non-API applications uses multiple integration paths depending on what each application actually supports.

Category 1: Browser-Based Apps Without APIs

Custom internal tools, vendor portals, and contractor-built applications are often web-based but lack REST APIs. They have admin UIs — dashboards where an administrator can manually add, modify, or remove users — but no programmatic interface.

What works: AI-powered browser automation. Rather than requiring an API, this approach uses deterministic browser automation that interacts with the application's UI directly: navigating to the user management section, locating the user to be offboarded, and executing the removal by interacting with the interface the way a human administrator would. The action is logged and timestamped for audit purposes.

The key capabilities this enables:

Offboarding execution for non-API apps. When an employee is offboarded through your IGA platform, the offboarding playbook includes an automated action against every browser-automatable application in their access profile. No manual administrator work required.

User list extraction for access reviews. The same browser automation can pull the current user list from an application's admin UI, which can then be surfaced in an access certification campaign.

The limitation: browser automation requires the application to have a reasonably consistent UI, and UI changes in the application may require the automation to be updated. This is less fragile than API integration in some ways (many legacy apps haven't updated their UI in years) and more fragile in others (a redesign breaks the automation).

Category 2: On-Prem Legacy Systems Tied to AD

Legacy systems from acquisitions typically authenticate through on-premises Active Directory, even if they were never federated to your Okta tenant. These systems depend on local AD accounts and groups — and if you can govern the AD layer, you can effectively govern access to the systems that depend on it.

What works: outbound-only AD agent. A lightweight agent deployed within your internal network connects to on-premises AD via LDAP/LDAPS using an outbound-only connection — no inbound firewall ports required. The agent syncs AD users, groups, and OUs to your cloud governance platform and can execute write operations (modifying group memberships, disabling accounts) as part of offboarding workflows.

For legacy acquisition systems that depend on specific AD groups for access, governing those groups through the AD agent provides effective lifecycle management without requiring any integration with the legacy system itself. When the offboarding workflow removes the user from the relevant AD group, the legacy system access is revoked through the AD dependency.

This approach does have a governance gap: it doesn't tell you what permissions the user had within the legacy system, only that they were in the groups that controlled access. For systems where permission-level visibility matters for access reviews, additional data extraction from the system itself may be needed.

Category 3: Apps With No Automation Path

Some applications genuinely don't support any automation: they have no API, no consistent UI for browser automation, and no AD dependency. Vendor portals that require contacting the vendor's support team to remove a user, legacy systems with proprietary admin interfaces, and contractor-built tools with single hardcoded admin accounts fall into this category.

What works: structured manual tasks with tracked completion. Rather than relying on email chains or Jira tickets that may or may not get resolved, a governed task system creates a mandatory task assigned to a specific owner — the person responsible for that application — when an offboarding event fires or an access review produces a revocation. The task has a unique ID, a completion deadline, and a status that is visible in a central dashboard. The offboarding record isn't closed until the task is marked complete.

This doesn't eliminate the manual work, but it does:

• Make the task mandatory and tracked rather than optional and email-based
• Assign it to the right person automatically rather than relying on someone to know who to contact
• Create an auditable record that the manual action was completed with a timestamp

For SOC 2, this is often sufficient: auditors want evidence that the review occurred and that revocation was completed. A tracked manual task with a completion timestamp and the assigned owner's identity is that evidence.

Solving the Specific Problems You Described

Days to scope the blast radius of a compromised account. The multi-source discovery engine that builds an access map across all three application categories — browser-agent discovered apps, AD-connected legacy systems, and manually governed systems — is what makes blast radius assessment fast. When the security incident happened, the question was "what does this compromised account have access to across our full environment?" A discovery-backed access graph answers that in real time rather than requiring manual investigation of each system individually.

Orphaned accounts months after offboarding. Orphaned accounts in non-SSO systems persist because the offboarding workflow only covered Okta-connected applications. The playbook-based approach extends offboarding coverage to every application in the access profile — SSO and non-SSO — using the appropriate integration path for each. When an employee is deactivated in your HRMS, the offboarding playbook runs against every system in their profile, not just the Okta-connected ones.

SOC 2 audit finding for inadequate non-SSO visibility. The SOC 2 requirement is evidence that access to in-scope systems has been periodically reviewed. For non-SSO applications, this means two things: first, that you have an inventory of current access in those systems; second, that you can demonstrate periodic review with timestamped, documented decisions and evidence that revocations were completed. Non-editable PDF certification reports with mandatory justifications and remediation timestamps provide the evidence format that SOC 2 auditors expect.

Manual provisioning across 15+ systems for new hires. New hire provisioning for non-SSO systems follows the same three integration paths as offboarding: browser automation for UI-based provisioning in browser-accessible apps, AD group additions for AD-dependent legacy systems, and governed manual tasks for apps with no automation path. The new hire event triggers a playbook that handles all three simultaneously rather than requiring manual IT work per system.

The Source of Truth Problem for Non-SSO Apps

Your script-based approach produced user lists that were immediately out of date because the authoritative source of truth was the system itself — and the system changed independently of your data. The governance model that prevents this establishes precedence logic for each application:

For applications where Okta users are logging in even without formal federation: Okta becomes the de facto source of truth for user status. When a user is deactivated in Okta, the governance platform marks them inactive in those non-federated applications and triggers the appropriate remediation. This isn't SSO — it's using Okta's authoritative status as a trigger for governance actions.

For applications that have no Okta relationship: Your HRMS becomes the source of truth. When the HRMS records a termination, the offboarding playbook runs against all applications in the departing employee's profile regardless of their SSO status.

For applications that need to be discovered before they can be governed: Discovery runs before governance. Browser agents, financial transaction analysis, and AD group analysis provide the inventory of what exists before you can decide how to govern it.

Frequently Asked Questions

How do you discover SaaS and internal applications that were never onboarded to Okta?

Multi-source discovery combines browser and desktop agents (tracking URLs and applications accessed at the endpoint level), financial transaction analysis (identifying recurring SaaS purchases outside IT procurement), SSO log analysis (surfacing applications Okta users access that aren't formally federated), and AD group analysis (identifying systems with AD-based access control). Together these sources build an inventory of the application footprint that manual catalog approaches can't match.

How do you manage offboarding for applications without APIs or SAML support?

Three paths depending on the application type: AI-powered browser automation for web-based applications with admin UIs, AD agent-based group modification for legacy systems with AD dependencies, and tracked manual task assignment for applications with no automation path. All three paths create audit records of the action taken and its completion status, which is what SOC 2 access management controls require.

What causes orphaned accounts in non-SSO applications?

Orphaned accounts in non-SSO applications occur because offboarding workflows are typically scoped to IdP-connected applications. When Okta deactivates a user, only applications federated through Okta receive the deprovisioning signal. Applications outside the SSO perimeter don't receive the signal and retain active accounts indefinitely. Discovery that maps the full application footprint and offboarding playbooks that extend to non-SSO applications prevent orphaned accounts from accumulating.

What does a SOC 2-ready access review look like for non-SSO applications?

A SOC 2-ready access certification for non-SSO applications includes: a current user list from the application (extracted through automation or manual export), a certification campaign where designated reviewers approve or revoke each user's access, timestamped records of every decision with mandatory justification for retained access, and evidence that revocations were completed — either through automated remediation or tracked manual task completion. Non-editable PDF reports with these elements provide the audit evidence format that SOC 2 Type II access management controls require.