access management

Okta Agent SSO and Workforce Identity, set up so sign-in policy matches how people really work.

We implement and tune Okta Workforce Identity, covering SSO, MFA, lifecycle management and governance. We also bring AI agents into Okta, now that Okta for AI Agents and Agent SSO are generally available.

platform dossierOktaAccess management
Retired
Connect with Okta and its connections API, Identity Engine 2026.44.0
Deployment
SaaS
Agent identity
Okta for AI Agents, GA Apr 2026
Agent SSO
GA Aug 2026, in core SSO plans, Cross App Access agents only
release watch
  • Connect with Okta retired in Identity Engine 2026.44.03 Nov 2026
  • Okta for AI Agents generally availableApr 2026
connects with
in short·15-second read

Okta Agent SSO lets AI agents that support Cross App Access sign in to enterprise apps and MCP servers through Okta, using short-lived tokens instead of stored credentials.

It comes with core Okta SSO plans. Cohash registers your agents, connects their apps and sets the policies. We also run Okta Workforce Identity rollouts and Classic Engine upgrades.

you probably need this if
  • AD FS still fronts a few dozen apps and nobody wants to be the one who turns it off.
  • Users approve MFA pushes they didn't start, and the only fix so far has been a training email.
  • Leavers keep SaaS access for days because deprovisioning waits on someone closing a ticket.
terms on this page Cross App AccessdefinitionAn IETF draft that Okta's Agent SSO is built on. The agent trades a user's sign-in assertion for a token to another app, and nobody sees a consent screen.explained in a field note →Classic EnginedefinitionOkta's older sign-in engine. You can tell an org runs it when the version in the Admin Console footer ends in C.explained in a field note →Identity EnginedefinitionOkta's newer sign-in engine, where passwordless sign-in and the new device checks live. If the Admin Console version ends in E, you're already on it.explained in a field note →Identity governancedefinitionThe tools and process that decide who should have what access, grant and remove it as people join, move and leave, and prove it to auditors. Often shortened to IGA.explained in a field note →MFAdefinitionMulti-factor authentication. On top of the password you prove it's you a second way, usually with an app prompt or a security key.explained in a field note →
Ask an engineer facts checked 2026-11-06
how it runs
  1. 01Org health check
  2. 02Migration waves
  3. 03Phishing-resistant sign-in
  4. 04HR-driven lifecycle
  5. 05Agents and handover
you keep
  • A sheet of every app with its protocol and owner. Each app gets a wave, so the order is agreed before anything moves.
  • Sign-in policies where someone has written down why each exception exists, plus the order groups switch to FastPass
  • HR-driven lifecycle design with attribute mappings and leaver timing
+ 2 more documents
who does it
Okta Workforce Identity engineerOkta Workflows developerOkta integration developer (SAML, OIDC, SCIM) Okta Certified Professional Okta Certified Administrator
okta · release timeline
  1. Apr 2026 Okta for AI Agents generally available Okta now treats agents as identities with their own management. There's a browser plug-in for finding shadow AI too. Agents can sit in access requests and certification campaigns next to people.
  2. 24 Aug 2026 Agent SSO generally available It's part of core Okta SSO plans and built on the Cross App Access standard. Only agents that speak Cross App Access can use it, so the rest still run on tokens someone has to own. Agent-to-Agent Connections went GA a month earlier.
  3. Sep 2026 Agent Gateway and agent registration options generally available Agent Gateway is a proxy that sits between your agents and the tools they call. Teams registering MCP servers can use dynamic client registration now. An agent can also point Okta at a Client ID Metadata Document by URL, so nobody has to hand out a static client ID.
  4. 13 Oct 2026 October 13 advisory batch for agents and SDKs Seven advisories in one day: the Credential Provider for Windows, two for the RADIUS Agent, and the auth0.js, auth0-lock, java-jwt and nextjs-auth0 libraries. The SDK ones won't show up in the Okta admin console. Your developers have to bump the dependency.
  5. 22 Oct 2026 Okta Access Gateway fixes, September and October 2026 Check your Access Gateway build before anything else if you still run it on premises. 2026.9.1 fixes the September advisories. You need 2026.10.2 for the two from 22 October, one of them an admin-console command execution flaw scored 9.1, and 2026.44.0 for the PHP2Shell fix in the appliance's PHP runtime.
  6. 3 Nov 2026 Connect with Okta retired in Identity Engine 2026.44.0 If an agent's Cross App Access integration has stopped working, look here first. Okta pulled this Early Access feature in the release deployed on 3 November, along with the Manage Connections tab on app profile pages and the /api/v1/apps/{appId}/cwo/connections API. Configurations built with it no longer function, so Okta tells you to reconfigure each one with an AI agent-to-app resource connection in the Admin Console.
  7. today · Nov 09, 2026
  8. 5 Mar 2027ahead Classic Engine features lose support on 5 March 2027 Self-Service Registration, Desktop SSO (IWA) and Device Trust stop being supported on Classic Engine that day. Okta's answer is to upgrade to Identity Engine and switch to Profile Enrollment, Agentless Desktop SSO or FastPass, and management attestation with Okta Verify. Orgs that still lean on IWA have the most rework.
