Let the connector go quiet for long enough and Intune simply stops enforcing the compliance state at all.
This feeds device risk into your compliance policies, into Conditional Access and into app protection, and it reaches devices nobody ever enrolled. A genuinely useful control, carrying one property everybody should know about: a connector that goes unresponsive and unnoticed means the risk signal quietly stops counting for anything.
- 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 anything, and nothing anywhere tells you.
This is the property that separates a mobile threat defense deployment that works from one that provides false assurance.
- Six states are documented: unavailable, not set up, available, enabled, unresponsive and error. Operationally the one that matters is unresponsive, where the connector has stopped answering without having actually failed.
- Let that state persist past the configured day threshold and Intune stops paying attention to the compliance state altogether. What that means in practice is that phones stop being assessed for risk, compliance stops reflecting any of it, and Conditional Access stops acting on it, with nothing visibly broken anywhere.
- The company carries on believing that mobile risk is feeding its access decisions. It is not. And because nothing technically failed, no ticket gets raised and no alert fires unless somebody deliberately built one.
- The remedy is simple and has to be deliberate. Watch connector status as an operational item, choose the unresponsive threshold consciously rather than inheriting whatever number was there, and give one person responsibility for noticing. An hour to arrange, and it is the whole difference between having a control and merely believing you have one.
Eight things that decide whether any of this actually protects a phone.
A risk level, compared to an allowance you set
The application on the phone scans and reports back to its vendor, the threat is rated low, medium or high, and that rating gets compared against whatever risk allowance you set in Intune. Depending on the comparison, access to resources is withdrawn for as long as the device stays compromised. That is the entire mechanism, and it means the allowance you configured is the real control here rather than the scanning.
The unresponsive connector, which silently stops enforcement
Six connector states are documented, and one of them deserves your attention: unresponsive. Once the connector has been unresponsive for the number of days set in the corresponding threshold, Intune stops paying attention to the compliance state entirely. So the control fails open, silently, after a number somebody configured and almost certainly does not remember. Watching connector status is not an optional refinement.
It works on devices you do not manage
The same data works on devices nobody enrolled, by way of app protection policies, so company data inside a protected application can still be defended and a block or a selective wipe still issued. For a workforce where most mobile access happens on personal phones nobody is ever going to enroll, that extends the control to precisely the population it normally cannot reach.
One vendor per platform, and Microsoft explains why
Stick to one vendor per tenant per platform. More than one is technically supported for compliance purposes, but run two on the same platform and every device there has to carry both applications and scan with both, and a single failure to submit from either one marks the device non-compliant. Defender for Endpoint sits outside that recommendation.
Enhanced permissions on managed Android, for one partner
On fully managed and corporate-owned Android devices you can grant your chosen partner enhanced permissions, exempting their application from being suspended, hibernated, power-restricted or interfered with by the person holding the phone, so protection carries on uninterrupted. Those permissions go to one partner at a time, which reinforces the point about sticking to a single vendor per platform.
Data sharing is opt-in and off by default
Two inventory sharing services exist for Apple mobile devices, one covering applications and one covering certificates, and both are opt-in with nothing shared until an administrator explicitly enables them. Since both reach personally owned phones as well as company ones, that default is the correct one, and changing it deserves an actual conversation rather than somebody clicking a toggle.
Certificate inventory, supported by exactly one partner
Certificate sync lets a supported partner ask about the certificates installed on an enrolled Apple mobile device, sharing the account and device identifiers, who owns the device, and a list of certificates including the common name and whether each is an identity. Exactly one partner is listed as supporting it. If that capability matters to you, it narrows the vendor choice down considerably.
Seventeen partners, and one of them covers Windows too
Seventeen products in total, from Better Mobile and BlackBerry through Check Point, CrowdStrike, iVerify and Jamf, then Lookout, Microsoft Defender for Endpoint, Pradeo, SentinelOne and Sophos, then Symantec, Trellix, Trend Micro, Trustd, the Windows Security Center and Zimperium. Nearly all of them handle both Android and Apple mobile devices. Defender for Endpoint is the only one reaching Windows as well.
Four things that keep this from becoming an assumption.
Connector health becomes an operational item on the first day
Because a connector left unresponsive past the configured threshold means Intune disregards the compliance state entirely, and nothing about that failure is visible to anybody who is not deliberately looking. We choose the threshold on purpose, put the connector status somewhere it will actually be seen, and name the person responsible for noticing. An hour of work, and it is what turns the deployment into something real.
We settle the vendor question before configuring anything
One vendor per tenant per platform is the recommendation, and the cost of ignoring it is spelled out: every device on that platform has to install every configured application and scan with all of them, and any one of them failing to submit marks the device non-compliant. Companies already owning two mobile security products need to pick one rather than deploying both and hoping.
We extend it to unenrolled devices deliberately
That same threat data drives app protection policies on devices nobody enrolled, allowing a block or a selective wipe of company data inside a protected application. Across most American workforces that unenrolled group is the larger of the two, and it is the half most companies leave entirely uncovered because they assume this needs enrollment to work at all.
We treat the inventory sharing decision as a decision
Both inventory sharing services are opt-in and off until somebody enables them, and both reach personally owned phones as well as company ones. Handing a third-party vendor a list of the applications on an employee personal phone is a privacy decision rather than a configuration toggle, and the state privacy laws are reason enough to treat it as one. We raise it explicitly so the decision gets made rather than discovered afterward.
Six US situations where mobile threat risk is worth acting on.
Executives and high-value targets on mobile
Senior people reading sensitive material on a phone, traveling constantly, joining networks nobody vetted, and worth targeting specifically because of who they are. Spotting a network open to interception or a malicious application, rating it, and withdrawing access for as long as the device stays compromised is aimed squarely at exactly this group.
A workforce on personal devices you cannot enroll
Where app protection already covers the data and nothing whatsoever assesses the phone underneath it. Feeding threat risk into those policies means a compromised personal device can be blocked outright, or have the company data selectively wiped out of it, which closes the single gap unenrolled protection otherwise leaves standing open.
A regulated firm asked about mobile security
When an insurer, a SOC 2 auditor, a HIPAA risk assessment or a large customer asks how the phones are protected, jailbreak detection on its own is a thin answer that invites a follow-up question. Graded risk from a recognized vendor, feeding compliance and Conditional Access, with the ability to withdraw access for as long as a device is compromised, is a far stronger position and it generates evidence as it goes.
A managed Android fleet where the security app keeps getting shut down
Android suspends and hibernates applications aggressively in the name of battery life, which is precisely the wrong instinct where a security agent is concerned. On fully managed and corporate-owned devices, the enhanced permissions exempt that application from suspension, hibernation, power restrictions and interference by the person holding the phone, so the protection genuinely keeps running.
An organization already paying for a mobile security product
A good many of those seventeen are products companies already own for entirely unrelated reasons, Check Point, CrowdStrike, SentinelOne, Sophos, Trellix, Trend Micro and Jamf among them. Connecting something you already have to Intune so that its risk signal starts driving access decisions is very often a configuration exercise rather than anything requiring a purchase order.
A mixed estate wanting one answer across platforms
Defender for Endpoint is the only entry on that list reaching Android, Apple mobile and Windows all at once. For a company already committed to the Defender family, using it as the mobile source as well keeps the signal, the console and the licensing together rather than adding another vendor relationship to manage.
What organizations 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 |
Answers a mobile security question with evidence | Yes | Thinly | No |
What each state actually means, and whether anything is being protected.
State
Enabled
- What it means
- Configured, with at least one platform switched on. This is the one you want.
State
Available
- What it means
- Configured, but with no platform switched on. Nothing whatsoever is being assessed.
State
Not Set Up
- What it means
- Not finished. Further steps or permissions are needed either in Intune or at the vendor end.
State
Unavailable
- What it means
- Deprovisioned entirely. The vendor has to reach out to Intune before it exists again.
State
Unresponsive
- What it means
- Silent. Once past the day threshold you configured, Intune disregards the compliance state completely.
State
Error
- What it means
- An error code, which some vendors send and others do not bother with.
Five steps, and the final one never finishes because it is not a milestone.
- 1
Choose the vendor, once, per platform
Weighing what you already own, whether Windows needs covering, whether certificate inventory matters to you, and the recommendation of one vendor per tenant per platform. Configure two for a single platform and every device there runs both applications, with a failed scan from either one marking it non-compliant.
- 2
Connect and confirm the connector reaches Enabled
Configured, with at least one platform switched on, which is what moves the status from available to enabled. Anything short of that leaves you with a connector that exists and assesses precisely nothing, and companies sit in that state for far longer than they realize.
- 3
Set the risk allowance and the enforcement path
Deciding which risk level you will tolerate, whether low, medium or high, and what happens above it. For enrolled devices that means being marked non-compliant and Conditional Access acting on it. For unenrolled ones it means an app protection action, whether a block or a selective wipe. Where both populations exist, both paths need configuring.
- 4
Decide the optional data sharing explicitly
Both inventory sharing services for Apple mobile devices are opt-in, off until enabled, and reach personally owned phones alongside company ones. That makes each a privacy decision for the company rather than a technical default, and it should be taken deliberately and written down somewhere.
- 5
Make connector health somebody's responsibility
The unresponsive threshold chosen deliberately, the connector status displayed somewhere a human will actually see it, and one person named as the owner. Because beyond that threshold Intune disregards the compliance state entirely, while the company carries on believing mobile risk is driving its access decisions.
What organizations 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 organizations already own.
- Do you need Windows coverage as well?Defender for Endpoint appears against Android, Apple mobile and Windows alike.
- 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 phone is telling you something, not merely producing an outcome.
The pages around this one.
Microsoft Intune
Where device risk becomes a compliance state: enrollment, compliance policies and the tenant settings that decide whether that state is enforced.
Defender for Endpoint
The Microsoft option, and the only partner on the list reaching Android, Apple mobile and Windows at once.
Endpoint security
The wider endpoint practice across platforms, and where mobile fits alongside laptops and servers.
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
Microsoft Intune
Device management and endpoint security
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn more