If your Security team is pushing OIG as the thing that will "fix everything," the honest feedback from practitioners who have used it is more nuanced. Okta Identity Governance does what it says on the tin for access requests and certifications. It doesn't solve the full onboarding/offboarding problem across 60 apps, and the expectation that it will is the source of the most common disappointment.

Here's what OIG actually does, where it works well, and what it won't cover for your specific situation.

What OIG Actually Does Well

The Okta Certified Consultant who used OIG early and has followed its development since was direct: for the things it can currently do, it works well.

Access requests work well, particularly for organizations with many applications. Employees can request access through a structured workflow rather than sending IT tickets. This reduces support burden and creates a paper trail for access grants. If you have 60 apps and users regularly need to request access to specific ones, this is genuine improvement over email threads.

Access certifications are easier than exporting to spreadsheets and checking with managers one by one. The reviewer dashboard is functional, the campaign scheduling works, and it produces a record of the review. For SOC 2 access review requirements, OIG certifications satisfy the basic control requirement better than manual alternatives.

The PIM-like elevated access workflow — replicating Azure PIM functionality for certain admin roles — is something a practitioner in this thread successfully built using OIG. The caveat they gave: the setup was painful, duplicating and editing requests requires significant effort, and getting new request types configured is a real administrative burden. Once it's running it works, but the plumbing to get there is substantial.

Where OIG Consistently Falls Short

The feedback from both early access users and the Okta Certified Consultant reviewing GA has been consistent: the gaps that existed in EA largely persist.

No Okta Workflows integration. This is the most significant architectural gap for organizations that already use Workflows for automation. OIG was acquired from a third party and hasn't been fully integrated into the Okta platform in a way that lets you combine governance triggers with Workflows logic natively. If your automation strategy depends on Workflows, OIG sits alongside it rather than within it.

Limited logic on access requests. The access request workflows support basic routing but have limited conditional logic for complex approval scenarios. Organizations that need multi-level approvals based on application risk tier, department-specific routing, or dynamic approval chains based on the requested access level will hit the ceiling quickly.

No internal request database at audit time. Producing a historical record of who requested what, when it was approved, and by whom — the audit trail that compliance requires — requires additional configuration to route requests to an external system. The access request history doesn't exist natively in a queryable audit database within OIG itself without additional setup.

The Core Issue for 60 Apps and Broken Onboarding/Offboarding

The expectation that OIG will fix onboarding and offboarding across 60 applications needs to be examined carefully before you commit to the implementation.

Okta's provisioning model relies heavily on SCIM. For applications in your 60 that support SCIM, Okta handles provisioning and deprovisioning natively — when an employee's account is activated or deactivated in Okta, the SCIM-connected apps update automatically. For the applications that don't support SCIM — which is a significant portion of most 60-app stacks — Okta doesn't automatically provision or deprovision. Those apps either require Okta Workflows with custom API calls per app, manual IT intervention, or they remain outside the automated lifecycle entirely.

OIG sits on top of this provisioning model. Access certifications and request workflows in OIG are governance processes that operate on the access layer Okta can see. The applications outside Okta's SCIM reach are also outside OIG's governance scope — they won't appear in access certifications unless you're pulling data from them separately, and they won't be automatically deprovisioned when someone leaves unless you've built custom Workflows logic for each one.

If your onboarding/offboarding is a "dumpster fire" because of the apps that aren't connected to Okta, OIG won't fix that part. It will improve the governance and visibility for the apps that are connected.

The Alternative Architecture: Okta for Authentication, Dedicated IGA for Governance

The pattern organizations use to cover all 60 apps — including the non-SCIM ones — keeps Okta as the authentication and SSO layer and adds a dedicated IGA platform as the orchestration layer for provisioning, deprovisioning, and governance across the full stack.

Zluri integrates with Okta as the identity source and adds coverage for the applications Okta's SCIM doesn't reach: direct API integrations for applications with REST APIs but no SCIM support, AI-powered browser automation for applications with admin UIs but no API, and governed manual task routing for applications that require human intervention. The offboarding playbook covers all 60 applications — not just the Okta-connected subset — because Zluri's discovery engine maps the full access footprint including shadow IT and non-SSO tools.

For access reviews, Zluri's certification campaigns cover the same scope as OIG for Okta-connected apps, but extend to the non-SSO and non-SCIM applications that OIG can't see. For organizations where audit findings on orphaned accounts span both connected and disconnected applications, this broader coverage is the structural fix rather than OIG alone.

This isn't an argument against implementing OIG — if your organization is already paying for it and the Okta professional services engagement is planned, implementing it for the access request and certification workflows it does handle well is reasonable. The argument is against expecting it to solve the full onboarding/offboarding problem across a 60-app environment where a significant portion of apps aren't SCIM-connected.

Practical Advice Before You Commit

Audit your 60 apps for SCIM support before the implementation starts. Categorize each application: native Okta SCIM integration, custom Workflows API call needed, or no automation path through Okta. This inventory tells you how much of the onboarding/offboarding problem OIG and Okta Workflows can actually solve versus how much requires a different approach or platform.

Request a demo in your preview environment with your actual apps. The Okta Certified Consultant's advice is correct: demo OIG specifically against the workflows you need to run. Don't evaluate it against a pre-configured demo environment with toy applications.

Get clarity on the professional services scope. Understand specifically what will be configured, what you'll own after the engagement, and what the ongoing administrative burden looks like for adding new request types or modifying existing ones. The feedback on the administrative pain of editing requests and adding new ones is consistent enough to warrant specific attention.

Frequently Asked Questions

Is Okta Identity Governance good for onboarding and offboarding automation?

OIG handles access request workflows and access certifications well for Okta-connected applications. For onboarding/offboarding automation specifically, the limitation is that Okta relies on SCIM for automated provisioning — applications that don't support SCIM aren't automatically provisioned or deprovisioned through OIG. For organizations with many non-SCIM applications, OIG addresses the governance layer but doesn't solve the full lifecycle automation problem without additional Workflows development or a dedicated IGA platform.

How does Okta Identity Governance compare to dedicated IGA platforms?

OIG is Okta's native governance layer, acquired from a third party and integrated into the platform. It's strongest for access requests and certifications within the Okta ecosystem. Dedicated IGA platforms like Zluri, SailPoint, and Saviynt offer broader coverage — particularly for non-SCIM applications, HRMS-driven lifecycle automation, and governance across shadow IT and disconnected apps. For organizations where governance scope extends well beyond Okta-connected applications, a dedicated IGA platform typically provides more complete coverage.

What does Okta Identity Governance actually cost?

The $4/user/month figure that appeared in this thread's discussion is the commonly cited estimate, though actual pricing varies by contract and user count. Verify the current pricing with your Okta rep, including whether it's additional to your existing Okta licensing tier and whether it includes the professional services implementation.

What are the gaps in Okta Identity Governance at GA?

Persistent gaps noted by practitioners include: no native Okta Workflows integration, limited conditional logic in access request workflows, no queryable internal request audit database without additional configuration, and high administrative burden for creating and modifying request types. These are known limitations rather than bugs — OIG does what it does well within those constraints.