Interactive Troubleshooter

Published: Sep 27, 2026

Intune Device Compliance Failed: Conditional Access Fix

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Systematically diagnose and fix Microsoft Intune device compliance failures causing Entra ID Conditional Access blocks. This decision tree covers primary device health attestation, BitLocker status sync, Primary Refresh Token (PRT) state, and Workplace Join registration faults.

Full Diagnostic Tree & Step-by-Step Overview

What is the primary error or state shown when Conditional Access blocks access due to compliance?

Entra ID sign-in blocks with 'You cannot get there from here' (Error Code 53000 / 530001).
Intune Admin Center marks device as 'Not Compliant' due to security or policy enforcement failures.
Device shows 'In Grace Period' or 'Not Evaluated' state continuously in Intune portal.
Device is marked compliant in Intune, but Entra ID Conditional Access still reports 'Device state: Non-compliant'.

What specific device join or Primary Refresh Token (PRT) condition is reported on the endpoint?

dsregcmd /status shows AzureAdJoined = YES, but AzureAdPrt = NO or PRT is invalid.
dsregcmd /status shows WorkplaceJoined = YES (Work/School account), but device lacks Hybrid/Entra ID join.
Conditional Access sign-in log shows 'Device ID' is blank or unassociated with the sign-in request.
Browser authentication fails because the WebAccountManager (WAM) broker or browser extension is disabled.

Primary Refresh Token (PRT) Missing or Invalid Claims

Solution:

Root Cause: Entra ID Token Broker Desynchronization or TPM Transport Key Failure

Conditional Access policies enforcing 'Require device to be marked as compliant' rely on the Primary Refresh Token (PRT) issued by Entra ID. The PRT contains the deviceID and device compliance claims verified by the Cloud AP plugin. If the Trusted Platform Module (TPM) fails transport key verification, or if user credentials desynchronize from the device registration object, the PRT lacks compliance claims, triggering Error Code 53000.

# Diagnostic Verification:

1. Open Command Prompt on the affected endpoint.
2. Execute state check:

cmd
   dsregcmd /status

3. Verify SSO State section: confirm AzureAdPrt : YES. If NO or AzureAdPrtAuthority is empty, PRT acquisition failed.
4. Check Event Viewer: Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin for Event ID 304 or 358.

# Step-by-Step Fix:

1. Clear Stale Device Tokens and Re-acquire PRT:

Lock the Windows session (Win + L) and log back in using full Entra ID credentials (or Windows Hello for Business).

2. Reset Cloud AP Plugin Cache:

Open PowerShell as Administrator and run:

powershell
     klist purge -li 0x3e7

3. Re-register Device with Entra ID if PRT Remains Missing:

Open Command Prompt as Administrator:

cmd
     dsregcmd /debug /leave

Wait 2 minutes, then re-join the endpoint:

cmd
     dsregcmd /join

4. Verify TPM Attestation Health:

Run tpm.msc and ensure Status states 'The TPM is ready for use'. Refer to Microsoft Official Support Guide for advanced dsregcmd output analysis.

# Prevention & Long-Term Monitoring:

Ensure TPM 2.0 firmware is updated to prevent attestation timeouts during logon token exchanges.

Workplace Join / Entra Registered Instead of Joined State

Solution:

Root Cause: Account Registration Mismatch (Entra Registered vs Entra Joined)

Conditional Access device compliance evaluation requires proper MDM enrollment tied to a full Entra ID Joined or Hybrid Entra ID Joined device object. If a user connects their account via 'Add Work or School Account' without proper MDM enrollment, the device is created as 'Entra Registered' (Workplace Joined) and cannot process corporate Intune compliance policies correctly.

# Diagnostic Verification:

1. Open Command Prompt and run:

cmd
   dsregcmd /status

2. Inspect Device State: AzureAdJoined : NO and WorkplaceJoined : YES indicates an informal registered state rather than a fully managed corporate device.

# Step-by-Step Fix:

1. Disconnect Workplace Account:

Navigate to Settings > Accounts > Access work or school.

Select the corporate account and click Disconnect.

2. Clean Residual MDM Enrolment Registry Keys:

Open regedit as Administrator and check:

HKLM\SOFTWARE\Microsoft\Enrollments

Remove orphaned GUID subkeys associated with the old UPN.

3. Execute Corporate Enrollment / Entra Join:

For corporate-owned devices, join via Connect > Join this device to Azure Active Directory.

Enter corporate credentials to trigger automatic Intune enrollment via MDM discovery URLs.

