Stay on Okta SSO, add Iden on top

What Okta SSO does, what it doesn't, and how Iden plugs in as the governance layer on top. Setup walkthrough, common patterns, where the responsibilities split.

6 min read · Last updated June 2026

Okta does authentication well. It does SCIM lifecycle for the apps that support it. It does workflow building for the gaps. What it doesn't do is the rest of identity governance, because it was never built to.

If you're already on Okta SSO, the question isn't whether to leave. It's how to add the governance layer Okta isn't designed to be. This guide covers exactly that. What Okta is doing today. What it isn't doing. How Iden plugs in alongside. The setup walkthrough. The patterns that work.

What Okta SSO does

The Okta product line covers a lot, but the SSO and adjacent products handle authentication and the basic SCIM-driven user lifecycle:

  • Federated authentication: SAML and OIDC across thousands of apps
  • SCIM-based user provisioning into apps that expose a SCIM endpoint at your plan tier
  • Lifecycle Workflows for cross-app sequences (the no-code builder)
  • Group management with assignment rules
  • MFA, session management, password reset

This is what most teams already have working. Authentication is solid. SSO into 30+ apps is functional. The team trusts it.

What Okta SSO doesn't do

Past the authentication layer, Okta wasn't built to be the identity governance layer. The gaps are predictable.

Apps it can't reach. Okta SCIM only governs apps that expose SCIM at the plan tier you're paying for. Across the average mid-market stack, that's about 20%. The other 80% (most non-SCIM SaaS, internal admin panels, legacy systems, on-prem databases, custom apps) is out of Okta's provisioning reach. Lifecycle Workflows can fire a Jira ticket; that's not governance, that's a notification.

Per-entitlement governance. Okta governs at group level. Whether someone is in the "Engineers" group, yes or no. Not whether they should have admin on a specific repository or admin on the staging database. Most companies' real access decisions are per-entitlement, not per-group.

Access reviews at scale. Okta IGA (the add-on) caps at two reviewer levels and 250 apps per certification campaign. The action is remove-only: no modify, no downgrade, no role swap during the review. Useful at small scale, painful past 500 users.

Contractor lifecycle. Okta doesn't model contractors as a first-class identity. You build it in Workflows or you don't have it. Most teams don't; the contractors live in a spreadsheet.

Non-human identity. Service accounts, API keys, OAuth grants, AI agents. Okta's ISPM addresses observability for Okta-managed assets but doesn't extend to lifecycle for NHIs across the whole stack.

Evidence assembly for compliance. SOC 2 CC6, ISO 27001 A.5.18, HIPAA termination procedures. Okta exports CSVs. Real evidence assembly with policy linkage and continuous handoff to your GRC platform is downstream work nobody automates without a separate tool.

How they work together

Iden plugs into Okta and the rest of your stack at four points.

The HRIS feeds joiner-mover-leaver. Iden reads from your HRIS (Workday, BambooHR, Personio, Rippling, HiBob, or whatever you run) as the source of truth for who exists, what role they're in, what status they have. Same data Okta uses. You don't have to pick.

Okta handles authentication. When a user logs in, they hit Okta. Iden doesn't replace this. Okta SSO continues to be the IdP.

Iden handles governance across the actual stack. Per-entitlement provisioning, fine-grained access reviews, contractor lifecycle, non-human identity, audit evidence. Apps Okta can't reach via SCIM get reached by Iden via API or browser automation.

Workflows stays where it makes sense. The Workflows you built for custom business logic (cross-team approvals, escalations, branching) continue to live in Okta. The Workflows you built to compensate for missing connector coverage can be retired. Iden takes over that work.

The responsibility split:

| Okta | Iden | |---|---| | User authentication (SAML, OIDC) | Per-entitlement provisioning across the full stack | | SCIM provisioning for SCIM-supported apps | Provisioning for the 80% Okta can't reach | | Group management as IdP context | Fine-grained access reviews and certifications | | MFA, session, password | Contractor lifecycle (first-class identity) | | Lifecycle Workflows for business logic | Non-human identity lifecycle | | | Audit evidence assembly and GRC integration |

Setup walkthrough

Connect Okta to Iden through the standard SCIM 2.0 integration. Iden ingests the Okta directory state (users, groups, group memberships) and reads ongoing changes via SCIM. Setup time: 10 to 15 minutes.

