multifactor authentication

Question

Hi All,

I have been asked to enable the below Conditional Access policy, but before proceeding, I would like to understand the possible impact from the Microsoft 365/Entra ID side.

Current environment:

• Okta is used for MFA and SSO
• Intune is used to manage Windows and mobile devices
• Jamf is used to manage macOS devices
• We use Enterprise Applications and App Registrations extensively
• B2B collaboration is enabled for guest accounts
• Users share SharePoint files with guest users externally

Proposed policy configuration:

Microsoft Entra Admin Center 
Conditional Access → Create New Policy 
Assignments → Users: All users (excluding only if necessary) 
Cloud apps: All cloud apps 
Grant controls: Require multifactor authentication OR Require authentication strength 
Enable policy and save

My concerns/questions:

1. Could this conflict with existing Okta MFA/SSO flows?
2. Could it impact Enterprise Applications, app registrations, service accounts, or non-interactive sign-ins?
3. Are there any known issues with Intune-managed or Jamf-managed devices?
4. Could enabling this policy for “All cloud apps” cause authentication loops or unexpected MFA prompts?
5. What exclusions are typically recommended before enabling such a broad Conditional Access policy?
6. Could this impact B2B guest access or external SharePoint sharing scenarios?

Looking for guidance and best practices from anyone who has implemented a similar setup in a hybrid Okta + Entra ID environment

Answer 1

Hello Glenn Maxwell

Thank you for reaching out to Microsoft Q&A.

It sounds like you’re planning to roll out a “Require MFA” Conditional Access (CA) policy across your hybrid Okta + Entra ID environment. Here’s what to watch out for and some best practices folks usually follow:

1. Okta MFA/SSO flows
   • If your users federate to Okta for primary authentication, Entra CA will still evaluate and enforce its own MFA step after the Okta token is issued. In practice you can end up with “double” MFA prompts unless you scope carefully.
   • Best practice: pilot with a small group, confirm your Okta IdP trust and SAML/OIDC flows work end-to-end, then expand.
2. Enterprise apps, app registrations & non-interactive/service accounts
   • Service principals, automation accounts, CI/CD pipelines and other non-interactive flows can break if they hit an MFA gate.
   • Exclude these by: • Using CA filters for “client apps” (e.g. exclude “Service principals”) • Putting SPNs and managed identities into an exclusion group • If you use app passwords or legacy protocols, plan to disable or carve those out.
3. Intune- and Jamf-managed devices
   • Requiring MFA won’t prevent device enrollment or compliance checks, but users will see an MFA prompt at user sign-in.
   • No known blockers with Intune or Jamf – just make sure your device-compliance and CA policies don’t contradict each other (e.g. requiring device compliance + MFA shouldn’t chain loops).
4. Full “All cloud apps” scope & unexpected prompts
   • Applying to “All cloud apps” is fine, but watch out for Microsoft-managed apps (Azure portal, Graph API) and management endpoints. If you protect those without exception, you can lock out admins or break infrastructure automation.
   • Always exclude a break-glass emergency account and exclude the “Azure management” built-in apps or your own admin roles.
5. Typical exclusions before going broadly
   • Break-glass/emergency access accounts
   • Service principals, managed identities, automation/service accounts
   • Legacy/authentication protocols not supporting MFA (Exchange ActiveSync, SMTP, IMAP, POP)
   • Any RADIUS/NPS integration endpoints you need to stay up
6. B2B guests & external SharePoint sharing
   • Guests will also be MFA-challenged if they’re in scope of the policy. You can either: • Create a separate CA policy scoped to “Guests + external users” with its own controls (e.g. lighter enforcement, or OTP via email) • Exclude the “Guest” directory role from your “All users” policy and handle them in a dedicated guest policy

Quick wins for a smooth rollout:

• Implement a break-glass emergency admin account (excluded from CA)
• Group your service and automation principals into an exclusion group
• Start with pilot users before flipping to “All users”
• Monitor sign-in logs for MFA failures especially from service principals
• Migrate legacy per-user MFA and SSPR policies into the new Authentication methods policy before disabling the old ones

Reference list

1. Plan MFA Deployment scenarios (free vs. P1 vs. P2) – https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-licensing#compare-multifactor-authentication-policies
2. How to migrate MFA/SSPR to Authentication methods policy – https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage
3. Emergency access admin accounts (break-glass) – https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
4. Conditional Access policy templates & exclusions – https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common
5. App passwords for legacy protocols – https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-app-passwords

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Enabling a broad “Require MFA” Conditional Access (CA) policy is a common pattern, but it must be scoped carefully. From the provided context, only the behavior of Entra Conditional Access itself and typical scoping patterns can be described; Okta-specific behavior is outside the scope of the context, so only Entra-side impact is covered.

Key points from the referenced CA patterns:

• Microsoft recommends using Conditional Access for MFA instead of per-user MFA and applying it broadly, then excluding break-glass/emergency accounts and certain technical identities.
• Common templates include:
  • Require MFA for all users or all guests.
  • Require MFA for high/medium sign-in risk.
  • Require MFA for specific user actions (device registration, security info registration).
• Policies are generally created in Report-only mode first to validate impact.

Addressing the questions using the documented patterns:

1. Conflict with existing Okta MFA/SSO flows

The context does not describe Okta integration, so only Entra behavior can be stated:

