Intune device compliance baseline for small and mid-size businesses

Microsoft Intune compliance policies define the minimum a device must meet to be trusted with company data. On their own they change nothing on the device; they mark it compliant or not compliant. That status becomes powerful when a Conditional Access policy requires a compliant device to reach Microsoft 365. Microsoft's device compliance overview describes the model.

The settings below are a starting point for organizations of roughly 10 to 1,000 users with Microsoft 365 Business Premium or E3/E5, where Intune Plan 1 is included.

Start with the tenant-wide compliance settings

In the Intune admin center, go to Devices › Compliance › Compliance settings:

• Mark devices with no compliance policy assigned as: set to Not compliant. The default is Compliant, which means an enrolled device that no policy targets passes any "require compliant device" check.
• Compliance status validity period (days): the default of 30 is reasonable. A device that stops checking in becomes noncompliant after this period.
• Enhanced jailbreak detection (iOS/iPadOS): consider enabling if you support iPhones and iPads.

Windows baseline

Create one policy for Windows 10 and later, assigned to all devices (or a pilot group first). Microsoft documents every setting in Windows compliance settings.

Two notes. BitLocker status reported through Device Health Attestation is evaluated at boot, so a device that hasn't restarted since encryption finished can report late; Microsoft's documentation explains the difference between the Device Health and the System Security encryption settings. And avoid adding password rules to Windows compliance if people sign in with Windows Hello for Business; configure sign-in requirements with device configuration instead.

macOS baseline

• Minimum OS version: a currently supported macOS release.
• Require system integrity protection.
• Require encryption of data storage on device (FileVault), with a FileVault policy that escrows recovery keys to Intune.
• Firewall enabled.
• Gatekeeper: allow apps from the Mac App Store and identified developers.

Settings reference: macOS compliance settings.

iOS/iPadOS and Android baselines

Company-owned or enrolled devices

• iOS/iPadOS: block jailbroken devices, set a minimum OS version, require a passcode. See iOS/iPadOS compliance settings.
• Android Enterprise (work profile or fully managed): require the Play Integrity verdict, a minimum OS version and a passcode; encryption is standard on supported devices. See Android Enterprise compliance settings.

Personal phones (BYOD)

Many SMBs don't want to enroll personal phones, and don't need to. App protection policies protect company data inside Outlook, Teams and the Office apps (PIN, no copy to personal apps, selective wipe) without managing the whole device. In Conditional Access, use the Require app protection policy grant for iOS and Android instead of requiring a compliant device.

Actions for noncompliance and grace periods

Each compliance policy has actions for noncompliance. A sensible default:

1. Send email to end user immediately, using a message template that explains what to do and who to contact.
2. Mark device noncompliant after a grace period, for example 3 to 7 days for most settings. The grace period gives people time to restart, update or enable encryption before they lose access.
3. Optionally, a reminder email before the grace period ends.

Avoid automatic retire or wipe actions in a first rollout. They're rarely needed in an SMB and a mistake is expensive.

Enforcing compliance with Conditional Access

1. Assign the compliance policies to a pilot group and watch Devices › Monitor › Noncompliant devices and the per-setting reports for a week or two.

2. Fix what you find: devices that need a reboot, an update or encryption, and stale devices that should be retired.

3. Widen the assignment to all devices, then change the "no compliance policy assigned" setting to Not compliant.

4. Create the Conditional Access policy in report-only mode: all users (excluding break-glass accounts), Office 365 or all resources, Windows and macOS platforms, grant Require device to be marked as compliant (or Microsoft Entra hybrid joined, if you use it).

5. Read the report-only results in the sign-in logs, fix the remaining devices, then enable the policy.

The full policy set is in our Conditional Access baseline.

What compliance doesn't cover

Compliance checks state; other Intune features create it. Alongside the baseline, most SMBs should also have:

• Disk encryption policies that actually turn on BitLocker and FileVault. See encrypt devices with Intune.
• Windows LAPS so every device has a unique, rotated local administrator password. See Windows LAPS with Intune.
• Update rings or feature update policies so devices stay on supported builds. See update rings for Windows.
• Security baselines or endpoint security policies for antivirus, firewall and attack surface reduction. See security baselines.

Pitfalls we see in assessments

• Compliance policies exist, but no Conditional Access policy uses them, so they don't protect anything.
• A policy exists for Windows only, while Macs and phones access the same data.
• A minimum OS version set once and never updated, or set so high that half the fleet fails overnight.
• Hundreds of stale device records that make the compliance numbers meaningless. Clean them up on a schedule.
• Several overlapping policies assigned to the same devices, which makes it hard to see which rule a device failed.

Reading the compliance reports

Once policies are assigned, Intune's reports tell you whether the baseline is working. Look at them weekly during rollout, then monthly:

• Device compliance status: the split between compliant, noncompliant, in grace period and not evaluated. A large "not evaluated" group usually means devices with no assigned policy or devices that haven't checked in.
• Per-setting status: which rule devices are failing. If most failures are one setting (often encryption or OS version), fix that at scale rather than device by device.
• Noncompliant devices: the list to work through with users, sorted by last check-in so stale records stand out.

Microsoft documents the reports in monitor compliance policies.

A realistic timeline

1. Day 1: create the policies and assign them to IT and a few volunteers.
2. Days 2 to 7: fix what the pilot reveals; adjust any setting that fails for reasons you're willing to accept.
3. Week 2: assign to everyone with user emails and a grace period; change the "no policy assigned" default.
4. Weeks 3 to 4: Conditional Access in report-only; chase the remaining noncompliant devices.
5. Week 5: enforce, and tell staff what to do if a device is blocked.

How M365Assessments helps

The M365Assessments Core module reads Intune compliance policies, configuration profiles, endpoint security, Windows Autopilot, app protection policies and update rings with read-only permissions, and flags gaps such as platforms without a compliance policy or devices that aren't compliant. Findings are ranked by severity with a recommended fix. See what we assess or run your first assessment.