the story · okta estate

From the first call to a setup your own team can run.

Here's what usually prompts a call about your Okta estate, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • AD FS still fronts a few dozen apps and nobody wants to be the one who turns it off.
    • Users approve MFA pushes they didn't start, and the only fix so far has been a training email.
    • Leavers keep SaaS access for days because deprovisioning waits on someone closing a ticket.
  2. chapter 02 · what we change

    How we solve it

    • SSO and application migration
    • Authentication policy and MFA
    • Lifecycle management
    • Okta Identity Governance
    • AI agents in Okta
    • Health checks
  3. chapter 03 · how it runs

    Our approach

    • Org health check
    • Migration waves
    • Phishing-resistant sign-in
    • HR-driven lifecycle
    • Agents and handover
  4. chapter 04 · where you end up

    What changes

    • Apps move over on a repeatable pattern with custom claims documented.
    • Every agent has an owner now and comes up for review on a schedule.
    • A sheet of every app with its protocol and owner. Each app gets a wave, so the order is agreed before anything moves.
    • Sign-in policies where someone has written down why each exception exists, plus the order groups switch to FastPass
what we do

Our Okta work

6 kinds of Okta work, each run by engineers who have done it on live tenants.

  1. SAML and OIDC apps moved from AD FS, Ping or a legacy portal into Okta, grouped so each wave can be tested and rolled back.

  2. Global session and app sign-in policies, an Okta FastPass and FIDO2 rollout, and a plan for the users who can't use either.

  3. HR-driven provisioning from Workday or another source of truth, with SCIM to downstream apps and access removed on the leaver's last day.

  4. Access requests, certification campaigns and entitlement management configured in Okta, sized so reviewers actually finish them.

  5. Agents registered with owners, Agent SSO and agent-to-agent connections configured, MCP servers added from the OIN catalog, and agent resource connections included in certification campaigns.

  6. A review of policies, groups, rules and admin roles, with a ranked list of fixes and the riskiest settings first.

capability 01 / 06in production

SSO and application migration

SAML and OIDC apps moved from AD FS, Ping or a legacy portal into Okta, grouped so each wave can be tested and rolled back.

capability 02 / 06in production

Authentication policy and MFA

Global session and app sign-in policies, an Okta FastPass and FIDO2 rollout, and a plan for the users who can't use either.

capability 03 / 06in production

Lifecycle management

HR-driven provisioning from Workday or another source of truth, with SCIM to downstream apps and access removed on the leaver's last day.

capability 04 / 06in production

Okta Identity Governance

Access requests, certification campaigns and entitlement management configured in Okta, sized so reviewers actually finish them.

capability 05 / 06in production

AI agents in Okta

Agents registered with owners, Agent SSO and agent-to-agent connections configured, MCP servers added from the OIN catalog, and agent resource connections included in certification campaigns.

capability 06 / 06in production

Health checks

A review of policies, groups, rules and admin roles, with a ranked list of fixes and the riskiest settings first.

typical situations

Okta situations we walk into

We pieced these together from Okta situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

180 AD FS relying parties and no appetite for a cutover night

composite · not a client story
  1. Beforethe situation

    AD FS serves 180 relying-party trusts, about 30 with custom claim rules written by someone who has since left. Okta is licensed, but only a handful of apps have moved, because each migration has been a one-off.

  2. What we dothe work

    We export the trusts and claim rules, group apps by pattern, and move plain SAML apps first in waves with a rollback per app. Custom-claim apps are rebuilt with Okta expressions and tested with their owners. AD FS goes off only when its logs show no traffic.

  3. Afterwhere you end up

    Apps move over on a repeatable pattern with custom claims documented. The AD FS servers go once the logs prove nothing is still using them.

case file 02

Agents wired in with personal API tokens, some from people who've left

