Okta, 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.
GA Aug 2026, built on the Cross App Access standard
release watch
Okta for AI Agents generally availableApr 2026
Agent SSO generally availableAug 2026
connects with
in short·15-second read
Cohash implements and tunes Okta Workforce Identity.
That means migrating applications to Okta SSO, designing authentication policies and phishing-resistant MFA, automating provisioning from HR and setting up Okta Identity Governance. For AI agents, we register them in Okta for AI Agents, GA since April 2026, and connect them through Agent SSO. Agent SSO is built on the Cross App Access standard.
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.
Apr 2026Okta for AI Agents generally available You get agent identity management, plus a browser plug-in that discovers shadow AI. Agents can be put through access requests and certifications too. source ↗
Aug 2026Agent SSO generally available Built on the Cross App Access standard. Agent-to-Agent Connections beat it to GA by about a month. source ↗
Sep 2026September 2026 agent releases GA now: certification of AI agent resource connections, MCP servers from the OIN catalog and DCR for MCP servers. Agent Gateway is only listed as GA soon. source ↗
today · Oct 22, 2026
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.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · okta estate3 open
openAD FS still fronts a few dozen apps and nobody wants to be the one who turns it off.
recurringUsers approve MFA pushes they didn't start, and the only fix so far has been a training email.
blockedLeavers keep SaaS access for days because deprovisioning waits on someone closing a ticket.
exposure
SSO and application migrationAuthentication policy and MFALifecycle managementOkta Identity GovernanceAI agents in OktaHealth checks
startrehearsehandover
Org health check
Migration waves
Phishing-resistant sign-in
HR-driven lifecycle
Agents and handover
we are here
ready to hand over
Apps move over on a repeatable pattern with custom claims documented.
Every agent has an owner and gets reviewed on a cycle.
Application inventory with protocol, owner and migration wave per app
Authentication policy set with documented exceptions and a FastPass rollout plan
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.
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
chapter 03 · how it runs
Our approach
Org health check
Migration waves
Phishing-resistant sign-in
HR-driven lifecycle
Agents and handover
chapter 04 · where you end up
What changes
Apps move over on a repeatable pattern with custom claims documented.
Every agent has an owner and gets reviewed on a cycle.
Application inventory with protocol, owner and migration wave per app
Authentication policy set with documented exceptions and a FastPass rollout plan
what we do
Our Okta work
6 kinds of Okta work, each run by engineers who have done it on live tenants.
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.
Global session and app sign-in policies, an Okta FastPass and FIDO2 rollout, and a plan for the users who can't use either.
HR-driven provisioning from Workday or another source of truth, with SCIM to downstream apps and access removed on the leaver's last day.
Access requests, certification campaigns and entitlement management configured in Okta, sized so reviewers actually finish them.
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.
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.
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.
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
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.
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.
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 running on personal API tokens with no owner of record
composite · not a client story
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.
What we dothe work
We register each agent in Okta for AI Agents with an owner. Where the apps support it, we connect it through Agent SSO or agent-to-agent connections. Its resource connections go into certification campaigns, and as each agent moves, its personal tokens are revoked.
Afterwhere you end up
Every agent has an owner and gets reviewed on a cycle. Its access ends when the owner leaves or the agent retires, and nobody integrates with personal tokens any more.
We don't start a step until the last one has produced something you can check.
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.
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.
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.
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.
step 05
Agents and handover
We register AI agents in Okta for AI Agents, each with an owner and its connections. Then your team gets the policies, runbooks and the Terraform configuration for your org.
ai on okta
Where AI fits on Okta, and where it needs guardrails.
Okta built agent identity into Workforce Identity, starting with Okta for AI Agents (GA April 2026). Agent SSO came in August and certification of agent resource connections in September. Okta also publishes an official MCP server for its admin APIs. With this, agents have owners, scoped access and reviews, and you can retire personal API tokens.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Oktadoes the work
Okta publishes an official MCP server for its Admin Management APIs, and it's GA. We set it up with Private Key JWT on an API Services app and grant only the okta.* scopes needed, since tools without a scope are removed. Manage scopes stay off by default. We also watch the Management API rate limits.
Okta for AI Agents
It covers agent identities (each with an owner), shadow AI discovery via a browser plug-in, and access requests and certifications for agents. Our part is registering every agent with an owner and adding its resource connections to your campaigns.
Agent SSO and agent-to-agent connections
Agent SSO has been GA since August 2026. It's built on the Cross App Access standard and only works where the target app supports it. So we work out which apps do and connect those first. Everything else gets scoped tokens with a named owner.
MCP servers from the OIN catalog
Since September 2026 you can add MCP servers from the OIN catalog and use dynamic client registration for MCP servers. We register the MCP servers your agents use so access to them goes through Okta policy.
Okta MCP server for admin work
Okta's official MCP server covers users, groups, apps, policies and logs. Delete and deactivate actions ask for confirmation. We'd start it read-only for helpdesk and audit questions and add manage scopes only where a change process exists.
Where Okta sits between your workforce and your apps
HR and Active Directory feed Okta the people it should know about, and Okta decides how each person or registered agent signs in. It then federates and provisions every downstream app, with Okta Identity Governance reviewing who keeps access.
These are working documents, written against your configuration, so your team can run them without us.
inventory01
Application inventory with protocol, owner and migration wave per app
yours to keep
plan02
Authentication policy set with documented exceptions and a FastPass rollout plan
yours to keep
inventory03
HR-driven lifecycle design with attribute mappings and leaver timing
yours to keep
report04
Admin role review with least-privilege custom roles
yours to keep
plan05
Agent registry with owners, Agent SSO connections and a review schedule
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.
Put these to anyone bidding on your Okta work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you group our AD FS relying parties into migration waves?
Plain SAML trusts move quickly, while custom claim rules and WS-Fed apps take longer. A wave plan that starts with the hard ones stalls the program in its first month.
Q2
Which users can't use FastPass or FIDO2, and what will they use instead?
Shared workstations, contractors and unmanaged devices often fall outside phishing-resistant MFA. The fallback factor and its policy decide your real exposure.
Q3
How will leavers lose access on their last day, not when someone notices?
HR-driven deprovisioning depends on attribute timing and SCIM coverage per app. Apps without SCIM need a ticket or a scheduled report, or the account lives on.
Q4
Which of our agents can use Agent SSO today, and which need another pattern?
Agent SSO is built on Cross App Access, which needs support on both sides. Apps without it still need scoped tokens and an owner, and the design should say how.
Q5
How will you review our Okta admin roles and API tokens?
Super admin sprawl and old API tokens turn up in health checks all the time. Custom admin roles and token rotation limit what a stolen session can do.
01What does Okta for AI Agents add?
It gives AI agents their own identities in Okta, with an owner, access policies and an audit trail. Okta marked it generally available in April 2026, then added Agent SSO, agent-to-agent connections and certification of agent resource connections over the following months.
02How 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.
03Should 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.
04Do you also work on Auth0?
Yes, that's Auth0, Okta's customer identity platform. We implement it for consumer and B2B applications.
05Can you clean up an Okta tenant someone else set 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.