# Prevention & Long-Term Monitoring:

Enforce automatic Intune MDM enrollment in Entra ID Mobility (MDM and MAM) settings for all user scopes.

Orphaned Device ID / Entra ID Object Mismatch

Solution:

Root Cause: Duplicate Device Records or Stale Device Cleanup in Entra ID

When a device is re-imaged or re-enrolled without removing the legacy device record, Intune generates a new DeviceId while local client tokens still reference the deleted or disabled Entra ID object ID. During Conditional Access evaluation, the sign-in request evaluates against an orphaned non-compliant record.

# Diagnostic Verification:

1. Check Entra ID Sign-in Logs in Azure Portal (Entra ID > Sign-in logs).
2. Filter by the correlation ID or failed sign-in attempt.
3. Navigate to the Basic Info tab and compare the Device ID listed in the log with the active Device ID in the Intune Admin Center.

# Step-by-Step Fix:

1. Remove Stale Device Records in Entra ID:

Open Entra Admin Center > Devices > All devices.

Locate and delete duplicate/disabled entries matching the device name.

2. Unenroll and Re-enroll Device in Intune:

Open PowerShell as Administrator and force MDM unenrollment:

powershell
     $EnrollmentID = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Enrollments\*" | Where-Object {$_.DiscoveryServiceFullURL}).PSChildName
     C:\Windows\System32\deviceenroller.exe /c /AutoEnrollMDM

3. Force Local Sync to Rebind Certificate:

Open Settings > Accounts > Access work or school > Click account > Info > Sync.

# Prevention & Long-Term Monitoring:

Implement automated stale device cleanup rules in Intune and avoid manual device deletion while endpoints are active.

Browser Native Authentication Broker (WAM) Failure

Solution:

Root Cause: Disabled Windows Accounts Extension or WAM Plugin Block

Web browsers (Chrome, Firefox) require native Web Account Manager (WAM) integration or the Windows Accounts extension to pass the device PRT and deviceId context to Entra ID endpoint endpoints during web-based Single Sign-On (SSO). Without WAM, browser sessions present no device context, triggering non-compliance blocks.

# Diagnostic Verification:

Accessing M365 apps via Microsoft Teams/Outlook desktop app works, but accessing portal.office.com via Google Chrome triggers Conditional Access Error 53000.

# Step-by-Step Fix:

1. Enable Native Window SSO in Google Chrome via Registry:

cmd
   reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v EnableCloudReporting /t REG_DWORD /d 1 /f
   reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v CloudManagementEnrollmentToken /t REG_SZ /d "" /f

*Alternatively, deploy the Windows Accounts Extension to Google Chrome via Group Policy/Intune.*
2. Enable WAM in Mozilla Firefox:

Open Firefox, navigate to about:config.

Set network.http.windows-sso.enabled to true.

3. Reset Account Broker Package in Windows:

Run PowerShell as Administrator:

powershell
     Get-AppxPackage -AllUsers *AccountsControl* | Reset-AppxPackage

# Prevention & Long-Term Monitoring:

Deploy Microsoft Edge as the default corporate browser, as it natively handles WAM token claims without additional extensions.

Which specific Intune compliance setting or check is failing in the portal?

BitLocker / Encryption status is reported as non-compliant or failing to sync.
System Health Attestation (Secure Boot, TPM, Code Integrity) fails evaluation.
Microsoft Defender for Endpoint (MDE) risk score is marked non-compliant or 'No status'.
Minimum OS Version requirement or Password/Firewall policy checks fail.

BitLocker Encryption Policy Sync Failure

Solution:

Root Cause: BitLocker Management Service (BDESVC) Reporting Lag or Cipher Mismatch

Intune compliance policies evaluating BitLocker require the local Windows Management Instrumentation (WMI) win32_encryptablevolume class to report active protection status. On newly encrypted or re-provisioned devices, BitLocker encryption may be complete locally, but the BitLocker CSP fails to refresh compliance states to Intune due to pending key escrow or missing XTS-AES cipher alignment.

# Diagnostic Verification:

1. Open PowerShell as Administrator.
2. Query BitLocker status:

powershell
   Get-BitLockerVolume -MountPoint "C:"

3. Verify ProtectionStatus is On and LockStatus is Unlocked.
4. Check Event Viewer: Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management for Event ID 813 or 846.

# Step-by-Step Fix:

1. Force BitLocker Key Escrow to Entra ID:

powershell
   $BLV = Get-BitLockerVolume -MountPoint "C:"
   BackupToAADBitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

