Getting Started with Windows Autopatch in Microsoft 365 Business Premium

When most people hear “patching,” they immediately think of ransomware, vulnerabilities, and scary headlines. And yes, security is a huge part of it. But that’s not the full story.

We patch software for three main reasons:

1. New features
Updates often introduce new capabilities or improve existing ones. For example, a new Outlook build might bring better search or improved calendar handling.

2. Bug fixes
Software is never perfect. Updates resolve issues that cause crashes, glitches, performance problems, or annoying odd behaviour your users quietly suffer through.

3. Security fixes
This is the big one. When vulnerabilities are discovered in Windows, Office, browsers, or other apps, vendors release patches to close those holes before attackers can exploit them.

If you’re not patching regularly, you’re essentially running known‑broken software in production. That’s not exaggeration; that’s just how the modern software lifecycle works.

In a typical Microsoft‑centric environment, you’ll usually have at least these components to worry about:

• Windows operating system – Windows 10, Windows 11 (hopefully not Windows 7 anymore)
• Microsoft 365 Apps for business/enterprise – Outlook, Word, Excel, PowerPoint, etc.
• Microsoft Edge – the default browser in most modern Windows environments
• Microsoft Teams – which is updated very frequently

Then there’s the non‑Microsoft world – the so‑called third‑party applications:

• Google Chrome
• Adobe Reader
• Mozilla Firefox
• 7‑Zip
• Various line-of-business apps, utilities, VPN clients, and so on

All of these need patching. The operating system might get the most attention, but in real breaches, unpatched third‑party apps are often the weak link.

The challenge is that while Microsoft offers tools to patch its own ecosystem (Windows, Microsoft 365 Apps, Edge, Teams), it doesn’t provide a native solution for third‑party applications. We’ll come back to that point later when we talk about filling the gaps.

One of the core realities of patching is this: sometimes an update breaks something. Not intentionally, but it happens. For example:

• A Windows feature update conflicts with an old accounting system
• A driver update causes blue screens on certain laptops
• A new version of Office affects a legacy add‑in

If you push updates to every device in your organisation at once and something goes wrong, you’ve just created a company-wide outage. That’s painful for users and for IT.

That’s why a basic patching strategy usually looks more like:

1. Patch a small group of devices first (early adopters or IT).
2. Observe for issues for a few days.
3. If everything’s stable, patch a larger group.
4. Repeat until all devices are up to date.

Windows Autopatch is essentially built around this idea of safe, phased rollout.

Manually tracking which machines are updated in spreadsheets or remote tools doesn’t really scale anymore.

For modern patching, you ideally want:

• A cloud-based management platform – so you can manage devices wherever they are (remote, hybrid, on‑prem).
• A central view of all devices – with clear status: compliant, not compliant, pending restart, etc.
• Policy-driven automation – define rules once; the system keeps devices aligned.

This is where Microsoft Intune and Windows Autopatch come in. Autopatch is layered on top of Intune and Entra ID (formerly Azure AD), using them to target, control, and monitor updates across your Windows fleet.

Windows Autopatch is a cloud-based service from Microsoft that automatically manages updates for:

• Windows 10 and Windows 11
• Microsoft 365 Apps (Outlook, Word, Excel, PowerPoint, etc.)
• Microsoft Edge
• Microsoft Teams
• Windows drivers and quality updates (depending on your configuration)

Autopatch uses Entra ID device groups and Intune policies behind the scenes to:

• Register devices with the Autopatch service
• Assign them to different “rings” or phases
• Schedule and enforce updates
• Report on update readiness and compliance

From a practical point of view, it’s designed to make device patching simpler and safer, especially for organisations that don’t have a huge internal IT team or a complex on‑premises WSUS/SCCM setup.

Previously, Windows Autopatch was more often talked about in the context of enterprise licences. The important change is that as of April 2025, Windows Autopatch is now included with Microsoft 365 Business Premium.

That means:

• No extra Autopatch licence to buy
• If you already have Business Premium, you can start using Autopatch at no additional cost
• Small and midsize businesses can access an update management capability that, frankly, used to be more in the “enterprise-only” category

In my experience, this is a pretty big deal for MSPs and in-house IT teams supporting 20–300 devices. It basically lets you move away from manual patch schedules and into policy-driven, automated patching – without introducing another separate tool into the mix.

You still need your devices enrolled in Intune and joined to Entra ID (or hybrid joined), but once that’s in place, turning on Autopatch is surprisingly straightforward.

