Skip to main content

📚🪟💻Compliance - Device Properties - Minimal OS Version

What this policy is about 🔍​

Microsoft ships Windows updates constantly. Security patches, bug fixes, new features.

But here's the problem:

Users delay updates. Devices skip them. And suddenly your "managed fleet" is running 8 different Windows versions—some of them months out of date.

This is a Device Properties Compliance Policy that ensures devices run at least a minimum OS version.

If a device is too far behind?

It's non-compliant.

Why this matters 🤔​

Running outdated Windows versions isn't just inconvenient—it's risky:

  • Security vulnerabilities — Old versions lack critical patches
  • Missing features — Newer security capabilities aren't available
  • Compatibility issues — Apps and policies expect newer builds
  • Support nightmares — Troubleshooting is harder when every device is on a different patch level

By enforcing a minimum OS version, you ensure:

  • Consistent security posture across all devices
  • Predictable behavior when deploying policies or apps
  • Easier support when everyone's on a known-good baseline

Think of it as version control for Windows itself.

How it works 🛠️​

Intune checks the device's OS build number during every compliance check.

If the version is below the minimum you specified, the device is marked non-compliant.

Then you can:

  • Send a notification to the user
  • Block access via Conditional Access
  • Force the device to update before regaining access

Simple. Automated. Effective.

🛠️ Compliance Settings​

Platform​

  • Windows 10 and later

Profile Type​

  • Windows 10/11 compliance policy

Device Properties​

SettingValueWhat it means
Minimum OS version10.0.26100.2161Devices must run at least this build number to be compliant

What's this build number?

The format is: Major.Minor.Build.Revision

  • 10.0 = Windows 10/11 (both share this)
  • 26100 = The actual OS build (e.g., 24H2)
  • 2161 = The specific patch level

You can find the latest build numbers here: Windows release health

Pro tip:

You can use Supervision Tags or a centralized configuration tool to dynamically update this value across all your customer tenants from one place.

That way, when a new security baseline comes out, you update one value—and it rolls out to all your managed customers.

⚙️ Actions for Non-Compliance​

ActionScheduleMessage TemplateAdditional Recipients
Mark device non-compliantImmediately(none)None selected

What this means:

  • Device flagged as non-compliant right away when the OS version is too low
  • No grace period
  • No email or notifications configured

Want to give users a heads-up first?

You can add additional actions:

  • Send email to end user — Warns them before enforcement kicks in
  • Send push notification — Company Portal alert
  • Send email to IT — Alerts your helpdesk about outdated devices

Best practice?

Depends on your deployment strategy:

  • Immediate enforcement works if your update rings keep devices current automatically
  • Grace periods work if users need time to manually update (e.g., work-from-home scenarios where bandwidth varies)

There's no one-size-fits-all. Configure what fits your SLA.

👥 Group Assignments​

✅ Included groups:​

  • All Devices

❌ Excluded groups:​

Why exclude these?

  • IoT devices (kiosks, digital signage) often run specialized images that are updated on a different cadence
  • W365 Boot devices are cloud PCs—Microsoft handles OS updates for those

Applying strict version requirements to those device types would cause unnecessary friction.

🧠 Pro Tips​

Pair with Update Rings​

This compliance policy works best when combined with Windows Update Rings:

  1. Update rings push updates automatically
  2. Compliance policy enforces the minimum version
  3. Conditional Access blocks outdated devices

It's a three-layer safety net.

Use Dynamic Baselines​

Don't hardcode the build number. Use a variable or supervision tag that you can update centrally across all your tenants.

Then when Microsoft releases a new security baseline (e.g., every Patch Tuesday), you update one value—and every customer gets the new minimum automatically.

Example workflow:

  • Microsoft releases 10.0.26100.2500 with critical patches
  • You update your central config: MinimalOSVersion = 10.0.26100.2500
  • Your automation pushes this to all customer tenants
  • Devices below that version are now non-compliant

Scale. Consistency. Control.

Don't Go Too Aggressive​

Setting the minimum version too high can backfire:

  • Devices that can't update immediately (e.g., slow internet, user offline) get locked out
  • Users get frustrated
  • Your helpdesk gets flooded

Best practice:

Set the minimum to one or two months behind the latest build. That gives devices time to update naturally via your update rings, while still blocking devices that are dangerously outdated.

Monitor Compliance Reports​

Check Intune's compliance dashboard regularly.

If you see a lot of devices stuck on older builds:

  • Maybe there's an update ring misconfiguration
  • Maybe devices are paused or deferred
  • Maybe a specific build is causing issues and users are avoiding it

Don't just set it and forget it. Monitor. Adjust. Refine.

Final Thoughts 🧘​

Security is a moving target.

What was "compliant" six months ago might be full of exploits today.

That's why minimum OS versions matter.

They ensure your devices don't just meet yesterday's baseline—they meet today's.

And when a new critical patch drops?

You can enforce it. Fast.

Deploy this policy. Monitor it. Keep your baseline current.

And the next time someone asks, "Are all our devices up to date?"

You'll know the answer. And you'll have Intune enforce it.

Standardize like a pro. Configure with intent. And remember: compliance isn't just about meeting the baseline—it's about staying there.