Connect your HRIS. Iden reads joiner-mover-leaver from your HRIS as the authoritative source. If your HRIS already feeds Okta, no change required for the Okta side. Iden reads in parallel.

Connect the apps Okta isn't governing. The 80% in the long tail: non-SCIM SaaS, internal admin tools, legacy systems. Iden uses API integration where available, browser automation where API is missing, custom connector where neither exists. First 15 apps connect in under an hour.

Configure birthright. Map each role in your org to the entitlement bundles a new hire should receive. This becomes the policy that fires on every new hire of that role.

Set the cross-app access review schedule. Quarterly, monthly, continuous, depending on what your compliance program needs. Iden runs the reviews and assembles evidence in the background.

That's the full setup. From signing to live: typically two to four days of clock time, less in active work.

Common patterns

A few configurations we see most often.

Okta as IdP, Iden for the 80%. Most common. Okta keeps doing authentication and SCIM provisioning for the apps it can reach. Iden handles everything else.

Okta + Okta IGA + Iden. Some teams have both. Okta IGA runs certification campaigns for SCIM-supported apps; Iden handles the rest plus fills the OIG limits (250-app ceiling, two reviewer levels, group-level only). Works fine. Most teams eventually consolidate to Iden alone, but the parallel pattern is supported.

Multi-IdP. Okta SSO for the main workforce, Entra ID for a Microsoft-heavy department, Google Workspace for a subsidiary. Iden runs the governance layer across all three. The HRIS remains the unified source of truth.

Okta Workflows + Iden connectors. For teams with significant Workflows investment: keep the custom business logic in Workflows, move the connector work to Iden. The dividing line is clear during setup. We walk through your specific Workflows together.

Where to ask for help

Setup support runs weekly. Bring your Okta config (SCIM apps list, Workflows you've built, certification cadence) and your timeline. We'll walk through how Iden plugs in for your specific Okta setup and where the work concentrates.

Frequently asked questions

Do we have to change anything in Okta?

No. Iden reads from Okta via SCIM. Authentication keeps going through Okta. The Workflows you've built stay where they are. Group memberships continue to drive whatever they currently drive in Okta.

How does Iden handle the apps Okta is already provisioning via SCIM?

Iden defers to Okta where Okta is already handling things cleanly. The apps Okta provisions via SCIM stay on Okta's flow. Iden picks up the apps Okta can't reach. You don't end up with two systems fighting over the same app.

We have Okta IGA. Do we need to drop it before adding Iden?

No. The two coexist. Okta IGA handles certifications for SCIM apps if you want it to. Iden handles the rest plus the gaps OIG leaves (non-SCIM apps, group-level governance, the 250-app cap, the remove-only review action). Most teams eventually retire OIG and consolidate to Iden, but the parallel state is supported indefinitely.

What if we're already heavy on Okta Workflows?

Keep the Workflows that handle real business logic (custom approvals, escalations, branching). Retire the Workflows you built to fill in for missing connectors. The dividing line is usually clear once we look at your Workflows together during setup.

Does Iden see the same user data Okta sees?

For users that exist in both Okta and the HRIS, yes. Iden reads from both. The HRIS is the source of truth for identity attributes (role, department, status, end date). Okta is the source of truth for authentication state and group membership. Iden reconciles them.

We're considering switching off Okta. Does Iden change that?

No. Iden runs alongside any SSO. If you switch from Okta to Entra (or vice versa) later, Iden continues to work. The transition is a separate decision.

What happens during Okta downtime?

Authentication is unavailable, same as before. Iden's governance actions (queued provisioning, scheduled reviews, audit evidence assembly) continue running. When Okta comes back, the SCIM reads sync up.

How does access request routing work with our existing Okta workflow?

Iden's access request flow can run in front of Okta's, behind it, or alongside it. Most teams route requests through Iden first (for the per-entitlement context and approval routing), then Iden triggers the provisioning action through whichever channel (Okta SCIM for SCIM apps, Iden's own connector for the rest).

What about our Drata or Vanta setup?

Iden pushes evidence directly to Drata, Vanta, Secureframe. Okta's existing reports also continue to feed your GRC platform. The two evidence streams coexist. Auditors see a unified trail.

We have Okta WIC (Workforce Identity Cloud). Same answer?

Same answer. The WIC bundle includes some IGA features that overlap with Iden. Same coexistence model applies: use what's working in WIC, layer Iden on for the parts WIC doesn't cover.