composite · not a client story
  1. Beforethe situation

    Teams connect AI agents to Salesforce, Jira and Google Workspace with personal API tokens belonging to whoever set them up. Some of those people have left. Security has no list of which agents even exist.

  2. What we dothe work

    We register each agent in Okta for AI Agents and give it a named owner. Where the app supports it, the agent connects through Agent SSO. Its connections go into the next certification campaign, and we revoke the personal tokens as each agent moves over.

  3. Afterwhere you end up

    Every agent has an owner now and comes up for review on a schedule. When the owner leaves or the agent retires, its access goes too, and nobody wires agents in with personal tokens any more.

case studies

Okta case studies

All case studies
consolidation Identity and access

Consolidating Okta and Entra ID after years of running both

Picking one primary identity provider after years of running Okta and Microsoft Entra ID side by side, then moving apps, MFA and provisioning to it.

read the case study
migration Identity and access

On-premises Active Directory to cloud-first Microsoft Entra ID

We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.

read the case study
migration Identity and access

AD FS federation to Entra ID authentication

Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.

read the case study
upgrade Identity and access

Moving Auth0 Rules and Hooks to Actions before Auth0 switches them off

Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.

read the case study
modernization Privileged access

Centrify alternatives, and how we untangle Server Suite zones

Untangling Centrify and Delinea Server Suite zones, UID maps and dzdo roles, and moving Linux and Windows servers to a server identity model you can run.

read the case study
modernization Cloud and infrastructure

Hand-built cloud to Terraform or OpenTofu

Bringing console-built AWS, Azure and Google Cloud resources under Terraform or OpenTofu with import blocks, clean state and pipelines, without rebuilding.

read the case study
approach

How a Okta engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Org health check

    First we review sign-in policies, group rules, admin roles, app assignments and the System Log. The riskiest settings go to the top of the list.

  2. step 02

    Migration waves

    We group the apps leaving AD FS or another identity provider by protocol and owner. Each wave gets test users and a rollback step.

  3. step 03

    Phishing-resistant sign-in

    We roll out Okta FastPass and FIDO2 group by group and tighten authentication policies as enrollment grows. For shared and kiosk devices, we agree a fallback.

  4. step 04

    HR-driven lifecycle

    Workday or another HR system set as profile source, SCIM provisioning turned on app by app, and deprovisioning tested against real leaver dates.

  5. step 05

    Agents and handover

    We register your AI agents in Okta for AI Agents and give each one an owner. Then we hand over the policies, runbooks and Terraform configuration, so your team can run it without us.

architecture

Okta in the middle: HR and AD feed it, and it signs people into every app

HR and Active Directory tell Okta who should exist, and Okta decides how each person or registered agent signs in. Then it federates and provisions every app downstream, while Okta Identity Governance checks who keeps access.

Okta in the middle: HR and AD feed it, and it signs people into every app HR and Active Directory tell Okta who should exist, and Okta decides how each person or registered agent signs in. Then it federates and provisions every app downstream, while Okta Identity Governance checks who keeps access. 01 · SOURCES AND SIGN-IN 02 · OKTA 03 · APPLICATIONS profile source import · delegated auth sign-in Agent SSO SAML · SCIM SAML · SCIM SAML · SCIM entitlements HR system Workday · UKG Active Directory through the Okta AD agent Employees and contractors FastPass · FIDO2 keys AI agents registered with an owner Okta WorkforceIdentity SSO · MFA · LifecycleManagement Okta IdentityGovernance requests ·certifications SaaS apps Slack · Google Workspace ·Zoom Sf Salesforce profiles · permissionsets AWS IAM Identity Center © Cohash · cohash.com
01 · SOURCES AND SIGN-IN02 · OKTA03 · APPLICATIONS HR system: Workday · UKG HR system Workday · UKG Active Directory: through the Okta AD agent ActiveDirectory through the OktaAD agent Employees and contractors: FastPass · FIDO2 keys Employees andcontractors FastPass · FIDO2keys AI agents: registered with an owner AI agents registered with anowner Okta Workforce Identity: SSO · MFA · Lifecycle Management Okta WorkforceIdentity SSO · MFA ·Lifecycle… Okta Identity Governance: requests · certifications Okta IdentityGovernance requests ·certifications SaaS apps: Slack · Google Workspace · Zoom SaaS apps Slack · GoogleWorkspace ·Zoom Salesforce: profiles · permission sets Salesforce profiles ·permission sets AWS: IAM Identity Center AWS IAM IdentityCenter profile source import · delegated auth sign-in Agent SSO SAML · SCIM SAML · SCIM SAML · SCIM © Cohash · cohash.com
use cases

