Six weeks ago you deployed Okta. The login screens are clean. The SSO works for the apps that support it. The team trusts it more than they trusted whatever was happening before. The deployment project is closed. You're done.
Then you start using it. The first thing you notice is the apps Okta doesn't reach. Then you notice that "reach" is doing a lot of work in that sentence. Some apps are SCIM-supported but only on enterprise plans you don't have. Some apps have an Okta SAML connection but no provisioning. Some apps are internal and were never on Okta's catalog to begin with.
By month three you have a list of gaps and a CEO who's asking why governance isn't governed. This is the post-Okta-deployment moment. The work isn't done. It's just starting. The next 90 days are where most companies decide whether to finish it, or to kick the can down to whoever inherits the system in eighteen months.
What Okta gave you
Worth naming explicitly. The deployment delivered four things.
Federated authentication. SAML and OIDC for the apps that support either. SSO across the long catalog of integrations Okta maintains. Users get one set of credentials instead of forty.
MFA enforcement. Centrally configured, applied across all federated apps. The most important security baseline a company gets from SSO.
A directory of users. Okta becomes the system of record for who exists, what groups they belong to, what apps they can authenticate against.
Some provisioning. Where apps expose SCIM at the plan tier you're paying for, Okta creates, modifies, and deactivates users automatically. Plus Lifecycle Workflows for orchestrating multi-step automations across the SCIM-supported set.
These are real. They're the right foundation. The deployment was a good decision.
What Okta doesn't do
The gaps aren't bugs. They're scope decisions Okta made early and shipped consistently. Understanding them isn't disparaging Okta. It's understanding where the identity work stops being Okta's problem.
The 80% of apps Okta can't reach via SCIM. The mid-market SaaS stack is roughly 20% SCIM-supported at standard plan tiers. The remaining 80% includes Notion, Linear, Asana, Miro, most internal admin panels, most legacy systems, every app on a standard plan that gates SCIM behind enterprise. Okta SSO can federate logins to these. Okta lifecycle can't provision them.
Group-level governance only. Okta certifications and access reviews operate at the Okta Group level. Whether someone is in the "Engineers" group, not whether they should have admin on a specific staging environment or write access to a specific repo.
Contractor lifecycle as a Workflows DIY. Okta doesn't model contractors as a first-class identity. You build it with Workflows, or you don't have it.
Non-human identity outside ISPM. Okta's Identity Threat Protection provides observability over Okta-managed assets. It doesn't extend to lifecycle for service accounts, API keys, OAuth grants, or AI agents.
Access review scale. Okta IGA (the add-on) caps at two reviewer levels and 250 apps per certification campaign. The action is remove-only.
Audit evidence assembly. Okta exports CSVs. Pushing continuous evidence into Drata, Vanta, or Secureframe with control mapping is work that lives downstream of Okta.
If you bought Okta, you got the first column. The second column is what teams typically discover in the first 90 days.
The 90-day decision tree
The post-deployment period is where the most consequential identity choices get made or deferred. Three forks.
Fork 1: how to govern the non-SCIM 80%
Three options.
Manual processes. Spreadsheet access reviews, Slack-based access requests, runbook offboarding for the non-SCIM apps. Common for companies under 200 employees. Works until it doesn't, usually around the first compliance audit.
Workflow buildout. Lifecycle Workflows for as many non-SCIM apps as can be cobbled together. Custom code via Workflows API for the rest. High maintenance, high vendor lock-in (Okta-specific work that doesn't move if you change SSO).
Dedicated IGA layer. A tool sits on top of Okta and handles governance for the apps Okta doesn't reach. This is the category Iden lives in.
The choice depends on stack complexity, compliance pressure, and how much engineering bandwidth you can defend for identity work. Most teams between 50 and 500 employees end up at the third option within twelve months of the Okta deployment.
Fork 2: contractor and NHI lifecycle
Decide whether contractors and non-human identities are in scope for identity governance from day one. If yes, neither Okta SSO nor Okta IGA models them as first-class identities. You need a layer that does.
If you defer, the cost is that the contractors and the agents accumulate as ungoverned identities. The remediation later is harder than the prevention now.
Fork 3: compliance evidence path
If you have a SOC 2, ISO 27001, or HIPAA program (current or upcoming), decide who owns the evidence pipeline. Drata, Vanta, and Secureframe handle the framework side. Okta exports CSVs that someone has to package for those platforms. Iden and similar tools push continuous evidence with control mapping automatically.
Compliance teams discover this gap at audit prep. Best to make the choice before the gap shows up under deadline pressure.
Common patterns we see in the field
A few configurations of the post-Okta state.
The Workflows-as-bandage path. Team uses Lifecycle Workflows extensively to compensate for missing SCIM coverage. By month six, the Workflows team has fifty flows in production and a queue of bugs. By month twelve they've quietly started looking for what Iden does.
The "we'll get to it" path. Manual processes for the non-SCIM apps, with the team assuming the gap will close naturally. It doesn't. The audit findings or the headcount-growth wall forces the decision twelve months later, often during a quarter that needed to be quiet.
The early-IGA path. Team adds an IGA layer within 60 days of the Okta deployment. Usually because someone on the team has been through this before. The Okta deployment doesn't get celebrated as the finish line. It gets celebrated as Phase 1 of 2.
The hybrid Okta IGA + dedicated tool path. Some teams add Okta IGA for the SCIM-supported certifications and a dedicated layer for the rest. Common when the team is already comfortable in Okta's UI and wants the consolidation in one vendor for the parts Okta covers well.
Where Iden fits
Iden is the layer most teams need but didn't know to scope at deployment time. It plugs into Okta as the IdP, reads the HRIS, and runs governance across the apps Okta can't reach via SCIM. The Workflows you built for actual business logic stay. The Workflows you built to compensate for missing connectors retire.
If you're past the Okta deployment and looking at the gap list, the work isn't to redo authentication. It's to add the governance layer Okta wasn't designed to be. The next 90 days is when most teams make that call.