Fix Intune Device Sync Failures After Conditional Access Policy Changes (Error 0x80180028)

A Conditional Access change can break Intune device sync even when nothing changed on the endpoint. The user opens Company Portal, the device says it cannot sync, or Windows enrollment fails with 0x80180028. From the admin side, the device may still exist in Microsoft Entra ID and Intune, but policy delivery stalls because the sign-in, compliance, or MDM enrollment path no longer satisfies the new access rules.

This guide gives desktop engineers and Intune admins a practical triage path for device sync failures after Conditional Access policy changes, with a focus on error 0x80180028.

What Usually Changed

Start by treating this as an access-path problem, not a device imaging problem. A sync failure after a Conditional Access rollout usually means one of these changed:

• A new policy now requires a compliant device before the device can complete the sync that would make it compliant.
• A policy now requires multifactor authentication in a flow that cannot complete MFA cleanly.
• The Intune enrollment cloud app, Microsoft Intune, Microsoft Intune Enrollment, or device registration flow was included too broadly.
• A grant control now blocks unmanaged or unknown device states.
• The user or test device moved into a targeted group by accident.
• A break-glass or enrollment exclusion was removed.

That creates a loop: the device needs Intune to become compliant, but Conditional Access blocks the device because it is not compliant yet.

Common Symptoms

You may see one or more of these symptoms:

• Company Portal reports that the device cannot sync.
• Windows Settings shows work or school account errors.
• The device stays non-compliant even after the user retries sync.
• Autopilot or enrollment fails before the device receives required policies.
• Sign-in logs show Conditional Access failure for the user.
• The device record exists, but the last check-in time stops updating.
• Error 0x80180028 appears during enrollment or MDM registration.

Do not wipe the device first. If the Conditional Access rule is the cause, a wipe will reproduce the same failure and waste another deployment cycle.

Step 1: Confirm the Failure Started With Conditional Access

Open Microsoft Entra admin center and check the user sign-in logs for the same time window as the failed sync.

Go to:

Microsoft Entra admin center → Identity → Monitoring & health → Sign-in logs

Filter by the affected user and inspect failed sign-ins around the sync attempt. Look for:

• Application: Microsoft Intune
• Application: Microsoft Intune Enrollment
• Application: Microsoft Device Registration Service
• Conditional Access status: Failure
• Grant controls: require compliant device, require MFA, require approved client app, or block access
• Device state: unknown, non-compliant, or not registered

If the sign-in log shows the new Conditional Access policy as the blocking control, you have found the root path. The endpoint is not the first thing to repair. The policy scope is.

Step 2: Check for the Compliance Deadlock

The most common mistake is requiring device compliance for the services that are needed to establish compliance.

Review any new or edited Conditional Access policy that targets broad user groups such as All users, All employees, or a dynamic pilot group. Check whether the policy includes these cloud apps:

• Microsoft Intune
• Microsoft Intune Enrollment
• Microsoft Device Registration Service
• Office 365 as a broad app bundle
• All cloud apps

If the policy requires Require device to be marked as compliant, exclude the enrollment and registration paths. A device that has not synced cannot prove compliance yet. Blocking the sync path makes remediation impossible from the endpoint.

A safer pattern is:

1. Keep compliance requirements for business apps such as Exchange Online, SharePoint Online, Teams, and line-of-business apps.
2. Exclude Microsoft Intune Enrollment and device registration flows from the strictest compliance gate.
3. Use a pilot group before applying to all users.
4. Keep a break-glass admin account excluded from Conditional Access.

Step 3: Inspect the Affected Device Record

In the Intune admin center, open the device and check these fields:

• Last check-in
• Compliance state
• Ownership
• Primary user
• Microsoft Entra device ID
• Management name
• Enrollment profile name
• MDM status

Then compare it with the Entra device object. You are checking whether Intune and Entra still agree about the device identity. If the Entra object was deleted, duplicated, disabled, or left in a stale state, Conditional Access may evaluate the sign-in as coming from an unknown or non-compliant device.