2. Restart BitLocker Drive Encryption Service:

powershell
   Restart-Service -Name "BDESVC"

3. Trigger Local Intune Management Extension (IME) Sync:

Open services.msc and restart Microsoft Intune Management Extension.

Or run PowerShell command:

powershell
     Get-ScheduledTask | Where-Object {$_.TaskName -like "*PushLaunch*"} | Start-ScheduledTask

# Prevention & Long-Term Monitoring:

Ensure BitLocker compliance policy allows standard encryption algorithms (XTS-AES 128/256) matching your configuration profiles.

Device Health Attestation (Secure Boot / TPM / Code Integrity) Failure

Solution:

Root Cause: Health Attestation Service (HAS) Endpoint Timeout or Measured Boot Log Corruption

Intune uses Device Health Attestation (DHA) to verify hardware-rooted security features (Secure Boot, BitLocker enabled in early boot, Driver Signature Enforcement, Code Integrity). If the local Measured Boot log in C:\Windows\Logs\MeasuredBoot becomes corrupted, or if outbound access to *.has.smarterdevices.microsoft.com is blocked by corporate firewalls, health attestation evaluation fails.

# Diagnostic Verification:

1. Open PowerShell as Administrator and verify local Secure Boot state:

powershell
   Confirm-SecureBootUEFI

2. Check Event Viewer: Applications and Services Logs > Microsoft > Windows > DeviceHealthAttestation > Operational for HTTP timeout errors or Event ID 101.

# Step-by-Step Fix:

1. Enable Secure Boot in UEFI/BIOS:

Restart the PC and enter BIOS setup.

Ensure Secure Boot is enabled and Platform Mode is set to User Mode / Deployed Mode.

2. Clear Corrupted Measured Boot Logs:

Open PowerShell (Admin) and run:

powershell
     Stop-Service -Name "hasSvc" -ErrorAction SilentlyContinue
     Remove-Item -Path "C:\Windows\Logs\MeasuredBoot\*" -Force -Recurse

3. Verify Outbound Network Connectivity:

Test access to the Microsoft Health Attestation endpoints:

powershell
     Test-NetConnection -ComputerName "has.smarterdevices.microsoft.com" -Port 443

4. Reboot Device to Regenerate Measured Boot Log:

cmd
   shutdown /r /t 0

# Prevention & Long-Term Monitoring:

Ensure corporate network proxies do not perform SSL inspection on DHA attestation URLs.

Microsoft Defender for Endpoint (MDE) Risk Score Non-Compliance

Solution:

Root Cause: MDE Connector Desynchronization or Active Unresolved Threat Alert

When Intune compliance policies require a machine to be at or below a 'Low' Machine Risk Score, any active malware alert or unverified device state flagged by Microsoft Defender for Endpoint causes Intune to set the device as non-compliant until the threat is remediated or closed in the Defender portal.

# Diagnostic Verification:

1. Open Microsoft Defender Portal (security.microsoft.com).
2. Navigate to Assets > Devices and search for the affected device name.
3. Check the Risk level badge (e.g., Medium, High, or No Data).

# Step-by-Step Fix:

1. Remediate or Suppress Active Alerts in Defender Portal:

Open the device page in Defender for Endpoint.

Review Alerts story.

Resolve, remediate, or classify active alerts as False Positive or Informational to lower the machine risk score.

2. Fix MDE Sense Service Sync on Endpoint:

Open PowerShell as Administrator and verify Sense service status:

powershell
     Get-Service -Name "Sense"

If stopped, start the service:

powershell
     Start-Service -Name "Sense"

3. Force MDE Onboarding Status Refresh:

Run Defender health check command:

cmd
     "C:\Program Files\Windows Defender\MpCmdRun.exe" -SignatureUpdate

# Prevention & Long-Term Monitoring:

Configure automated investigation and remediation (AIR) in Defender to automatically resolve low-risk threat alerts.

OS Version / Firewall / Password Policy Enforcement Failure

Solution:

Root Cause: Outdated Windows Build or Local Security Policy Override

Intune compliance rules enforce strict OS build thresholds (e.g., minimum build 10.0.22631.3880) or require active local firewalls across Domain, Private, and Public profiles. Third-party security suites or pending Windows updates cause local status mismatches against Intune baseline policies.

# Diagnostic Verification:

1. Open PowerShell and check exact Windows build version:

powershell
   [System.Environment]::OSVersion.Version

2. Verify Windows Firewall status across all profiles:

powershell
   Get-NetFirewallProfile | Select-Object Name, Enabled

# Step-by-Step Fix:

1. Enable Windows Defender Firewall Profiles:

powershell
   Set-NetFirewallProfile -All -Enabled True

2. Force Windows Update Installation:

Open Settings > Windows Update > Click Check for updates.

Install required cumulative security updates to meet the minimum build compliance threshold.

3. Refresh Intune Policy Sync:

Run Command Prompt as Administrator:

cmd
     C:\Windows\System32\deviceenroller.exe /c /AutoEnrollMDM

# Prevention & Long-Term Monitoring:

Align Intune minimum OS version compliance policies with your active Update Rings deployment schedule.

What state is shown in the Intune Admin Center for the non-evaluating device?

Device status remains 'Not Evaluated' or displays 'No Compliance Policy Assigned'.
Device shows 'In Grace Period', but compliance deadline has expired without policy sync.
Intune Management Extension (IME) agent service is missing or failing to execute scripts.
Device compliance check fails specifically on macOS / iOS / Android endpoints.

Missing Compliance Policy Assignment or Target Group Conflict

Solution:

Root Cause: Policy Targeting Scope Exclusion or Default Compliance Settings

When Intune reports 'Not Evaluated' or 'No Compliance Policy Assigned', the device object or enrolled user does not reside within the assigned Azure AD / Entra ID target groups for any active compliance policy. By default, Intune marks devices without an assigned compliance policy based on the tenant-wide setting 'Mark devices with no compliance policy assigned as'.

# Diagnostic Verification:

1. Open Microsoft Intune Admin Center (intune.microsoft.com).
2. Navigate to Devices > Compliance > Policies.
3. Click your active compliance policy and review Assignments (Included/Excluded groups).
4. Check tenant default setting: Devices > Compliance > Compliance policy settings > Mark devices with no compliance policy assigned as.

# Step-by-Step Fix:

1. Update Target Group Assignment:

Add the affected user or device object to the included Entra ID security group assigned to the compliance policy.

2. Change Tenant Default Compliance Setting:

If non-targeted devices should remain compliant, change Mark devices with no compliance policy assigned as to Compliant (Note: Zero-Trust best practice is Non-compliant).

3. Trigger Remote Sync from Intune Portal:

Go to Devices > All devices > Select device > Click Sync.

# Prevention & Long-Term Monitoring:

Use dynamic user/device groups based on OS platform attributes (device.deviceOSType -eq "Windows") to automate compliance policy assignment.

Grace Period Expiration and Scheduled Task Failure

Solution:

Root Cause: Scheduled MDM Task Disablement or Network Timeout During Grace Period

