How to patch remote employees’ computers without pulling them into the office

Patches used to be simple. You pushed Windows updates through WSUS on the office network. You ran a quarterly third-party update cycle during a maintenance window. If a laptop was behind, you grabbed it off the employee’s desk on Friday afternoon and fixed it yourself. The feedback loop was tight: the device was on your network, you could see it, you could touch it.

Remote work broke that loop. The laptop is in someone’s home office across three time zones. It is on the corporate network for maybe an hour a week, if at all. If Windows Update is broken, nobody notices until it has been failing for two months. If a critical zero-day drops on Tuesday, you cannot count on the device being online or available during the patch window you pick.

The good news is that the tools to solve this remotely have gotten significantly better. The bad news is that most SMBs have not adopted them, and their patching posture looks a lot worse than it did when everyone was in the office. This guide covers what remote patch management actually looks like in 2026 – the tooling, the cadence, the edge cases, and the reporting that tells you whether it is actually working.

Why remote devices fall behind faster than on-site ones

A few reasons, some of them non-obvious:

They are not on the managed network

In-office devices sit behind the firewall, talk to the internal patch server, and get prodded by network-based tools that notice when they drift. Remote devices do none of those things. Whatever patching happens has to reach out to the device over the public internet, on the device’s own schedule.

Users defer patches constantly

On an unmanaged laptop, Windows or macOS will prompt the user to restart for pending updates. The user clicks “remind me later” for three weeks because they are in the middle of things. The patches are downloaded but not applied. The device looks up to date from the user’s perspective and is actually two months behind.

Third-party software is often missed entirely

Windows Update handles Microsoft products. It does not handle Chrome, Zoom, Slack, Adobe Reader, Java runtime, or any of the hundred other applications that actually represent the attack surface. Unless there is a tool specifically managing third-party patches across the fleet, they drift independently.

Devices go dormant

A remote employee’s laptop spends nights and weekends in a closed lid state. It is on during working hours, offline or asleep the rest of the time. Patch windows that assume 24/7 availability (like “we patch everything at 2am Sunday”) simply miss the device entirely.

Failed patches are invisible

When a Windows update fails on an office machine, IT notices when the status report comes in. When it fails on a remote machine with no one watching, it keeps failing, silently, for as long as it takes someone to audit compliance and realize something is wrong.

BYOD compounds everything

On a company laptop you can enforce patching policy. On a BYOD device, you can require app-level patching for the business apps (via MAM policies), but the OS patching happens on the employee’s schedule. Which is to say, rarely.

The net effect is that a typical unmanaged remote fleet has devices running months behind on Windows Updates, dozens of versions behind on browsers, and with third-party software that has not been updated since whenever it was installed. This is also the fleet the attacker is scanning, continuously, for unpatched vulnerabilities to exploit.

The tooling that makes remote patching work

Remote patch management needs a tool that can reach every device over the internet, apply patches with or without user interaction, report on success and failure, and handle the long-tail edge cases (failed patches, offline devices, pending reboots). Three categories of tool fit the bill, with overlap.

Native platform tools

Microsoft Intune, for Windows and Mac, with the Windows Update for Business feature and the macOS Software Update configuration profiles. Free to Microsoft 365 Business Premium customers, integrated with conditional access, works over the internet without a VPN. For most Microsoft-shops, this is the default answer.

Jamf and Kandji for Mac-focused environments. Both offer native macOS patching with equivalent or better capabilities than Intune on Mac.

For iOS and Android, the device’s own update mechanisms are the baseline, with MDM pushing compliance requirements (“OS must be within two versions of current”). Devices that fall out of compliance get blocked from accessing company resources, which creates the incentive to update.

Dedicated patch management tools

Automox, Action1, PDQ Deploy (with PDQ Inventory), and ManageEngine Patch Manager Plus sit in this category. They focus specifically on patch management across Windows, macOS, Linux, and third-party applications.