Before you click any buttons, you need a simple idea of who should get updates first and who should get them last.

For example, imagine a company with 250 Windows devices and four key teams:

• IT team – comfortable with early updates; more technical
• Customer Service – frontline users; moderate risk tolerance
• Finance – critical systems; you really don’t want to break anything here
• Executives – high-visibility users; you definitely don’t want to upset them

A sensible approach might be:

1. Patch IT devices first – they act as your test group.
2. If stable, roll updates to Customer Service.
3. Then roll to Finance.
4. Finally, once you’re confident, update Executive devices.

This plan translates directly into Entra ID device groups and Autopatch deployment rings.

Inside the Microsoft 365 admin ecosystem, you’ll typically:

1. Go to Entra ID (Identity) > Devices to see all your Windows devices.
2. Go to Groups > All groups and create security groups such as:
- `AutoPatch – Test` (for IT devices)
- `AutoPatch – Customer Service`
- `AutoPatch – Finance`
- `AutoPatch – Executive`

You can choose two main membership types for these groups:

• Assigned – you manually add specific devices to the group. Simple and predictable.
• Dynamic device – devices are added automatically based on rules (e.g., OS version, naming pattern, department tag). This is more advanced but powerful at scale.

For many small businesses, starting with assigned groups is absolutely fine. You can always get fancy with dynamic rules later.

Once your groups exist, you assign each device to the right group:

• IT laptops → `AutoPatch – Test`
• Finance desktops → `AutoPatch – Finance`
• And so on

This grouping is the foundation Autopatch will use for phased rollouts.

Now we move into Intune.

In Intune, under Tenant administration, you’ll see Windows Autopatch. From there, you create an Autopatch group – for example:

• `Our Business – Autopatch`

Within that Autopatch group, you define deployment rings. A “ring” is just a phase or wave of rollout.

By default, Autopatch gives you:

• Test ring
• Last ring

For a very small business (say 10–30 devices), those two might be enough:

• Test ring → a few IT/early adopter devices
• Last ring → everyone else

But you can absolutely create more rings to reflect your real-world risk appetite. Using our earlier 250‑device example, you might do:

• Test ring → `AutoPatch – Test` (IT)
• Ring 1 → `AutoPatch – Customer Service`
• Ring 2 → `AutoPatch – Finance`
• Last ring → `AutoPatch – Executive`

Each ring gets updates on a slightly different schedule, giving you a built-in buffer to catch issues before they hit more sensitive users.

Autopatch also supports a dynamic group distribution model. Instead of hard-assigning a single group per ring, you can add multiple groups to a ring and define percentages.

For example, in Ring 1 you might:

• Add `AutoPatch – Customer Service` and `AutoPatch – Finance`
• Set 10% of devices to get the update first
• Then 90% to follow later

Autopatch will then randomly select 10% of the devices across those groups as early recipients, and once those look stable, the remaining 90% are updated. It’s more randomised and can be very handy when you don’t want your rollout to be strictly department‑based.

This isn’t mandatory, but it’s a nice advanced option once you’re comfortable with the basics.

When configuring your Autopatch group, you’ll be asked what types of updates you want it to manage. Typically you’ll enable:

• Feature updates – major OS upgrades (e.g., Windows 10 → Windows 11, or 22H2 → 23H2)
• Quality updates – monthly security and reliability patches
• Driver updates – hardware drivers (network, GPU, etc.)
• Microsoft 365 Apps updates – for Office desktop apps
• Microsoft Edge updates

Feature update settings often include:

• A target Windows version – e.g., “latest Windows 11 version”
• An option to keep older devices on latest Windows 10 if they’re not eligible for Windows 11

Driver updates can be a bit sensitive. Some admins prefer to:

• Auto-approve drivers for the Test ring only
• Use manual review for other rings

To be honest, this is one area where your risk tolerance matters. If you’ve been burned by problematic drivers before, consider a more cautious approach here.

Autopatch uses three timing concepts that are worth understanding. The terms show up a lot in the policy screens:

1. Deferral
A deferral is how long Autopatch waits after an update is released before offering it to a device.

Example: If the quality update deferral for Ring 1 is 9 days, that update won’t even be offered to Ring 1 devices until nine days after Microsoft releases it.

2. Deadline
The deadline is the number of days a user has to install the update once it’s offered.