Intune allows admins to configure actions for non-compliance, such as 'Mark device non-compliant: Immediately' or 'Block access after X days' (Grace Period). If the Windows Scheduled Task responsible for MDM background processing (Schedule #3 created by enrollment client) is disabled or failing, the endpoint fails to re-check compliance before the grace period expires.

# Diagnostic Verification:

1. Open PowerShell as Administrator on the endpoint.
2. Inspect Intune MDM scheduled tasks:

powershell
   Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Select-Object TaskName, State

3. Verify if tasks are listed as Disabled or Ready.

# Step-by-Step Fix:

1. Enable All Enterprise Management Scheduled Tasks:

powershell
   Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Enable-ScheduledTask

2. Trigger Immediate MDM Policy Refresh Task:

powershell
   Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" | Where-Object {$_.TaskName -like "*ScheduleToExecute*"} | Start-ScheduledTask

3. Verify OMA-DM Client Communication:

Open Settings > Accounts > Access work or school > Click account > Info > Click Sync.

# Prevention & Long-Term Monitoring:

Do not disable default Windows EnterpriseMgmt scheduled tasks via optimization scripts or Group Policy.

Intune Management Extension (IME) Service Corruption

Solution:

Root Cause: IME Agent Crash, Missing Service Executable, or Agent Token Expiration

The Microsoft Intune Management Extension (IME) process (IntuneManagementExtension.exe) handles custom compliance scripts, PowerShell detection routines, and win32 app deployments. If the agent service crashes or fails authentication, custom compliance rules fail to evaluate.

# Diagnostic Verification:

1. Check Service Status in PowerShell:

powershell
   Get-Service -Name "IntuneManagementExtension"

2. Inspect log files at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log for error code 0x80070002 or HTTP 401 Unauthorized.

# Step-by-Step Fix:

1. Restart IME Service:

powershell
   Restart-Service -Name "IntuneManagementExtension"

2. Reinstall Intune Management Extension Service cleanly:

Uninstall current extension via Command Prompt:

cmd
     msiexec /x {A741639E-0E28-40C6-9195-2E52DFD360F6} /q

Force Intune to re-deploy the extension by assigning a dummy PowerShell script or Win32 app to the device in the Intune portal.

3. Verify Log File Sync:

Monitor AgentExecutor.log in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs for successful script execution entries.

# Prevention & Long-Term Monitoring:

Ensure endpoint security software excludes C:\ProgramData\Microsoft\IntuneManagementExtension from real-time file locking.

Non-Windows Platform (macOS / iOS / Android) Company Portal Failure

Solution:

Root Cause: Apple Push Notification Service (APNs) Certificate Expiry or Company Portal Broker Disconnect

On non-Windows platforms (macOS, iOS, Android), device compliance checks require active communication between the Intune Company Portal app and platform notification services (Apple APNs or Google FCM). An expired APNs certificate or missing Microsoft Authenticator broker app prevents compliance status delivery to Entra ID.

# Diagnostic Verification:

1. Open Intune Admin Center > Tenant administration > Connectors and tokens > Apple MDM Push certificate.
2. Confirm status is Active and expiration date is in the future.
3. On macOS/iOS, open Company Portal app and check for error: 'Management profile missing' or 'Device compliance status unknown'.

# Step-by-Step Fix:

1. Renew Apple MDM Push Certificate (If Expired):

Renew certificate using the same Apple ID at identity.apple.com and upload new .pem file to Intune.

2. Re-establish SSO Broker on iOS / Android:

Ensure Microsoft Authenticator (iOS) or Company Portal (Android) is installed to act as the broker app for conditional access claims.

3. Re-install Management Profile on macOS:

Open Company Portal on Mac > Click Fix > Re-download and approve the enrollment profile under System Settings > Privacy & Security > Profiles.

# Prevention & Long-Term Monitoring:

Set calendar reminders 30 days prior to Apple APNs certificate expiration to prevent company-wide iOS/macOS compliance drops.

What specific discrepancy exists between Intune compliance and Entra ID Conditional Access status?

Intune shows device is 'Compliant', but Entra ID Sign-In logs report 'Device State: Non-compliant'.
Conditional Access policy blocks sign-in from an Entra Hybrid Joined device despite valid Intune sync.
Cross-tenant / B2B guest user sign-in fails Conditional Access device compliance check.
Device compliance state flips back and forth between Compliant and Non-Compliant dynamically.

Intune-to-Entra ID Sync Latency / Compliance State Propagation Delay

Solution:

Root Cause: Asynchronous Service-to-Service Graph Propagation Delay

When a device transitions to 'Compliant' in Intune, Intune calls an internal Graph API microservice to write the isCompliant = true attribute to the corresponding Entra ID device object. During peak Microsoft cloud service load, propagation between Intune device management microservices and Entra ID authentication endpoints can lag by 15 to 45 minutes.

# Diagnostic Verification:

1. Open Graph Explorer or Azure PowerShell and query the device object directly in Entra ID:

powershell
   Get-MgDevice -DeviceId "<Your-Entra-Device-ID>" | Select-Object DisplayName, IsCompliant

2. Compare IsCompliant output (True/False) against the status displayed in Intune Admin Center.

# Step-by-Step Fix:

1. Force Entra ID Device Property Refresh via Graph PowerShell:

Connect to Microsoft Graph with Device write permissions:

powershell
     Connect-MgGraph -Scopes "Device.ReadWrite.All"
     Update-MgDevice -DeviceId "<Entra-Device-Obj-ID>" -IsCompliant:$true

2. Clear Local Authentication Cache on Client Endpoint:

Open PowerShell on client machine and purge Kerberos/CloudAP tickets:

powershell
     klist purge

3. Force Re-Authentication via Web Account Manager:

Sign out of Microsoft 365 desktop apps (Word, Teams), restart the application, and sign back in to issue a fresh PRT with updated compliance claims.

# Prevention & Long-Term Monitoring:

Allow up to 30 minutes following compliance remediation before attempting critical Conditional Access sign-ins.

Hybrid Entra ID Join Device ID Mismatch / Azure AD Connect Sync Lag

Solution:

Root Cause: Dual Device Object Creation via Microsoft Entra Connect Sync

Hybrid Entra ID Joined devices rely on Microsoft Entra Connect to sync on-premises Active Directory computer objects to Entra ID. If Intune enrollment occurs *before* Entra Connect completes initial object sync, two separate device records are generated in Entra ID: one 'Server AD joined' object and one 'Intune MDM' object, preventing compliance claim merging.

# Diagnostic Verification:

1. Open Entra Admin Center > Devices > All devices.
2. Search for the computer name.
3. Verify if two entries exist with differing Join Type values (e.g., Microsoft Entra hybrid joined vs Microsoft Entra registered).

# Step-by-Step Fix:

1. Verify On-Premises AD Computer Object Sync State:

Ensure computer object resides in an Active Directory OU included in Microsoft Entra Connect Sync filtering.

2. Force Entra Connect Delta Sync on Sync Server:

Open PowerShell on Entra Connect server:

powershell
     Start-ADSyncSyncCycle -PolicyType Delta

3. Re-bind Hybrid Device Enrollment:

On client computer, run Command Prompt as Administrator:

cmd
     dsregcmd /leave

Trigger Automatic Scheduled Task for Hybrid Join:

powershell
     Start-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace\" -TaskName "Automatic-Device-Join"

# Prevention & Long-Term Monitoring:

Ensure Microsoft Entra Connect sync cycles complete prior to executing bulk Intune enrollment on hybrid endpoints.

B2B Guest User / Cross-Tenant Device Compliance Trust Failure

Solution:

Root Cause: Unconfigured Cross-Tenant Access Policy Device Trust Settings

When a guest user accesses resources in a resource tenant enforcing Conditional Access device compliance, the resource tenant blocks sign-in unless its Cross-Tenant Access Settings explicitly trust compliance claims passed from the guest user's home tenant Intune infrastructure.

# Diagnostic Verification:

1. Open Sign-in logs in the Resource Tenant.
2. Locate the failed guest user sign-in attempt.
3. Check Conditional Access tab > Details: Message reads 'The device must be marked as compliant in the home tenant, but cross-tenant trust is not configured'.

# Step-by-Step Fix:

1. Configure Cross-Tenant Access Settings in Resource Tenant:

Open Entra Admin Center > External Identities > Cross-tenant access settings.

Select Organizational settings > Add the guest user's Home Tenant ID.

2. Trust Compliance Claims from Home Tenant:

Click the home organization entry > Inbound access settings.

Navigate to Trust settings tab.

Check Trust compliant devices.

Click Save.

3. Verify Home Tenant Compliance Enforcement:

Ensure the home tenant maintains an active Intune compliance policy evaluating the guest user's device.

# Prevention & Long-Term Monitoring:

Establish mutual cross-tenant trust settings prior to onboarding external organization B2B guest users to Conditional Access protected resources.

Flapping Device Compliance State / Conflicting Multi-Policy Evaluation

Solution:

Root Cause: Conflicting Intune Compliance Policies or Custom Compliance Script Instability

If a device is targeted by multiple Intune compliance policies with contradictory settings (e.g., Policy A enforces BitLocker XTS-AES 128 while Policy B enforces XTS-AES 256), or if a custom PowerShell compliance script returns inconsistent JSON output objects, the device state continually toggles ('flaps') between Compliant and Non-Compliant.

# Diagnostic Verification:

1. Open Intune Admin Center > Devices > Compliance.
2. Select the affected device > Device compliance tab.
3. Review individual policy states and look for opposing setting status flags (Conflict or Error).

# Step-by-Step Fix:

1. Consolidate Target Compliance Policies:

Remove overlapping compliance policy assignments so each OS platform receives a single unified compliance policy.

2. Debug Custom PowerShell Compliance Scripts:

Check custom compliance script logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log.

Ensure custom PowerShell scripts output strict JSON string format matching Intune schema parameters:

json
     {
       "BitLockerSecure": "True",
       "ComplianceState": "Compliant"
     }

3. Force Immediate Policy Re-evaluation:

In Intune portal, open device > Click Check compliance.

# Prevention & Long-Term Monitoring:

Test custom compliance scripts extensively on pilot device groups before deploying across production tenant devices.

Related Diagnostic Guides

SharePoint Online Access Denied Even as Owner

Interactive: Game Crashes - Overheating, Driver, or Corrupted Files?

Entra ID Sync Error: Duplicate Proxy Address

Power Automate Flow Failed: Connector Timeout Diagnostic

Interactive: Blue Screen - Which Driver Caused It? Use Driver Verifier

Subscribe to StepDiag

Embed Guide on Your Website