• A CA policy with Users: All users and Target resources: All resources (formerly ‘All cloud apps’) that Grants → Require multifactor authentication or Require authentication strength (Multifactor authentication) will cause Entra ID to demand an MFA claim for interactive sign-ins that evaluate this policy.
• If a user’s sign-in path into Entra ID does not satisfy Entra’s MFA requirement (for example, if Entra does not see a valid MFA claim that matches the configured authentication strength), Entra will prompt for MFA using its configured methods.
• To reduce friction, Microsoft guidance for broad MFA policies is to:
  • Start in Report-only mode to see which sign-ins would be impacted before enforcing.
  • Use risk-based or scenario-based policies (for example, only for high/medium sign-in risk, or specific user actions) rather than a single “all users / all apps” blanket policy when appropriate.

2. Impact on Enterprise Applications, app registrations, service accounts, non‑interactive sign-ins

From the templates:

• Broad policies typically:
  • Include All users.
  • Exclude:
    • Emergency access / break-glass accounts.
    • Directory synchronization accounts or service identities.
• Example: the “Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users” policy explicitly excludes:
  • Emergency access accounts.
  • Directory Synchronization Accounts when hybrid identity is used.
• Microsoft-managed policies for risky sign-ins note that:
  • All Users could include service accounts or break-glass accounts, and these may need to be excluded.

Implications:

• If service accounts or non-interactive identities are left in scope of a “Require MFA” policy, sign-ins that cannot perform MFA will fail.
• Best practice from the patterns is to:
  • Exclude service accounts, sync accounts, and other non-interactive identities from broad MFA policies.
  • Use more targeted policies (for example, risk-based MFA) for human users.

3. Issues with Intune-managed or Jamf-managed devices

The context covers CA policies that combine device state and MFA:

• A template policy requires:
  • Require multifactor authentication, Require device to be marked as compliant, or Require Microsoft Entra hybrid joined device, with Require one of the selected controls.
• Another template requires MFA for Register or join devices and notes:
  • When using the Register or join devices user action in CA, the tenant-level device setting Require Multifactor Authentication to register or join devices with Microsoft Entra must be set to No, otherwise CA is not enforced correctly.

Implications:

• A pure “Require MFA” policy (without device conditions) should not directly conflict with Intune/Jamf management, but:
  • If device registration/join or compliance is also enforced via CA, ensure the documented device setting is configured correctly.
  • For device registration scenarios, use the dedicated “Require MFA for device registration” pattern rather than overloading a global “All apps” policy.

4. Authentication loops or unexpected MFA prompts with “All cloud apps”

From the templates:

• Several examples use All resources (formerly ‘All cloud apps’) for MFA policies, but always with:
  • Careful exclusions (break-glass, service accounts, sometimes guests).
  • Initial Report-only mode.
• Risk-based MFA template adds Sign-in risk: Medium and High and Sign-in frequency: Every time, which will intentionally cause frequent MFA prompts for risky sign-ins.

Implications:

• A broad “All cloud apps” + “All users” MFA policy will:
  • Cause MFA prompts across all Entra-protected resources unless another policy or exclusion prevents it.
  • Potentially increase prompt frequency when combined with other policies (for example, risk-based MFA, device registration MFA, security info registration MFA).
• Best practice from the patterns:
  • Use Report-only to observe impact.
  • Consider scoping by risk, user group, or specific user actions rather than a single global policy.

5. Recommended exclusions before enabling a broad MFA policy

Across the documented policies, typical exclusions include:

• Emergency access / break-glass accounts:
  • Explicitly excluded in multiple templates (all-users MFA, guest MFA, device registration MFA, security info registration MFA).
• Directory Synchronization Accounts / service accounts:
  • Specifically called out for exclusion when hybrid identity solutions like Entra Connect or Cloud Sync are used.
• Guest and external users in some scenarios:
  • The security info registration policy excludes All guest and external users because Temporary Access Pass does not work for guests.

For a broad “All users / All apps” MFA policy, the patterns suggest excluding at least:

• Break-glass/emergency access accounts.
• Directory synchronization and other non-interactive/service accounts.
• Any identities that cannot perform MFA but must remain functional (for example, certain automation accounts), and handling them with separate controls.

6. Impact on B2B guest access and external SharePoint sharing

The context includes:

• A template “Require MFA for guest access” policy:
  • Users: All guest and external users.
  • Target resources: All resources (or selected apps).
  • Grant: Require MFA.
• A B2B tutorial that enforces MFA for guest users accessing a specific resource (Azure Resource Manager).

Implications:

• If a global “All users / All apps” MFA policy includes guests, then:
  • B2B guest users will be required to perform MFA when accessing SharePoint and other resources, assuming their sign-in path is evaluated by Entra CA.
• If a separate guest-specific MFA policy is used, it can be tuned independently (for example, only for certain apps or resources).
• For security info registration, guests are explicitly excluded from the MFA policy because Temporary Access Pass does not work for them.

Best-practice alignment from the context:

• Use dedicated policies for:
  • All internal users MFA (or risk-based MFA).
  • Guest/external users MFA.
  • Device registration MFA.
  • Security info registration protection.
• Always:
  • Exclude break-glass accounts.
  • Exclude directory sync/service accounts where MFA is not possible.
  • Start in Report-only mode and review results using the CA reporting and “What If” tools before switching to On.

---

References:

• Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users
• Require multifactor authentication for guest access
• Require multifactor authentication for elevated sign-in risk
• Microsoft-managed Conditional Access policies
• Add multifactor authentication (MFA) to an app
• Require multifactor authentication for device registration
• Tutorial: Enforce multifactor authentication for B2B guest users
• Protect security info registration with Conditional Access policy

AI-generated content may be incorrect. Read our transparency notes for more information.