Strengths: generally stronger third-party application coverage than Intune, more flexible scheduling, better reporting dashboards, and often cheaper per-endpoint than adding the needed M365 tier just for patching.

Weaknesses: another tool to integrate, does not tie into Microsoft conditional access natively the way Intune does.

For environments where third-party application patching is a priority and Intune’s coverage of those apps feels lacking, a dedicated patch tool running alongside Intune is a common pattern.

RMM platforms

NinjaOne, Atera, ConnectWise Automate, Datto RMM, Syncro, and others typically include patch management as a feature. If you already run an RMM for remote support and monitoring, its patching module is usually sufficient and avoids the tool-sprawl problem.

Quality varies – some RMM patching modules are excellent, others are rudimentary. Evaluate the specific platform against your actual needs.

What the stack usually looks like in practice

For a 20-person Microsoft-focused remote team:

• Intune handles Windows OS updates, driver updates, and Microsoft Store apps
• Intune handles macOS software updates for the Mac users
• Intune or a dedicated third-party patching tool handles browsers, productivity apps, and line-of-business applications
• EDR (Defender for Business, Huntress, SentinelOne) provides the security agent layer that monitors for exploitation of unpatched vulnerabilities while patches are being rolled out

This overlaps meaningfully with the broader endpoint management practice – patching is one piece, compliance enforcement and software deployment are adjacent pieces.

Patch testing and staged rollouts

Patching has always had a tension: patches close security vulnerabilities, but occasionally patches break things. The answer is not to skip patches – that creates far worse risk – but to structure the rollout so breakage is caught early, not after the whole fleet has adopted the problem.

The basic rollout pattern

A three-ring rollout is the standard approach:

Ring 0: Pilot (1-5% of fleet, or a handful of IT devices). Gets patches first, on the earliest-available schedule. Usually IT’s own devices plus a few tech-comfortable early adopters who will report problems clearly. Size: 1-5 devices for a small fleet, more for larger.

Ring 1: Broad deployment (majority of fleet). Gets patches 3-7 days after Ring 0, assuming Ring 0 has not surfaced problems. This is where most devices live.

Ring 2: VIP and business-critical (remainder). Gets patches 1-2 weeks after Ring 0, after the broad deployment has confirmed stability. Includes the CEO’s laptop, the finance team during close week, anyone whose downtime would be particularly painful.

Intune implements this with “deferral days” on update rings. Most patch tools have an equivalent.

What to actually test for

Patches break things in predictable categories:

• Line-of-business applications that depend on specific OS components or runtime versions
• Drivers for specific hardware (docking stations, peripherals, specialized USB devices)
• VPN clients and network tools
• Security agents that occasionally conflict with OS updates
• Browser changes that break intranet web apps that depended on legacy behavior

If you have specific LOB apps or hardware, Ring 0 should include devices that represent the typical configurations of the rest of the fleet. Testing patches only against IT-issued standard laptops misses issues that only manifest on sales laptops with specific driver combinations.

Critical vs non-critical patches

Security patches rated critical by the vendor should not wait for the full three-ring cadence. The right pattern is:

• Critical security patches. Push to the entire fleet within 72 hours. The risk of sitting unpatched is higher than the risk of a rare compatibility issue.
• Important security patches. Normal three-ring rollout, 7-14 days to full deployment.
• Quality updates and non-security. Longer rollout, can wait weeks.
• Feature updates (Windows 11 23H2 → 24H2 type). Much longer cadence, months. Test carefully before broad rollout.

Vendor advisory emails and threat intelligence from your EDR/MDR provider should feed into the decision to compress the cadence for specific patches when active exploitation is observed in the wild.

Forced vs user-deferred patches

The single biggest operational question in remote patching: how much can the user delay?

The spectrum of options

Forced install with scheduled reboot. The device downloads the patch, installs it, and reboots at a specific time whether the user is online or not. Harsh, but guarantees the patch is applied.

