Intune MTD connectors (Lookout, Zimperium, Check Point): setup, threat levels and errors

A Mobile Threat Defense (MTD) partner such as Lookout for Work, Zimperium or Check Point Harmony Mobile scans phones and tablets and hands Intune a device threat level. Intune feeds that level into compliance and app protection policies, and from there into Conditional Access. When one link breaks, users are blocked for threats nobody can find, or risky devices stay compliant. In this post I'll walk through each link, show what healthy looks like, and how to prove whether Intune or the partner is at fault.

Symptoms#

• Devices are noncompliant on Require the device to be at or under the Device Threat Level, although the partner console shows no active threat or doesn't list the device at all.
• Outlook, Teams or another protected app blocks the user (or wipes its data) through the app protection conditional launch rule Max allowed device threat level.
• Under Tenant administration › Connectors and tokens › Mobile Threat Defense, the partner's Last synchronized time is days old, or its connection status isn't healthy.
• Microsoft Graph returns the connector with partnerState: unresponsive, partnerState: notSetUp or partnerState: error.
• The reverse case: a device with a known threat stays compliant.

Why it happens#

Every MTD integration has four links, and each one fails in its own way:

1. The partner console. You set up the Intune connection in the partner's console first, usually including an Entra admin consent, and that's where findings are classified as Low, Medium or High. Only then can you enable the connector in Intune.
2. The Intune connector. Its toggles fall into four groups: compliance policy evaluation, app protection policy evaluation, the Android MTD role and shared settings. Which ones you see depends on the partner, and the full list only appears when the tenant's MDM authority is Intune.
3. The partner app. It has to be installed and activated, and the device needs a Microsoft Entra device ID (it must be registered) before it can report through the partner to Intune.
4. Your policies. A compliance rule or an app protection rule compares the partner's verdict with the highest level you allow: Secured, Low, Medium or High. (Microsoft's compliance policy documentation now calls the strictest level Clear; app protection policies call it Secured.)

How to fix it#

1. Read the connector from Graph. The portal shows the connection status and last sync; Graph shows the connector's state, heartbeat and toggles in one place:
   PowerShell

   Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
   $uri = "https://graph.microsoft.com/v1.0/deviceManagement/mobileThreatDefenseConnectors"
   (Invoke-MgGraphRequest -Method GET -Uri $uri).value | ForEach-Object {
       [pscustomobject]@{
           PartnerState      = $_.partnerState
           LastHeartbeat     = $_.lastHeartbeatDateTime
           AndroidCompliance = $_.androidEnabled
           IosCompliance     = $_.iosEnabled
           AndroidAppProt    = $_.androidMobileApplicationManagementEnabled
           IosAppProt        = $_.iosMobileApplicationManagementEnabled
           UnresponsiveDays  = $_.partnerUnresponsivenessThresholdInDays
       }
   } | Format-List

   The documented partnerState values are unavailable, available, enabled, unresponsive, notSetUp and error. unresponsive means no heartbeat arrived within the threshold; notSetUp and error send you to the partner console first.
2. Repair the partner side. Open the partner's Intune or UEM integration page and check that it reports a healthy connection. If consent was revoked, or the admin who set it up has left, re-run the integration with an account that can grant tenant-wide admin consent. Then confirm the affected user is inside the groups the partner syncs.
3. Check the toggles per platform. In Intune, open the partner under Tenant administration › Connectors and tokens › Mobile Threat Defense. Compliance and app protection are separate switches; turning on only one gives you a setup that works for compliance but not for Outlook, or the other way round. You need the Endpoint Security Manager role, or a custom role with Read and Modify on the Mobile Threat Defense permission.
4. Check the device. Assign the partner app as required, then make sure the user opened it and finished activation. Confirm the device is registered in Microsoft Entra ID; on mobile the broker app does that (Microsoft Authenticator on iOS/iPadOS, Company Portal on Android).
5. Compare levels, not just states. Look up the severity the partner gave the finding and compare it with your policy. Secured (Clear) tolerates nothing; Low allows low; Medium allows low and medium; High allows every level, uses the partner for reporting only and still requires the MTD app to be activated. Fix or reclassify the finding in the partner console rather than lowering the bar in Intune to hide it.
6. Decide what happens without data. Intune ignores an unresponsive partner, so the threat rule quietly stops protecting you. The Graph properties androidDeviceBlockedOnMissingPartnerData and iosDeviceBlockedOnMissingPartnerData show whether Intune must receive partner data before it marks a device compliant. Know which behaviour you chose.

Verify the fix#

• Graph shows partnerState as enabled with a recent lastHeartbeatDateTime, and the toggles you rely on are True.
• The connector's Last synchronized time in the admin center is current.
• On the device's compliance page the Device Threat Level setting is compliant, and the user can open the protected app again.
• The partner console lists the device as activated, with a recent check-in and the threat level you expect.

Prevent it next time#

• Assign the MTD app before you create the compliance and Conditional Access rules, as Microsoft recommends, so users can activate it before anything blocks them.
• Pilot with High, which only reports but still requires an activated MTD app, then tighten to Medium or Low.
• Run the Graph script on a schedule and alert when the heartbeat is more than a day or two old.
• Plan vendor changes: only one partner per platform can feed app protection evaluation, and only one partner per tenant can hold the MTD role on Android corporate-owned fully managed (COBO) and corporate-owned work profile (COPE) devices.
• Defender for Endpoint uses its own machine risk score rule; see the machine risk score checklist. With Jamf as your partner, see Jamf mobile threat defense with Intune. If only Outlook misbehaves, also work through app protection not applying to Outlook mobile.

References#

• Enable the Mobile Threat Defense connector in Microsoft Intune (Microsoft Learn)
• Create Mobile Threat Defense device compliance policy with Intune (Microsoft Learn)
• Create Mobile Threat Defense app protection policy with Intune (Microsoft Learn)
• mobileThreatDefenseConnector resource type (Microsoft Graph)