Windows Autopatch: Will MSPs Still Need a Patch Management Solution?

On April 5, 2022, Microsoft announced their new Windows Autopatch feature to take the burden of patching off the shoulders of overwhelmed IT departments. With a planned released date of July 2022, it’s worth getting educated about this new service from Microsoft and what its potential impacts on the MSP ecosystem will be. Spoiler alert: It’s not that big of a deal. 

What is Windows Autopatch?

You would be forgiven for asking “Isn’t Autopatch just Auto Update with a price tag?” The key differences are control, scheduling, offloading of management, and patch auditing. Windows Autopatch will be a service available from Microsoft to keep Windows and Office software up-to-date on any enrolled endpoints. 

Windows Autopatch will leverage Microsoft secret sauce to place enrolled devices in dynamically created testing rings: Test, First, Fast, and Broad Rings. A small number of endpoints will be in the Test Ring with more devices being added to each subsequent ring until every device is assigned. You’ll be able to manually move devices into different rings as necessary. Updates will then be applied starting with the Test Ring, allowing enough time for patches to be applied and metrics measured before moving on to the next ring. Security and quality updates will be rolled out more quickly than feature updates, with feature updates being deferred for up to 30 days between rings. This should all sound very familiar to most MSPs. 

There are also familiar functions like pausing updates, deferring updates, and uninstalling patches that might be causing issues. These have long been standard in most third-party patching solutions that exist. N-able’s Patch Management has had these features for many years. 

One of the biggest benefits of Window Autopatch is offloading the responsibility of patching systems to a third-party for overburdened IT departments. For MSPs though, that would be like hiring another MSP to handle patching for you clients. Not that you can’t do that, but it might not be the best business decision. 

What are the prerequisites for Windows Autopatch?

Here’s the real showstopper for the use of Windows Autopatch for MSPs. The prerequisites for its use are rather high and most MSP clients are unlikely to reach the thresholds.

While more MSPs than ever are leveraging Azure AD and Intune for their clients, the E3 license is the real kicker. Most SMBs are likely using Microsoft 365 Business Basic or Standard licenses (if any at all) and adding either supplemental licensing or upgrading licenses is going to be cost-prohibitive for just this one service.

How will this impact MSPs today?

The short answer is that the introduction of Windows Autopatch will not have a sizeable impact for MSPs. The aforementioned prerequisites will set the bar too high for many SMBs, the majority of which that are managed by MSPs will likely be running with nothing more than Windows Pro or Home licenses. 

Chris Dunsmore, N-able’s Product Manager for Patch Management, also sees other limitations for applying the use of Autopatch to the MSP space. "Autopatch is an interesting concept from Microsoft, however I think they missed the mark for their target audience with it and, as such, have created something which suits a very niche group somewhat closer to an SMB with no dedicated or outsourced IT support," he says. "They state their intent of Autopatch is to provide a service that meets the needs of their broad set of customers and act as their 'Update Admin'. This seems more like a more advanced “auto-update” feature which MSP’s and Internal IT teams typically disable in patching policies."

He adds: "Whilst Autopatch has its plus points, it is not a complete solution suitable for MSP’s, it removes a lot of the controls, makes patching more random and would have to be used in parallel with another tool which can update the servers, third-party products, and emergency security patches for older operating systems."

This brings us to the good news. If you’ve been providing patch management as part of your managed services contracts, you’ve already been delivering the service that Microsoft is offering. This means if your clients have questions about this new Microsoft service they heard about, the conversation will be easy to navigate. “We already provide Windows, Office, plus third-party patching as part of our regular managed services. If we transition you to the Windows Autopatch service it’s going to cost you an extra “X” amount more per month and we will have to charge “Y” for project costs to update your licensing all for the same end results” is likely to bring their interest in Windows Autopatch to a screeching halt. 

For MSPs that co-manage IT departments or for MSSPs it might be a different story. If you are supporting enterprise environments Windows Autopatch could have the potential to replace a full-time employee or even a whole team. There are big opportunities but a scarce number of situations where you’ll find that opportunity. 

What can be learned from Windows Autopatch?

While we can’t ascribe motivation for the introduction of Windows Autopatch, there is a clear need for automating of patching in enterprise environments. The pressures that drive that need to automate patching in large, complex environments are the same pressures that drive the need to automate patching in smaller, less complex environments. The primary pressure being the remediation of vulnerabilities and threat mitigation. Keeping operating systems and applications fully patched and updated is one of the most effective and essential security controls available to defenders. 

MSPs have been carrying this out for years through the use of WSUS, PowerShell or other tools like Patch Management. This is well-treaded territory for MSPs, but that doesn’t mean you can’t take a look at Windows Autopatch and see if there are any good ideas in its implementation you can adapt for yourself. I have always advised having a testing environment vs production environment for patching, but you can always do better. The Deployment Rings and Ring Groups as described by Microsoft that determine what devices are enrolled in Windows Autopatch can easily be adapted to be used by other patching processes or solutions. At smaller scales, having multiple different groups of workstations being enrolled in different patching windows might not make much sense but once you’re patching at scale with hundreds of workstations per department, the ability to have a first, second, and everyone-else approach can improve the logistics and automation of patching. 

Summary

This looks to be a case where Microsoft is introducing a new service that MSPs have been pros at delivering for the past decade. While it’s reassuring to see Microsoft bring forth a new service to help improve the cybersecurity stance of enterprise scale businesses, it misses the mark when it comes to providing a patching solution for SMBs that make up the bulk of the MSP client base.

Know what it is, try to take away some lessons on how it’s implemented, but I wouldn’t lose any sleep over it making possible inroads to the MSP channel. 

This guest blog is courtesy of N-able. Author Lewis Pope is the head security nerd at N-able. You can follow him on Twitter (@cybersec_nerd), LinkedIn (thesecuritypope) or Twitch (cybersec_nerd). Read more N-able guest blogs here. Regularly contributed guest blogs are part of ChannelE2E’s sponsorship program.