Mobile Compliance in Intune for iOS and Android

A mobile compliance policy defines what a 'healthy' device is before it reaches your data. On iOS and Android, Intune continuously evaluates key criteria — jailbreak or root, OS version, encryption, passcode — then passes the verdict to Conditional Access, which allows or blocks access to Microsoft 365 resources. It is the brick that links a device's real state to a concrete access decision, and therefore the core of a mobile strategy aligned with NIS2, ISO 27001 and GDPR.

The essential criteria

A good policy stays simple but covers the major risks. Each unmet criterion marks the device as non-compliant and triggers the defined action. A few clear, enforced rules beat a long list that is never upheld.

What to check first

These criteria cover most mobile compromise scenarios, from jailbreak to missing security patches.

• Block jailbroken (iOS) or rooted (Android) devices, a sign of compromised integrity.
• Require a minimum OS version to benefit from security patches.
• Enforce encryption of the device storage.
• Require a passcode or biometrics to unlock the device.

Adapting criteria to iOS and Android

The two platforms don't expose exactly the same signals. Encryption is native and generally active on recent iOS, while Android needs particular attention depending on the manufacturer. Defining a policy per platform lets you match each one's specifics without compromise.

From compliance verdict to Conditional Access

Compliance alone prevents nothing: it produces a verdict, but Conditional Access enforces the decision. A non-compliant device is denied access to Exchange, Teams or SharePoint until it is brought back into compliance. Without this pairing, the policy remains a mere informational dashboard.

1. 1Define a separate iOS compliance policy and an Android one.
2. 2Configure jailbreak/root, minimum OS and encryption criteria.
3. 3Set an action for non-compliance, with a grace period.
4. 4Create a Conditional Access rule requiring a compliant device.
5. 5Target sensitive apps (Exchange, Teams, SharePoint) in the rule.

Deploy without breaking usage

The main danger of a compliance policy is blocking legitimate users en masse overnight. A gradual introduction, with education and clear remediation, makes all the difference between smooth adoption and an avalanche of tickets.

Grace period and remediation

Introduce a grace period to give users time to update or encrypt their device. Provide an explicit remediation path: what exactly must the user do to become compliant again? Communicate the reasons to turn a constraint into a security reflex.

• Test first on a small pilot group before the whole fleet.
• Provide a grace period before access is actually blocked.
• Supply clear, accessible remediation instructions.
• Communicate upfront on the reason for each requirement.
• Monitor the compliance report to spot recurring drift.

Common mistakes to avoid

A few classic pitfalls turn good intentions into a production incident.

• Enabling immediate blocking with no grace period or communication.
• Forgetting to pair compliance with Conditional Access, making it ineffective.
• Requiring an OS version some fleet devices cannot reach.
• Neglecting remediation and leaving the user without a clear solution.
• Creating a single iOS/Android policy instead of two tailored ones.

Compliance defines trust; Conditional Access enforces it.

A concrete example

A company decides to require encryption and a minimum Android version on phones accessing Exchange. Rather than switching blocking on overnight, it configures the policy in non-blocking mode for two weeks. The compliance report then reveals that a dozen devices run an OS version that is too old, never updated by their users. Thanks to the grace period and clear instructions, those users update their phones before the deadline. On the day Conditional Access becomes blocking, nearly the whole fleet is already compliant: no mass lockout, no flood of tickets.

This example shows that the success of a compliance policy depends as much on the rollout method as on the chosen criteria. Observing before blocking, communicating and allowing time turns a potentially blunt measure into a gradual, accepted security uplift. It is also what lets you present an auditor not just rules, but proof that they are actually enforced and followed over time.

Monitoring and maintaining compliance over time

A compliance policy is not a one-off project but a living process. Devices evolve, new OS versions ship, users join or leave the company. Without continuous monitoring, the compliance rate quietly degrades until an incident reveals it. The Intune compliance report is your dashboard: review it regularly to spot trends and recurring gaps before they become problems.

• Review the compliance report regularly to track trends.
• Adjust the minimum OS version as major updates ship.
• Watch for devices that frequently flip into non-compliance.
• Revise criteria at each regulatory change.
• Keep a history to feed your audit evidence.

This continuous monitoring is what separates compliance on paper from compliance in reality. It is what lets you demonstrate, at any moment, that your mobile fleet durably meets your NIS2, ISO 27001 and GDPR obligations rather than just met them once.

Strengthening compliance with mobile threat risk level

The basic criteria (jailbreak, minimum OS, encryption) describe the device's static state, but not the active threats bearing down on it. To go further, Intune can consume the risk level computed by a Mobile Threat Defense solution, such as Microsoft Defender for Endpoint on iOS and Android. A device exposed to a malicious app, a rogue Wi-Fi network or a phishing attempt sees its risk level rise, which can flip it into non-compliance in near real time. Compliance then stops being a snapshot taken at enrollment and becomes a dynamic evaluation that follows the device.

1. 1Connect the Mobile Threat Defense solution to Intune through its dedicated connector.
2. 2Deploy the protection app (Defender for Endpoint) to the targeted iOS and Android devices.
3. 3Set the maximum tolerated risk level in the compliance policy, for example low.
4. 4Let Intune mark non-compliant any device whose risk exceeds that threshold.
5. 5Pair with Conditional Access to block access until risk returns to an acceptable level.

Take a user who sideloads a booby-trapped Android app from outside the catalog. The threat defense solution detects the malicious behavior and raises the device risk level to high. Because the compliance policy allows only a low risk, the device flips into non-compliance immediately, and Conditional Access denies it Exchange and Teams. The user is prompted to remove the offending app; once the threat is neutralized, the risk level drops and access is restored automatically. All of this without manual IT intervention, and with a full trail usable for audit.

How AuPoint helps

AuPoint turns these requirements into ready-to-use compliance policies and Conditional Access rules, in plain language and without PowerShell. An impact preview shows who would be blocked before you enable a rule, and reversible policies let you adjust risk-free. You align iOS and Android with your NIS2, ISO 27001 and GDPR obligations, with compliance evidence ready for an audit.

Frequently asked questions

Do you need separate policies for iOS and Android?

Yes, it is recommended. The two platforms expose different signals and settings; one policy per system lets you match each one's specifics without compromise and eases maintenance.

What happens during the grace period?

The device is flagged non-compliant but temporarily keeps access, with notifications prompting the user to become compliant. When the period expires, Conditional Access enforces the block.

Is compliance enough without Conditional Access?

No. Without Conditional Access, compliance only produces an informational verdict. Conditional Access is what translates that verdict into an effective allow or block of data access.

Is the mobile threat risk level indispensable?

No, it is not mandatory to get started. The static criteria (jailbreak, OS, encryption) already form a solid, sufficient baseline for most organizations. The mobile threat risk level is an additional layer, recommended for sensitive environments, that adds dynamic detection of compromises in progress rather than limiting the check to the device's configuration state.

Ready to align your mobile fleet with your regulatory obligations without PowerShell? With AuPoint, deploy your compliance policies and Conditional Access rules in a few clicks, with confidence.