If the connector stops responding for long enough, Intune stops enforcing the compliance state.
Mobile Threat Defense feeds device risk into compliance policies, Conditional Access and app protection policies, including on unenrolled devices. It is a genuinely useful control with one property worth knowing: an unresponsive connector left unnoticed means the risk signal quietly stops mattering.
- 17 partnersListed by Microsoft, plus Defender
- Low, medium, highRisk levels compared to your allowance
- Unenrolled tooThrough app protection policies
- One per platformMicrosoft recommendation on vendors
A connector that stops responding stops protecting, and nothing announces it.
This is the property that separates a mobile threat defence deployment that works from one that provides false assurance.
- Microsoft documents six connector states: unavailable, not set up, available, enabled, unresponsive and error. The one that matters operationally is unresponsive, where the connector is not responding but has not failed outright.
- If that state persists for the number of days defined in the setting for days until the partner is unresponsive, Intune ignores the compliance state. In practice that means devices stop being assessed for threat risk, compliance stops reflecting it, and Conditional Access stops acting on it, without anything breaking visibly.
- The organisation continues to believe mobile threat risk is feeding its access decisions. It is not. And because nothing has failed, no ticket is raised and no alert fires unless somebody has deliberately set one up.
- The fix is straightforward and it has to be deliberate: monitor connector status as an operational item, set the unresponsive threshold consciously rather than accepting whatever it is, and make somebody responsible for noticing. It takes an hour to arrange and it is the difference between a control and a belief.
Eight things about Mobile Threat Defense that decide whether it protects anything.
A risk level, compared to an allowance you set
The mobile threat defence application scans and reports to its vendor, the threat is categorised as low, medium or high risk, and that level is compared with the risk allowance you configured in Intune. Based on the comparison, access to resources can be revoked while the device is compromised. That is the whole mechanism, and it means your allowance setting is the actual control.
The unresponsive connector, which silently stops enforcement
Microsoft documents six connector states, and one deserves attention: unresponsive. If the connector stays unresponsive for the number of days defined in the setting for days until the partner is unresponsive, Intune ignores the compliance state. So the control fails open, quietly, after a threshold you configured and probably do not remember. Monitoring connector status is not optional.
It works on devices you do not manage
Microsoft states the same data can be used for unenrolled devices through Intune app protection policies, so administrators can protect corporate data within a protected application and issue a block or a selective wipe. For a market where a large proportion of mobile access happens from personal devices nobody will enrol, that extends the control to exactly the population it usually cannot reach.
One vendor per platform, and Microsoft explains why
Microsoft recommends one mobile threat defence vendor per tenant per platform. Multiple vendors are technically supported for device compliance, but if you configure two or more for the same platform, every device on that platform must install each application and scan, and if any configured application fails to submit a scan the device is marked non-compliant. Defender for Endpoint is exempted from that recommendation.
Enhanced permissions on managed Android, for one partner
On Android Enterprise fully managed and corporate-owned work profile devices you can grant your mobile threat defence partner enhanced security permissions, exempting the application from app suspension, hibernation, power restrictions and user controls so it maintains continuous protection. Microsoft notes these permissions can be granted to one partner at a time, which reinforces the one vendor per platform point.
Data sharing is opt-in and off by default
Two inventory sharing services exist for iOS and iPadOS, application inventory and certificate inventory, and Microsoft states both are opt-in with no information shared by default, requiring an Intune administrator to enable them explicitly. Since both cover corporate and personally owned devices, that default is the right one and the decision to change it deserves a conversation rather than a click.
Certificate inventory, supported by exactly one partner
Certificate Sync lets supported partners request information about certificates installed on enrolled iOS and iPadOS devices, sharing the account and device identifiers, device owner and a certificate list including common name and whether it is an identity. Microsoft lists one partner supporting it: Zimperium. If that capability matters to you, it materially narrows the vendor choice.
Seventeen partners, and one of them covers Windows too
Microsoft lists Better Mobile, BlackBerry Protect Mobile, Check Point Harmony Mobile, CrowdStrike Falcon for Mobile, iVerify Enterprise, Jamf Mobile Threat Defense, Lookout for Work, Microsoft Defender for Endpoint, Pradeo, SentinelOne, Sophos Mobile, Symantec Endpoint Protection Mobile, Trellix Mobile Security, Trend Micro Mobile Security as a Service, Trustd Mobile, Windows Security Center and Zimperium. Most cover Android and iOS. Defender for Endpoint covers Android, iOS and Windows.
Four things that keep this from becoming an assumption.
We make connector health an operational item from day one
Because an unresponsive connector past the configured threshold means Intune ignores the compliance state, and nothing about that failure is visible unless somebody is watching. We set the threshold deliberately, put the connector status where it will be seen, and name who is responsible for noticing. It is an hour of work and it is what makes the deployment real.
We settle the vendor question before configuring anything
Microsoft recommends one vendor per tenant per platform, and explains the cost of ignoring that: every device on the platform must install every configured application and scan, and any application that fails to submit a scan marks the device non-compliant. Organisations that already own two mobile security products need to choose rather than deploy both.
We extend it to unenrolled devices deliberately
The same threat data can drive app protection policies on devices that are not enrolled at all, allowing a block or a selective wipe of corporate data in a protected application. In this market that is frequently the larger population, and it is the half most organisations leave uncovered because they assume mobile threat defence needs enrolment.
We treat the inventory sharing decision as a decision
Application and certificate inventory sharing are opt-in and off by default, and both cover corporate and personally owned devices. Sharing an inventory of the applications on somebody personal phone with a third-party vendor is a privacy decision, not a configuration toggle. We raise it explicitly so it is made rather than discovered.
Six UAE situations where mobile threat risk is worth acting on.
Executives and high-value targets on mobile
Senior people who read sensitive material on a phone, travel frequently, connect to networks they do not control, and are specifically worth targeting. Detecting a network vulnerable to interception or a malicious application, grading it and revoking access while the device is compromised, is aimed precisely at this population.
A workforce on personal devices you cannot enrol
Where app protection policies already cover the data but nothing assesses the device itself. Feeding threat defence risk into those policies means a compromised personal phone can be blocked or have corporate data selectively wiped, which closes the one gap that unenrolled protection otherwise leaves wide open.
A regulated firm asked about mobile security
Where a regulator, an auditor or an enterprise client asks how mobile devices are protected, jailbreak detection alone is a thin answer. Graded risk from a recognised vendor, feeding compliance and Conditional Access, with the ability to revoke access while a device is compromised, is a considerably stronger position and it produces evidence.
A managed Android fleet where the app keeps getting killed
Android aggressively suspends and hibernates applications to save power, which is precisely the wrong behaviour for a security agent. On fully managed and corporate-owned work profile devices, the enhanced permissions exempt the mobile threat defence application from suspension, hibernation, power restrictions and user controls so protection actually stays running.
An organisation already paying for a mobile security product
Several of the seventeen listed partners are products organisations already own for other reasons, including Check Point, CrowdStrike, SentinelOne, Sophos, Trellix, Trend Micro and Jamf. Connecting an existing product to Intune so its risk signal drives access decisions is frequently a configuration exercise rather than a purchase.
A mixed estate wanting one answer across platforms
Microsoft Defender for Endpoint is the only entry on the partner list covering Android, iOS and iPadOS, and Windows. For organisations already invested in the Defender family, using it as the mobile threat source as well keeps the signal, the console and the licensing in one place rather than adding a separate vendor relationship.
What organisations actually know about threats on their mobile devices.
| Feature | Mobile Threat Defense | Basic compliance checks | Nothing |
|---|---|---|---|
Jailbroken and rooted devices detected | Yes | Yes | No |
Malicious applications detected | Yes | No | No |
Network attacks detected | Yes | No | No |
Risk graded and compared to an allowance | Yes | No | No |
Access revoked while a device is compromised | Yes | Partly | No |
Covers unenrolled personal devices | Yes | No | No |
Continuous protection on managed Android | Yes | Not applicable | No |
Selective wipe possible on a compromised device | Yes | Partly | No |
Somebody monitors whether it is still working | Should be | Not applicable | Not applicable |
Frequency in the UAE market | Rare | Common | Common in SMEs |
What each state means, and whether protection is actually running.
| State | What it means | |
|---|---|---|
| Enabled | Setup complete and at least one platform toggle on. This is the working state. | |
| Available | Setup complete but no platform toggle on yet. Nothing is being assessed. | |
| Not Set Up | Setup incomplete. Additional steps or permissions needed in Intune or with the partner. | |
| Unavailable | The connector is deprovisioned. The partner needs to talk to Intune to provision it again. | |
| Unresponsive | Not responding. Past the configured day threshold, Intune ignores the compliance state. | |
| Error | An error code, which some partners choose to send in an error case. |
Five steps, and the last one is ongoing rather than a milestone.
- 1
Choose the vendor, once, per platform
Taking account of what you already own, whether Windows coverage is needed, whether certificate inventory matters, and Microsoft recommendation of one vendor per tenant per platform. Configuring two vendors for one platform means every device runs both applications and any failed scan marks the device non-compliant.
- 2
Connect and confirm the connector reaches Enabled
Setup complete and at least one platform toggle turned on, which is what moves the status from available to enabled. Anything short of that means the connector exists and is assessing nothing, which is a state organisations sit in for longer than they realise.
- 3
Set the risk allowance and the enforcement path
Which risk level, low, medium or high, is acceptable, and what happens above it: compliance marked non-compliant feeding Conditional Access for enrolled devices, and app protection policy action including block or selective wipe for unenrolled ones. Both paths should be configured where both populations exist.
- 4
Decide the optional data sharing explicitly
Application inventory and certificate inventory sharing for iOS and iPadOS are opt-in, off by default, and cover personally owned devices as well as corporate ones. That makes them a privacy decision for the organisation rather than a technical default, and it should be made deliberately and recorded.
- 5
Make connector health somebody responsibility
The unresponsive threshold set consciously, connector status visible somewhere it will be noticed, and a named owner. Because past that threshold Intune ignores the compliance state, and the organisation continues believing mobile risk is driving its access decisions when it is not.
What organisations ask about Mobile Threat Defense.
Fifteen questions worth answering first.
Vendor selection
- Do you already have a mobile security product?Several vendors on the list are ones organisations already own.
- Do you need Windows coverage as well?Defender for Endpoint is listed for Android, iOS and Windows.
- Do you need certificate inventory?Microsoft lists one partner supporting it.
- Are you running Jamf for Apple already?Jamf Mobile Threat Defense is on the partner list.
- Are you tempted to run two vendors?Microsoft recommends one per tenant per platform.
Configuration
- What risk level should block access?Low, medium or high, compared with your allowance.
- Are unenrolled devices in scope?App protection policies can consume the same signal.
- Should the Android enhanced permissions be granted?One partner at a time, on managed Android.
- Do you want application inventory sharing?Opt-in, and it covers personal devices too.
- Do you want certificate inventory sharing?Also opt-in, and supported by one partner.
Operations
- Who monitors connector status?Unresponsive for long enough means enforcement stops.
- What is the unresponsive day threshold set to?Set it deliberately rather than inheriting it.
- What happens when a device is flagged?Block, selective wipe, or a conversation.
- Who tells the user why they are blocked?The Company Portal can, if configured.
- Does anybody review the threat findings?A blocked device is a signal, not just an outcome.
The pages around this one.
Intune compliance policies
Where device risk becomes a compliance state, and the tenant settings that decide whether that state is enforced.
App protection policies
How the same threat signal reaches unenrolled personal devices, and what a block or selective wipe does there.
Defender for Endpoint
The Microsoft option, which is the only partner listed covering Android, iOS and Windows together.
Check your connector status, and the unresponsive threshold behind it.
If a connector is anything other than enabled, it is assessing nothing. If it has been unresponsive past the configured threshold, Intune has stopped acting on the compliance state entirely. Both are two-minute checks with significant consequences.
Related Services
Explore more solutions that work great with this service
Intune Compliance Policies
The default that lets unassessed devices through Conditional Access
App Protection Policies
Protect company data on a phone you will never be allowed to manage
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
Microsoft Intune
Device management and endpoint security
Endpoint Security
Defender for Endpoint and Intune managed
Jamf Protect UAE
macOS endpoint security, honestly compared with Defender
MDM Solutions Dubai
Device management across Windows, Apple and Android
Entra Conditional Access
The control that decides who reaches your data