In this module
AD3.4 macOS, iOS, and Android Compliance
Figure AD3.4 — Compliance checks available by platform. Windows has the most granular checks. macOS covers encryption and OS version but has fewer security-specific checks. iOS always encrypts and detects jailbreaking but has no traditional AV check. Android supports encryption and root detection but enforcement consistency varies by manufacturer. Each platform gets a tailored policy.
Building the macOS compliance policy
Navigate to intune.microsoft.com → Devices → Compliance → Create policy → Platform: macOS.
Name: "macOS Security Compliance"
System Security:
- Require a password: Required (minimum 6 characters, alphanumeric)
- Firewall: Enable
- Incoming connections: Block (blocks unsolicited inbound connections)
- Stealth Mode: Enable (hides the Mac from responding to probing requests)
Device Health:
- Require System Integrity Protection: Required (SIP prevents modification of protected system files — disabling it is a red flag for compromise or unsanctioned development tools)
Device Properties:
- Minimum OS version: Set to the current macOS version minus one (e.g., if the current release is macOS 15 Sequoia, set the minimum to 14.x Sonoma). This gives users one version of flexibility while keeping them on supported releases.
Encryption:
- Require FileVault: Required (FileVault is the macOS equivalent of BitLocker — full disk encryption using XTS-AES-128 with a 256-bit key)
Set the same grace period and notification actions as the Windows policy: 7-day grace period, email notification on non-compliance.
Building the iOS compliance policy
Navigate to intune.microsoft.com → Devices → Compliance → Create policy → Platform: iOS/iPadOS.
Name: "iOS Security Compliance"
Device Health:
- Jailbroken devices: Block (a jailbroken iOS device has bypassed Apple's security controls — it can run unsigned code, has disabled sandboxing, and is fundamentally untrustworthy for corporate data)
Device Properties:
- Minimum OS version: Set to the current iOS version minus one (e.g., iOS 17.x if iOS 18 is current). Apple's update cadence means older versions lose security patches quickly.
System Security:
- Require a passcode: Required
- Minimum passcode length: 6
- Maximum minutes of inactivity before passcode is required: 5
iOS devices are encrypted by default when a passcode is set — you don't need a separate encryption check. The passcode requirement effectively ensures encryption is active.
Building the Android compliance policy
Navigate to intune.microsoft.com → Devices → Compliance → Create policy → Platform: Android Enterprise (work profile).
Name: "Android Security Compliance"
Device Health:
- Rooted devices: Block (equivalent to jailbreak detection on iOS)
- Google Play Services is configured: Required
- Up-to-date security provider: Required
- SafetyNet device attestation: Check basic integrity and certified devices
Device Properties:
- Minimum OS version: Set to Android 13 or later (older versions lack critical security features and don't receive regular patches)
System Security:
- Require a password: Required (minimum 6 characters)
- Encryption of data storage on device: Required
Android compliance varies by manufacturer. Samsung Knox devices support additional compliance checks (firmware integrity, TIMA attestation). Standard Android Enterprise devices support the basic checks above. If you have a mix of manufacturers, the compliance policy should target the common denominator — checks that work on all Android Enterprise devices.
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'macOS'" |
Select-Object DeviceName, IsEncrypted, ComplianceState, UserPrincipalName |
Format-Table -AutoSizeYour organization has 20 employees who use personal iPhones to access company email through the Outlook mobile app. You want to enforce device compliance via CA003, but these users refuse to enroll their personal phones in Intune. How do you protect corporate data on these devices?
Option A: Exempt personal devices from compliance — they access email through the app, not the device.
Option B: Configure an App Protection Policy for Outlook and Teams that encrypts corporate data within the app, restricts copy/paste to other managed apps, and allows remote wipe of corporate data only. Modify CA003 to accept either device compliance OR app protection policy.
Option C: Block all mobile access — users can only access email from compliant laptops.
The correct answer is Option B. App Protection Policies provide data protection at the application level without requiring device enrollment. Corporate data inside Outlook is encrypted, isolated from personal apps, and remotely wipeable without touching personal photos or messages. Modifying CA003 to accept "compliant device OR app protection policy" allows both paths: corporate laptops use device compliance, personal phones use app protection. Option C (blocking mobile access) is disproportionate and creates shadow IT risk — users will forward email to personal accounts if you block mobile access entirely.
Try it: Create compliance policies for your non-Windows devices
Check how many non-Windows devices access your M365 data: navigate to intune.microsoft.com → Devices → All devices and filter by OS. Note the count for macOS, iOS, and Android.
If you have macOS devices: create the macOS compliance policy with FileVault, SIP, and OS version checks. If you have iOS devices: create the iOS policy with jailbreak detection and passcode requirements. If you have Android devices: create the Android Enterprise policy with root detection and encryption.
For BYOD devices not enrolled in Intune: navigate to intune.microsoft.com → Apps → App protection policies. Check if any app protection policies exist. If not, create one for iOS and Android targeting Outlook and Teams with these settings: encrypt app data, block copy/paste to unmanaged apps, require PIN for app access, enable remote wipe of corporate data.
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.