If the device has not checked in since the policy change, do not assume the device is offline. It may be blocked before the MDM channel can refresh policy.

Step 4: Confirm MDM Enrollment Scope and URLs

For Windows devices, verify the MDM user scope and discovery URLs.

Go to:

Microsoft Entra admin center → Mobility (MDM and WIP) → Microsoft Intune

Check:

• MDM user scope includes the affected user.
• MAM user scope is not accidentally taking precedence for the scenario.
• MDM terms of use URL is present if required.
• MDM discovery URL is configured.
• The user has a valid Intune license.

If the affected user was moved out of MDM scope during a group cleanup, Windows can still show the work account while Intune enrollment or sync fails behind it.

Step 5: Read the Device-Side Clues

On the affected Windows device, collect quick evidence before making changes.

Run:

Get-EventLog -LogName Application -Source "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider" -Newest 50

Also check Event Viewer:

Applications and Services Logs
  Microsoft
    Windows
      DeviceManagement-Enterprise-Diagnostics-Provider
        Admin

Useful signals include:

• MDM enrollment failure
• Token acquisition failure
• Server rejected the request
• Device credential or user credential issues
• Repeated sync retry events after the CA policy change

If you see authentication or token errors at the same time that Entra sign-in logs show Conditional Access failure, fix the Conditional Access policy first.

Step 6: Repair the Conditional Access Scope

Use this order to avoid over-correcting:

1. Put the affected user and one test device into a temporary troubleshooting exclusion group.
2. Confirm sync succeeds after policy evaluation refreshes.
3. If sync succeeds, remove the broad exclusion and narrow the policy fix.
4. Exclude enrollment and registration cloud apps where required.
5. Replace All cloud apps targeting with explicit app targeting when possible.
6. Split enrollment controls from normal app access controls.
7. Re-test with a pilot user before restoring broad scope.

Do not permanently exclude all Intune access from Conditional Access without understanding the tradeoff. The goal is not to weaken device governance. The goal is to avoid blocking the path devices use to become governed.

Step 7: Force a Clean Sync After Policy Repair

After the Conditional Access fix, trigger sync from Intune first:

Intune admin center → Devices → Windows → select device → Sync

Then ask the user to retry from the endpoint:

Settings → Accounts → Access work or school → select connected account → Info → Sync

You can also use Company Portal:

Company Portal → Settings → Sync

Watch for the last check-in time to update. Then verify compliance state after the next evaluation cycle. Compliance may not flip instantly even after sync is restored.

When Error 0x80180028 Persists

If 0x80180028 continues after the policy scope is repaired, check these secondary causes:

• The user is not licensed for Intune.
• The device is already enrolled under another tenant or stale workplace join.
• Enrollment restrictions block the platform or ownership type.
• The device limit for the user has been reached.
• The Entra device object is disabled or duplicated.
• The MDM enrollment scope excludes the user.
• Required network endpoints for login, device registration, or Intune are blocked.

For a stubborn device, remove the work account only after you have confirmed Conditional Access is no longer blocking the enrollment path. Then re-enroll the device and confirm a fresh Entra device object maps to the Intune record.

Prevention Checklist

Before rolling out a Conditional Access policy that affects device trust, validate these items:

• Test with a pilot group before All users.
• Keep break-glass accounts excluded.
• Do not require compliance for the initial enrollment path.
• Review Microsoft Intune Enrollment and device registration app targeting.
• Confirm sign-in logs during the pilot, not after the help desk escalates.
• Document which policies are allowed to target All cloud apps.
• Keep a rollback group ready for enrollment incidents.

Bottom Line

Intune sync failures after Conditional Access changes are usually caused by policy scope, not broken Windows devices. Error 0x80180028 should push you to check enrollment, registration, licensing, and Conditional Access evaluation together. Fix the access loop first, then force a clean sync and confirm the device check-in time updates in Intune.