Okta and Microsoft 365: get Microsoft’s security without giving up Okta

The two posts we published on this in 2025 were written while some of these capabilities were still in preview. This is the updated guide, the one we follow in Microsoft 365 security projects for customers who use Okta.

The three options at a glance

Option	How it works	When it fits
1. Okta authenticates Microsoft 365 (federation)	Entra ID trusts Okta for sign-in. Conditional Access still applies	When Okta must stay the primary identity provider
2. Entra ID authenticates Okta	The user goes to Okta, is sent to Entra ID, checked by Conditional Access and Intune, and returns to Okta	When you want Conditional Access and Intune to protect the apps connected to Okta too
3. Okta Verify as external MFA	Entra ID verifies the password, and Okta Verify is used for the second factor	When users are managed in Entra ID but are used to Okta Verify

Option 1: Okta authenticates Microsoft 365 (federation)

Conditional Access still applies to Microsoft 365. For Okta’s MFA to count in Entra ID, set federatedIdpMfaBehavior to enforceMfaByFederatedIdp.
Limit: authentication strengths don’t work as usual. Only the "federated multifactor" combination can be required.
Limit: leaked-credentials detection in Entra ID Protection requires password hash sync.
Microsoft describes federation as optional rather than recommended, and documents a staged migration from Okta federation to Entra ID.

Option 2: Entra ID as Okta’s identity provider

In Entra ID you register Okta as an app, and in Okta you add Microsoft as an identity provider. From then on, anyone signing in to Okta is sent to Entra ID, and Conditional Access, Intune and ID Protection evaluate the sign-in before the user returns to their Okta apps.

Okta routing rules decide who is sent to Microsoft: by network, platform, app or user attributes. That lets you start with a pilot group.
Use a custom OIDC IdP locked to your tenant. Okta’s built-in Microsoft IdP uses a common endpoint, so accounts from other tenants and personal Microsoft accounts can sign in too.
Don’t route users to Microsoft while their domain is still federated to Okta. It creates a loop. Remove the federation first, following Microsoft’s guide.
Make sure the user name (UPN) matches on both sides, or pick another shared attribute.
This option puts Entra ID in front of the Okta sign-in. It doesn’t bring the permissions inside Okta apps under PIM or access reviews.

Option 3: Okta Verify as external MFA

External MFA, previously called external authentication methods, has been generally available since early 2026. Entra ID verifies the first factor, Conditional Access decides MFA is needed, and the user approves in Okta Verify as usual.

Requirements: Entra ID P1 or P2, and the first factor must be verified in Entra ID. In Okta you add the Microsoft Entra ID External Authentication Methods app from the catalog and map each user to their Entra Object ID.
What it covers: the "Require multifactor authentication" grant in Conditional Access. It does not satisfy authentication strengths, including the built-in MFA strength.
Other limits: not supported during Windows 10 out-of-box setup (Windows 11 is needed), and admin consent to the provider’s app is required.
Custom controls are being retired: from September 2026 they can’t be added or edited, and they’re removed in 2027. If you connect Okta to Entra through custom controls, move to external MFA.

What you gain: automatic response that only works when Entra ID is in control

The main reason for all of this is the loop between Defender, Intune and Conditional Access, for apps Entra ID protects:

Defender detects risk on a device. For example malware or suspicious behavior.
Intune marks the device non-compliant. The compliance policy sees the risk level.
Conditional Access blocks access. From that device to cloud services, until the issue is resolved.
Defender remediates and clears the risk. And access comes back automatically, with no helpdesk ticket.

How to start

Map where you are today. Who authenticates Microsoft 365, where MFA happens, and which apps are connected to Okta.
Pick an option. Usually option 2, sometimes together with option 3.
Start with a pilot. A small group through routing rules, and Conditional Access policies in report-only mode.
Check the sign-in logs. In Entra ID and in Okta, before you tighten anything.
Expand gradually. And tell users in advance that they’ll be asked to sign in through Microsoft.

Using Okta and want Microsoft’s Conditional Access and Intune? At OnCloud we design and deploy the integration between Okta and Entra ID, from pilot to the whole organization.