Patching a Remote Workforce: Keeping Laptops Updated Off the Corporate Network

To keep remote laptops patched, stop relying on the corporate network to deliver updates. Move update delivery and device management to services that laptops can reach directly over the internet. Keep bulky update downloads off your VPN where you can, set deadlines that force installs and reboots, and track which devices have stopped reporting in. Then patch the VPN and remote access systems themselves, because they have become the front door for your entire workforce.

Many organizations moved staff to home working very quickly this month. Patch processes built around office networks and on-premises servers often didn't make the trip. This post covers what breaks and how to fix it.

Why do remote laptops fall behind on patches?

Most patching setups assume that devices spend much of their time on the corporate network. Remove that assumption and several things fail at once.

Devices rarely touch the corporate network

Laptops that used to check in with an internal patch server every day may now connect to the VPN only when someone needs a file share or an internal application. If the device isn't connected during the maintenance window, it misses the update. Network-based vulnerability scans miss it too, so you lose visibility at the same time as you lose control.

VPN bandwidth goes to update downloads

Operating system cumulative updates are large, and they arrive for everyone at once. When hundreds of laptops pull the same update through a VPN concentrator sized for a fraction of the workforce, calls drop and applications crawl. Users then disconnect from the VPN to get work done, which takes their laptops further out of reach.

Patch servers sit on-premises

Update servers, distribution points and software repositories usually live in the data center. They were never designed to be reached from the internet, so a laptop at home can only get to them through the VPN, if at all.

Restarts get postponed

Updates often don't take effect until the device restarts. Home users tend to close the lid rather than shut down, and it's easy to keep clicking "remind me later." A laptop can download a patch and still stay vulnerable for weeks.

How can you deliver updates without the corporate network?

The principle is simple: a device should get its policy and its updates wherever it is, without depending on the VPN.

Use cloud-based device management and update delivery

There are three common ways to get there, and many organizations combine them:

• Point devices at the operating system vendor's internet update service and control timing through policy, rather than routing everything through an internal server.
• Use a cloud-based endpoint management service that devices reach over the internet to receive policies, report status and install third-party application updates.
• Extend an existing on-premises management tool with an internet-facing gateway, if your tool supports one, so devices can check in without the VPN.

Whichever you choose, protect the management channel properly. Devices should authenticate to it with certificates or equivalent strong credentials, and administrative access to the console needs multi-factor authentication.

Split tunneling for update traffic

By default, many remote access VPNs use a full tunnel: all traffic from the laptop goes through the corporate network. Split tunneling sends only defined traffic through the tunnel and lets the rest go directly to the internet. One targeted use is to let traffic to vendor update services bypass the VPN.

It works, but it's a trade-off rather than a free win:

If you use it, keep the exclusions narrow: well-defined update endpoints published by the vendor, with everything else still tunneled. Updates from major vendors are digitally signed, which reduces the integrity concern, but make sure the host firewall and endpoint protection stay on. Record the decision and review the exclusion list regularly.

Peer caching

Peer caching lets devices on the same local network share update content, so one device downloads a patch and its neighbors copy it locally. It's very effective in offices and branches. In a home with one corporate laptop, it helps much less.

It still matters for any sites that stay open and for staff sharing a location. Some tools can also share content between devices outside the local network, so check what your tool's peer-to-peer settings allow before relying on it.

Stagger releases

Deployment rings help with bandwidth as well as stability. Release updates to a pilot group first, then roll them out to the rest in waves. That spreads the load on whatever path the downloads take and gives you time to catch a bad update before it reaches everyone.

How do you make sure updates actually install?

Delivery is only half the job. You also need the update installed and the device restarted.

Set deadlines and enforce restarts

Give users a grace period to install and restart at a time that suits them, then enforce it. After the deadline, the device installs the update and restarts automatically, with clear warnings beforehand.

Choose restart timing carefully. Overnight windows that worked for desktops in the office don't help when laptops are closed at night. A forced restart in the middle of a video call won't win you any friends either, so tell staff what to expect and when.

Don't forget third-party applications

Browsers, document readers, runtimes and collaboration tools need patching too. Remote staff now depend heavily on video conferencing and chat applications, which makes those clients more important to keep current. Include them in your cloud-delivered update process rather than treating them as the user's problem.

How do you track devices that go dark?

A laptop that hasn't checked in can't tell you it's vulnerable. Compliance reporting has to come from a source that works off-network, typically your cloud management service or an agent-based vulnerability scanner.

For each device, track at least:

• Last check-in time
• Operating system version and patch level
• Status of key third-party applications
• Time since last restart

Then define what happens as a device stays silent. The thresholds below are an example, so adjust them to your own risk tolerance:

Where your tooling supports it, conditional access is the strongest lever. If a device must meet a minimum patch level before it can reach email or internal applications, it stops being able to fall behind silently.

Patch the VPN and remote access infrastructure too

Your remote access infrastructure may now carry most of your workforce. That makes it both more critical and harder to take down for maintenance.

CISA made this point in its alert AA20-073A, Enterprise VPN Security, released on March 13, 2020. It observed that "As VPNs are 24/7, organizations are less likely to keep them updated with the latest security updates and patches." Its recommendations included:

• Updating VPNs, network infrastructure devices and the devices used to connect remotely with the latest patches and security configurations
• Implementing multi-factor authentication on all VPN connections
• Testing VPN limits for mass usage and using measures such as rate limiting to prioritize users who need more bandwidth
• Preparing IT security staff for more remote access log review, attack detection and incident response

NIST SP 800-46 Rev. 2, the Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security (2016), makes the same case. It recommends that organizations "ensure that remote access servers are secured effectively" and "secure organization-controlled telework client devices against common threats and maintain their security regularly."

In practice:

• Subscribe to security advisories for every VPN appliance, remote desktop gateway and firewall you run.
• Build in redundancy, such as a second VPN concentrator, so you can patch one while the other carries users.
• Treat critical remote access vulnerabilities as emergencies. These devices face the internet by design, which makes them attractive targets.
• Don't expose remote desktop services directly to the internet as a quick workaround for VPN capacity. Put them behind a gateway with multi-factor authentication.

Frequently asked questions

Should we allow split tunneling for updates?

It depends on your risk appetite and compliance obligations. Limited split tunneling for signed vendor update traffic is a reasonable trade-off for many organizations, especially while VPN capacity is tight. Keep the scope narrow, document the decision and review it once the pressure eases.

Do laptops still need the VPN to get patched?

They shouldn't. If your patching depends on VPN connectivity, remote devices will fall behind whenever users disconnect. Move update delivery and status reporting to channels that work over the internet.

What about personally owned devices?

You usually can't patch devices you don't own. Instead, set minimum requirements for access, such as a supported operating system that's up to date, and enforce them where your tools allow. NIST SP 800-46 Rev. 2 covers BYOD security in more depth.

Next steps

• Check how many laptops have reported a patch status in the last seven days. That number tells you how big the gap is.
• Move update delivery and compliance reporting to services that work without the VPN.
• Decide deliberately on split tunneling for update traffic, and document the decision either way.
• Set installation deadlines with enforced restarts, and tell staff what to expect.
• Review the patch status of every VPN and remote access device you run, and plan how to patch them without cutting everyone off.