We have a Conditional Access Policy not honoring the sign in frequency on an unmanaged Mac

The behavior is consistent with how Microsoft Entra Conditional Access session controls work and is likely not a “Mac-only bug” in the policy itself, but an interaction between:

• The Conditional Access Sign-in frequency setting
• How the browser on macOS handles cookies/tokens
• Other session-related controls (Conditional Access App Control, idle timeouts, CAE, or app-specific timeouts)

Key points from the platform behavior:

1. Sign-in frequency is a maximum lifetime, not a keep-alive
   A Conditional Access Sign-in frequency of 30 days means users can stay signed in up to 30 days before being forced to reauthenticate, assuming nothing else revokes the session. Any IT policy violation or revocation event (password change, device noncompliance, account disabled, explicit session revocation, etc.) will end the session earlier.
2. Sign-in frequency applies to OAuth2/OIDC apps and MFA
   Office 365 web apps (Exchange Online, SharePoint/OneDrive, Teams web, Office.com, etc.) honor the Conditional Access Sign-in frequency setting when using OAuth2/OIDC. The same setting now also applies to MFA, so frequent MFA prompts can be driven by this control if the session is being re-evaluated often.
3. Continuous Access Evaluation (CAE) does not override Sign-in frequency
   CAE revokes tokens based on policy changes and risk events, but the documentation explicitly states that Sign-in Frequency is honored with or without CAE. So if something on the Mac side is causing token invalidation or repeated re-auth, the 30‑day value will not prevent that.
4. Other session controls can shorten effective lifetime
   In addition to Sign-in frequency, the following can force earlier reauth:
   • Conditional Access Application enforced restrictions or App Control (reverse proxy via Defender for Cloud Apps) that change the session behavior for unmanaged devices.
   • App-specific idle session timeouts (for example, SharePoint/OneDrive or Microsoft 365 web idle timeout policies) that sign users out after inactivity.
   • Browser behavior on macOS (private browsing, cookie restrictions, clearing cookies on exit, third-party cookie blocking) that causes the auth cookies or tokens to be dropped.
5. Unmanaged vs managed device behavior
   The recommended pattern is:
   • Use SSO with managed devices or seamless SSO where possible.
   • For unmanaged devices, be more restrictive with persistent browser sessions and sign-in frequency. If a Conditional Access policy is configured to treat unmanaged devices differently (for example, via device filters or compliant device conditions), unmanaged macOS devices may be getting:
     • Shorter sign-in frequency
     • No persistent browser session
     • Additional session controls via Defender for Cloud Apps

Given that BYOD Windows devices are not seeing the hourly prompts, the most likely causes are:

• A browser or privacy configuration specific to macOS (Safari/Chrome/Edge settings, content blockers, or clearing cookies) that prevents the session cookie/token from persisting.
• A Conditional Access policy or Defender for Cloud Apps session policy scoped in a way that affects macOS browsers differently (for example, via device platform conditions or custom app control settings for unmanaged devices).
• An idle timeout or app-enforced restriction that is effectively set to ~1 hour for the workloads the Mac users are accessing.

Recommended checks and steps:

1. Verify the exact Conditional Access policies applied to a Mac sign-in
   Use the Microsoft Entra Sign-in logs for an affected Mac user:
   • Go to Entra admin center → Entra ID → Monitoring & health → Sign-in logs.
   • Filter by username, date/time, and resource (e.g., Exchange Online, SharePoint Online, Office.com).
   • Open a sign-in event that corresponds to when the user is prompted again.
   • On the Conditional Access tab, confirm:
     • Which policies are applied.
     • Which controls are enforced (Sign-in frequency, App Control, application enforced restrictions, etc.).
   • Use the Troubleshooting and support tab to see if the sign-in was interrupted due to device compliance, session control, or another condition.
2. Confirm the Sign-in frequency configuration
   • Ensure there is only one effective Sign-in frequency policy for these users/apps, or if multiple exist, verify they are not conflicting.
   • Confirm that the policy targeting unmanaged devices on macOS is indeed set to 30 days and not overridden by another policy with a shorter frequency.
3. Check for Conditional Access App Control / Defender for Cloud Apps policies
   • If Conditional Access is routing unmanaged devices to Conditional Access App Control (Defender for Cloud Apps), review the session policies there. Session policies can enforce additional controls that may shorten the effective session or cause more frequent reauth.
4. Review idle session timeout and app-enforced restrictions
   • Check if SharePoint/OneDrive or Microsoft 365 web idle session timeout policies are configured to 1 hour or similar. These can sign users out even if Sign-in frequency is 30 days.
   • If Application enforced restrictions are used for unmanaged devices, confirm how they are configured for the workloads the Mac users are accessing.
5. Browser and device behavior on macOS
   On affected Macs, verify:
   • The browser is not in private/incognito mode.
   • Cookies (especially third-party cookies) are allowed for Microsoft sign-in endpoints.
   • No extensions/content blockers are stripping auth cookies or clearing them on a schedule.
   • The browser is not configured to clear cookies on exit or after a short time.
6. Test with report-only mode or What If tool
   • Use report-only mode for any new or adjusted Conditional Access policies to see how they would apply to macOS users without enforcing them.
   • Use the Conditional Access What If tool to simulate a macOS unmanaged device scenario and verify which policies and controls would apply.

If, after these checks, the sign-in logs show that the same 30‑day Sign-in frequency policy is applied and no additional session controls are forcing reauth, focus on the macOS browser environment (cookies, privacy, extensions) as the likely cause of the hourly prompts.

References:

• Conditional Access: Session
• Conditional Access adaptive session lifetime policies
• Continuous access evaluation
• Reauthentication prompts and session lifetime for Microsoft Entra multifactor authentication
• Plan a Conditional Access deployment
• Troubleshoot sign-in problems with Conditional Access