Forced install with user-selectable reboot window. The patch is installed, but the user picks when to reboot within a defined window (e.g., within 48 hours). Standard for most remote-first environments.

User-deferred install. The patch is available, the user decides when to install. Fine for optional updates, dangerous for security patches.

No enforcement. Rely on the user to patch voluntarily. Not a real option for business devices.

The pattern that works

For most SMBs with remote fleets:

• Critical security patches: install immediately, allow 24-48 hour reboot deferral, then force reboot.
• Regular monthly patches: install during off-hours, allow 7-day reboot deferral, then force reboot.
• Driver updates and non-critical: install during off-hours, user controls reboot within a reasonable window.
• Feature updates: schedule explicitly, give the user multi-week notice, allow them to choose a date within the window.

The key is that the patch gets installed – the user’s deferral controls when the reboot happens, not whether the patch applies at all.

Handling the “but I am on a call” scenario

The worst patching moment is a forced reboot during a client call. Avoid it by:

• Scheduling enforcement outside core business hours (e.g., reboots only between 8pm and 6am local time)
• Detecting active meetings (Intune can integrate with Teams/Zoom presence in some configurations) and deferring
• Giving the user clear warning dialogs well before the enforced reboot, with the option to reboot earlier

The goal is patches get applied promptly without destroying the user’s trust in the patching process. A user who has been burned once by a bad-timed reboot will find ways to delay patches forever afterward.

Reporting on patch compliance across the fleet

What gets measured gets managed. Patch reporting should tell you, at a glance:

Fleet-wide metrics

• Percentage of devices current on OS patches
• Percentage of devices current on major third-party apps (browsers, Microsoft Office, etc.)
• Median time between patch release and fleet-wide deployment
• Number of devices not seen in the last 7 / 14 / 30 days (these are the devices drifting out of compliance unnoticed)

Per-device detail

For any device, you should be able to answer:

• What patches are installed?
• What patches are pending?
• When was the device last online?
• Have any patches failed to install, and why?
• When is the next scheduled reboot?

Trend tracking

Month-over-month trends matter more than snapshots. If the percentage of compliant devices is trending down, something is systemically failing. If the median deployment time is growing, your pilot ring is too cautious or the cadence is breaking down.

Alerts

Set up alerts for the conditions that actually matter:

• A critical security patch that has not been applied to a device after X days
• A device that has not been seen for 14+ days (check in with the user – is the device lost, retired, or just dormant?)
• Patch installation failures exceeding a threshold (a single failure is noise; a pattern is a problem)
• Any device where a specific CVE being actively exploited has not been patched

Alerts should feed into tickets or the IT team’s normal workflow, not a dashboard nobody looks at.

Handling devices that fall out of sight

Some devices go missing from the patch management system. Categorize and address each one:

Device is legitimately dormant

The employee is on parental leave, sabbatical, or an extended trip. The device is in a drawer. It will come back online eventually.

Handling: Tag it in the inventory, set a calendar reminder to check in at a reasonable interval, plan for the catch-up patching when the device returns (it may need several restart cycles to catch up).

Device has been replaced or retired

The employee got a new laptop and forgot to return the old one, or the old device broke and was replaced.

Handling: Audit inventory periodically. If a device has not checked in for 90+ days and a replacement exists, retire it from the inventory and remove its access. If the old device surfaces later, its access credentials should already be revoked.

Device is compromised or disconnected intentionally

Rare but possible. An employee who is about to leave and is copying data offline. A compromised device that the attacker has disconnected from management.

Handling: Any device that stops checking in without explanation should be investigated. This is exactly the scenario that generic patch compliance reports catch, which is why the alerting on “device not seen for 14 days” matters.

Device has the patch agent broken

Intune or the RMM agent is not running, or is not communicating with the control plane. The device looks offline but is actually in use.

