Consolidating Okta and Entra ID after years of running both
Cohash helps organizations that run both Okta and Microsoft Entra ID pick one as the primary identity provider and move to it. We map which platform is authoritative for sign-in, MFA, provisioning and agents today, then compare the two on your apps and licenses. Applications, factors and SCIM provisioning move in waves. The other platform is retired, or kept for a stated purpose with an owner.
- 01Map who owns what
- 02Inventory apps with real usage
- 03Decide the target
- 04Move factors and devices
- 05Move apps and provisioning in waves
- 06Retire or scope the other platform
The story
Told without the client's name or anything that could identify them.
A healthcare group's identity team had run Okta and Entra ID side by side for years. Microsoft 365 sign-in was federated to Okta while Entra ID held Conditional Access, devices and Copilot licensing, and a few SaaS apps took SCIM from both. Two renewals were landing in the same year and AI agents were being registered wherever their builders preferred, so finance and security both wanted one answer. We merged the Okta System Log and Entra sign-in logs into one app inventory, wrote up both options, and moved factors, apps and provisioning in waves. Entra ID became the primary identity provider, with the Microsoft 365 domain converted to managed authentication last.
why it was urgentBoth vendors shipped AI agent identity in 2026. Okta for AI Agents reached general availability in April and Agent SSO in August, while Microsoft Entra Agent ID added Conditional Access for agents in July and changes agent consent rules on 4 November 2026. Running two identity providers now means registering, governing and reviewing every agent twice.
- openMicrosoft 365 sign-in is federated to Okta while Entra ID holds Conditional Access, devices and Copilot licensing.
- recurringSome SaaS apps provision from Okta, others from Entra ID, and a few from both.
- blockedUsers carry Okta Verify and Microsoft Authenticator side by side, and the help desk has to reset both.
- openTwo identity renewals land in the same year and finance has asked why.
- recurringAgents get registered in Okta or in Entra ID, depending on which team built them.
The estate, before and after
Before: two identity providers doing the same job
Before: users signed in through Okta and Entra ID, with Microsoft 365 federated from Entra ID to Okta. A few SaaS apps took SCIM from both platforms, and agents were registered in whichever one their builders chose.
Read the diagram as text
- Workforce users → Okta: sign-in
- Workforce users → Entra ID: sign-in
- AI agents → Okta: agent registration
- AI agents → Entra ID: agent registration
- Entra ID → Okta: M365 domain federation
- Entra ID → Microsoft 365: token
- Okta → SaaS apps: SCIM
- Entra ID → SaaS apps: SCIM
After: Entra ID as the one primary identity provider
Everything goes through Entra ID now, whether it's a user, a device or an agent. Microsoft 365 uses managed authentication, and SaaS apps get SSO and SCIM from Entra ID alone. Okta is gone, or kept for one named purpose.
Read the diagram as text
- Workforce users → Entra ID: sign-in and MFA
- Managed devices → Entra ID: device trust
- AI agents → Entra ID: agent registration
- Entra ID → Microsoft 365: managed auth
- Entra ID → SaaS apps: SSO and SCIM
- Entra ID → Okta for a named purpose: scoped use
How we run it, phase by phase.
6 phases take you from Okta and Entra ID running side by side to One primary identity provider. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Map who owns what
For each user population we record which platform does sign-in, MFA and device trust, and which one owns provisioning, lifecycle workflows, access reviews and agent registration. If there's federation between the two, in either direction, we draw it.
- phase 02
Inventory apps with real usage
One app list, built from the Okta System Log and Entra sign-in logs, with protocol, sign-in count, provisioning method and owner for each app. Anything with zero sign-ins over the review period goes on the retirement pile.
- phase 03
Decide the target
The choice is made on your facts. That means Microsoft 365 depth, device management, non-Microsoft SaaS coverage, Okta Workflows usage, governance needs and contract dates. We write up both options, with what each one costs to leave behind.
- phase 04
Move factors and devices
Users enroll in the target's MFA and passkey methods before their apps move. We rebuild device trust and Conditional Access or Okta policies, and run them in report-only or audit mode first.
- phase 05
Move apps and provisioning in waves
We move SAML and OIDC apps one owner group at a time, switching each app's SCIM to a single source on a recorded date. Federated Microsoft 365 is the exception. If Entra ID is the target, that domain converts to managed authentication at the very end.
- phase 06
Retire or scope the other platform
The second platform goes at renewal. It can stay for a named purpose, customer identity or a subsidiary for example, but then it gets an owner and a review date.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Each app has one provisioning source
Each app now gets SCIM from one platform only, switched over on a recorded date. Accounts stopped flipping between attribute values, and the wrong side can't deprovision anyone.
- result 02
Users enroll one set of factors
Group by group, users switched to the target's MFA and passkeys before their apps moved. One authenticator for the help desk to support, where there used to be two.
- result 03
Agents are registered in one place
Agents and MCP servers live in a single platform now, each with an owner and scopes. The unclaimed agents were switched off.
- result 04
Microsoft 365 uses managed authentication
The Microsoft 365 domain stopped depending on Okta federation. That change ran in its own window, rollback plan ready.
- result 05
The second platform is retired or has a named job
We shut Okta down at renewal, or keep it for a stated purpose with an owner and a review date. The automation it carried has been rebuilt or retired.
Risks we plan for
-
Provisioning from two sources
When both platforms push SCIM to the same app, accounts flip between attribute values or get deprovisioned by the wrong side. One source per app is set before any wave starts.
-
Federated Microsoft 365 domain
If Okta federates your Microsoft 365 domain, changing that touches every mailbox and every Teams sign-in. It gets a change window of its own, with a rollback plan.
-
Automation nobody listed
Okta Workflows, event hooks, Entra lifecycle workflows and custom scripts often carry joiner and leaver logic. Each one is found and rebuilt, or the leaver process quietly breaks.
-
MFA re-enrollment fatigue
Asking every user to enroll a new factor at once floods the help desk. Enrollment runs by group, ahead of each app wave, with a fallback for shared and kiosk devices.
Where AI helps, and where it needs guardrails
Okta for AI Agents registers each agent with an owner and certifies its connections. Microsoft Entra Agent ID uses identity blueprints and sponsors and puts agents under Conditional Access. Pick one place to register agents and MCP servers before the app waves start. Watch 4 November 2026 too. From then Microsoft stops granting AgentIdentity.CreateAsManager automatically, so Entra ID agents that create their own identities need explicit consent. We look for those in the inventory.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Map of sign-in, MFA, provisioning and agent registration by user group, showing which platform owns each
yours to keep - inventory02
Merged app inventory with usage, protocol, provisioning source and owner
yours to keep - report03
Target decision paper covering both options and what each leaves behind
yours to keep - plan04
Wave plan with factor enrollment, app moves and provisioning switch dates
yours to keep - plan05
Retirement or scoped-use plan for the second platform
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Conditional access
- Rules evaluated at each sign-in that look at conditions such as user, device or location, and then allow, block or demand more proof.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
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
01Which one should we keep?
It depends where most of your apps and devices sit, how much you lean on Okta Workflows or Entra ID Governance, and when each contract renews. Estates that are mostly Microsoft tend to pick Entra ID. If you have lots of non-Microsoft SaaS and Okta automation, Okta often wins. We put both cases on paper with your numbers.
02Can we keep both on purpose?
Yes, if each has a clear job, for example Entra ID for workforce and Okta's Auth0 for customers, or one platform for a subsidiary. What causes trouble is two platforms doing the same job for the same users.
03Will users notice the move?
They'll enroll a new factor once and see a different sign-in page. We schedule enrollment ahead of each wave and brief the help desk, so apps keep working on the day they move.
04What about AI agents already registered in both?
We list every agent with its owner and scopes, decide which platform governs agents from now on, and re-register them there. Agents nobody owns get disabled. If someone needs one back, they claim it.
Often on the same roadmap
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 studyAD 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 studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studyfe3aa358 - 01Okta support: What's new in Okta for AI Agentssupport.okta.com ↗
- 02Microsoft Learn: What's new in Microsoft Entra Agent IDlearn.microsoft.com ↗
- 03Message Center MC1395007: Conditional Access and ID Protection for agentsmc.merill.net ↗
- 04Message Center MC1506728: AgentIdentity.CreateAsManager change (4 Nov 2026)mc.merill.net ↗
- 05Microsoft Learn: Migrate from federation to cloud authenticationlearn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- 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