Example: If the deadline is 5 days, users have five days after the update appears before installation becomes mandatory.

3. Grace period
The grace period is an extra time window after the deadline. Once this ends, the device will force the installation and restart if needed, even if it’s inconvenient.

Example workflow:
- Day 0: Microsoft releases an update.
- Day 9: Deferral ends; Ring 1 devices are offered the update.
- Day 14: Deadline ends; users are out of time.
- Day 16: Grace period (2 days) ends; the update is forced if still not installed.

The nice thing is that Autopatch creates sensible defaults for these values per ring. And yes, you can edit them. For many organisations, the defaults are a good starting point.

You also get control over:

• Reboot behaviour (automatic vs. user-driven)
• Notifications (particularly important for executive devices where surprise reboots are not appreciated)

Once you finish the wizard to create an Autopatch group, Microsoft does quite a bit of heavy lifting automatically.

Behind the scenes, Autopatch creates:

• Update ring policies for Windows in Intune
• Feature update policies
• Driver update policies

If you’ve manually configured Intune update rings before, you’ll recognise many of these. The difference is that Autopatch handles the wiring and coordination for you.

You can later inspect these policies in Intune to see exactly what’s been created—useful if you’re curious or want to align your own custom policies with Autopatch’s behaviour.

Hot patching is a capability that allows certain quality updates (including security fixes) to be installed without requiring an immediate reboot of the device.

Instead of the traditional install → reboot → apply flow, hot patching lets Windows apply changes in memory where possible, keeping the user’s session running.

For IT teams, that means:

• Less pushback from users about “that update popup again”
• Fewer forced reboots during inconvenient times
• A better balance between security and user experience

It’s not that you’ll never need to reboot again—major updates, drivers, and certain deep system changes will still require it—but it can significantly cut down the disruption from regular quality updates.

Within Intune, you manage this under Devices > Manage updates > Windows updates > Quality updates.

The basic flow is:

1. Create a Quality Update policy – for example, `My Business – Quality Update Policy`.
2. Enable “Apply the latest quality updates for security”.
3. Turn on the setting to apply updates without restarting the device when available – this is the hot patching behaviour.
4. Assign the policy to your Autopatch device groups (Test, Customer Service, Finance, Executive, etc.).

From that point on, where hot patching is supported and appropriate, Windows will install those quality updates without forcing a reboot. Users just keep working, and you quietly stay secure in the background.

In my opinion, this is one of those small technical changes that can massively improve how updates are perceived by end users.

After a couple of hours (it’s not instant), devices start registering with the Autopatch service. You can monitor them in Intune under the Windows Autopatch section.

You’ll see:

• Device name
• Update status – up to date, not up to date, or in progress
• Autopatch readiness – whether the device meets requirements and is properly onboarded
• Autopatch group & deployment ring – which policy set it’s following
• Last check-in time

There’s also an option to “Discover devices” or scan Autopatch groups manually, which basically forces a refresh to pick up newly added devices instead of waiting for the hourly background job.

If a device shows as not registered or excluded, the usual culprits are:

• The device isn’t properly enrolled in Intune.
• It’s not in any of the groups you targeted with Autopatch.
• There’s a configuration conflict or prerequisite missing.

This dashboard is where you’ll spend your time checking that:

• Updates are rolling out as expected.
• Specific devices aren’t stuck or failing repeatedly.
• Each ring is behaving according to your plan.

Here’s an important limitation to understand clearly: Windows Autopatch only covers Microsoft software:

• Windows OS
• Microsoft 365 Apps
• Edge
• Teams
• Windows updates like drivers and quality patches

It does not patch third-party tools such as:

• Google Chrome
• Adobe Reader
• Firefox
• 7‑Zip
• Most other vendor applications

And realistically, Microsoft has shown little interest in becoming a third‑party patching provider. That’s probably not going to change.

So how do you handle those apps?

Typical options include:

• Third-party patching services that integrate with Intune – there are several cost-effective tools on the market that plug into Intune, provide application catalogues, and keep non‑Microsoft apps up to date.
• Traditional RMM tools – if you’re an MSP, your remote monitoring and management platform may already include third‑party patching capabilities.
• Custom packages + Intune – more manual, but you can package installers and updates for key apps and deploy them as line‑of‑business apps.

Whichever route you choose, the big takeaway is: Autopatch is a huge step forward, but it does not eliminate the need for a separate third‑party patching strategy.