Typical Okta projects

The work teams usually bring us, and the platforms Okta has to talk to while we do it.

  1. OKT-01 You're moving off AD FS and want the migration done in testable waves common request
  2. OKT-02 You haven't moved to Identity Engine yet, and Desktop SSO, self-service registration or Device Trust still matter to you common request
  3. OKT-03 MFA push fatigue is a live risk and you want phishing-resistant sign-in common request
  4. OKT-04 Leavers keep access to SaaS apps for days after they go common request
  5. OKT-05 Teams are building AI agents that need corporate app access, and nobody has said who owns them common request
  6. OKT-06 Access reviews exist in Okta but nobody finishes them common request
you keep

What a Okta engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • document01

    A sheet of every app with its protocol and owner. Each app gets a wave, so the order is agreed before anything moves.

    yours to keep
  • guide02

    Sign-in policies where someone has written down why each exception exists, plus the order groups switch to FastPass

    yours to keep
  • inventory03

    HR-driven lifecycle design with attribute mappings and leaver timing

    yours to keep
  • document04

    A cut-down admin list: most super admins move to custom roles that only hold what that person actually uses

    yours to keep
  • report05

    An owner for every agent and a note of which apps it signs in to. The next access review starts from that list.

    yours to keep
talent and delivery · okta

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • Okta Certified ProfessionalOkta
  • Okta Certified AdministratorOkta
  • Okta Certified ConsultantOkta
  • Okta Certified DeveloperOkta
roles we staff
  • Okta Workforce Identity engineer
  • Okta Workflows developer
  • Okta integration developer (SAML, OIDC, SCIM)
  • Okta Identity Governance engineer
  • IAM architect for Okta migrations
  • Okta administrator
01We set up Cross App Access with Connect with Okta. Why did it stop working?

Okta retired that Early Access feature in Identity Engine 2026.44.0, along with the Manage Connections tab and the cwo/connections API. Anything built with it no longer functions. Reconfigure each integration with an AI agent-to-app resource connection in the Admin Console, and find any script that still calls the old API, because Okta has retired that too.

02We're on Classic Engine. When do Desktop SSO, self-service registration and Device Trust stop being supported?

On 5 March 2027. Okta wants those orgs on Identity Engine by then. Someone on your side still has to rebuild registration as a Profile Enrollment policy and replace IWA with Agentless Desktop SSO or FastPass. Start with the Desktop SSO users, because they notice first.

03We run Okta Access Gateway. Which version fixes the October 2026 advisories?

2026.10.2 fixes the two OAG advisories from 22 October, and 2026.44.0 carries the patched PHP runtime for the PHP2Shell flaws. Okta says the default configuration mitigates known exploitation of the PHP flaws, but don't count on your appliance still being default. Upgrade, then trim the list of people with admin console access, because the 9.1 flaw needs an admin login.

04We already pay for Okta SSO. Is Agent SSO included, or do we need Okta for AI Agents?

Agent SSO puts each agent in Okta's directory and gives it short-lived tokens for apps that support Cross App Access, so nobody pastes a personal API token into it. It's part of core Okta SSO plans. Okta for AI Agents is a separate subscription. You'd buy it to find shadow agents, reach service accounts and custom authorization servers, and put agents through access reviews with a kill switch. One catch: the AI Agent Admin role can't manage Agent SSO, so registration still takes a super admin.

05How long does an AD FS to Okta migration take?

It depends on how many relying-party trusts you have and how many use custom claim rules. We inventory them first, move simple SAML apps in the early waves, and leave the complex ones for later once the pattern is proven.

06Should we use Okta Identity Governance or a separate IGA platform?

Okta Identity Governance suits companies with apps already in Okta and moderate audit needs. Heavy ERP separation-of-duties rules or lots of on-premises systems usually point to SailPoint or Saviynt. We compare against your audit scope before we recommend either.

07Someone else set up our Okta tenant. Can you clean it up?

Yes. We start with a health check of policies, groups and rules, admin roles and API tokens. Fixes get ranked by risk. Nothing changes in production until we've agreed the order with your team.

services

Related services

Projects on Okta usually end up touching one of these, so they're worth a look.

fact-checked Checked against vendor and official documentation last checked 2026-11-06 content fingerprint 135bd122
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Okta is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it