Handling: This is the insidious case. The user thinks everything is fine; IT thinks the device is dormant; nothing is actually being patched. Catch it through cross-referencing with other signals – the user is active in Microsoft 365, EDR agent is still reporting, but the MDM agent is silent. Schedule a remote session to repair the agent.

Dealing with patches that break things

Even with staged rollouts, occasional bad patches slip through. The response matters.

Detection

Users report the problem. EDR flags unusual activity. Applications start failing in ways they did not yesterday. Within a few hours of broad deployment, you should know if a bad patch is in the fleet.

Containment

Stop the rollout to devices that have not received the patch yet. Most patch management tools allow pausing or pulling back a deployment. Do this first, before you fix the affected devices.

Rollback

Some patches can be uninstalled cleanly (most Windows cumulative updates). Some cannot (driver updates, firmware). Know in advance which category your affected patch falls into.

For uninstallable patches, push a rollback via the patch management tool. For non-uninstallable, you may need to restore from a known-good backup or reimage the device.

Communication

Tell the affected users what happened, what the fix is, and when to expect it. Silence creates distrust. A brief explanation (“patch X caused issue Y on some devices, we are rolling it back, affected devices will auto-recover in the next 4 hours”) is what keeps patching relationships functional.

Common remote patching mistakes

• Relying on “Windows Update will handle it.” It does, but not on your schedule, not with the deferral controls you want, and not for third-party applications.
• No third-party patching. The OS is only half the attack surface. Browsers, Office, PDF readers, and line-of-business apps need coverage too.
• Ignoring compliance reporting. If you cannot answer “what percentage of our fleet is current on the latest security patches” in under 30 seconds, your reporting is not working.
• No pilot ring. Pushing every patch to the whole fleet simultaneously means every bad patch is a fleet-wide incident.
• Scheduling patches during business hours. Forced reboots in the middle of the workday are how you lose user trust and drive people to delay updates indefinitely.
• Forgetting BYOD entirely. Personal devices accessing business data need at least the app-level compliance checks and OS version requirements that company devices have.
• Assuming “checked in last week” means “patched.” A device that communicates with the MDM does not necessarily have the latest patches applied. Check the patch status specifically, not just the check-in.
• Not testing feature updates. Windows feature updates (new major versions) break more things than regular cumulative updates. Test them carefully before broad deployment.

How this fits into the broader IT picture

Patch management is one part of endpoint management, which sits inside a broader IT operations practice for remote and hybrid teams. Getting patching right is a specific discipline, but it only delivers value when the rest of the stack is also in place – identity management, device compliance enforcement, endpoint security monitoring, and a functional support process.

A fully patched fleet with no EDR and no compliance enforcement is still exposed. A strict compliance posture with no actual patching is theater. The point is the combination: patches applied systematically, compliance monitored, security agents watching for what the patches did not catch, and conditional access blocking devices that fall out of line.

How Sequentur handles remote patch management for clients

For clients on our managed IT support for remote and hybrid teams with an MDM or RMM platform already in place, remote patch management runs as part of the ongoing service. The cadence is usually:

• Critical security patches deployed within 72 hours of release, after quick validation
• Regular monthly patches deployed on a staged three-ring rollout, completing within 14 days
• Third-party applications patched on a similar staged cadence through the MDM or a dedicated tool
• Feature updates scheduled explicitly with client communication, typically 60-90 days after release
• Weekly compliance reports showing the fleet’s patch state, with follow-up on devices drifting out of compliance
• Monitoring integrated with our MDR service so exploitation attempts against unpatched systems generate real alerts

For clients who do not have a patching platform yet, the initial deployment is scoped as a project that covers tool selection, policy design, ring assignment, reporting setup, and rollout. Once deployed and stable, it transitions into managed IT for ongoing operation.

If your current remote patching approach is “Windows Update is probably running on most of them,” schedule a call and we will walk through what a disciplined remote patching operation looks like for your fleet.