Why this matters
Most break-ins start with a bug that already has a fix. A laptop running a browser that is two versions behind is the easiest way into your network, and it does not need anyone to click a bad link to get there. Keeping every laptop patched is a routine you run, not a product you buy.
Laptops leave the building. They sit in bags, on hotel Wi-Fi, on home routers, and on a shelf for three weeks while someone is on leave. You cannot wait for a device to come back to the office network before it gets updates, so the process has to work over the internet, unattended, and it has to survive a user who clicks remind me later every day for a month.
There are three buckets, not one. The operating system handles its own updates and some drivers. Everything sitting on top of it, meaning browsers, PDF readers, runtimes, the VPN client and the meeting app, updates on its own schedule or not at all. Firmware, the BIOS and dock firmware, is the third bucket and the one people remember only after a dock stops working.
Before you start
Put one name on this job. Someone has to open the patch report every week, find the devices that did not update, and chase the people who own them. At a small company that is a couple of hours a week, but it needs an owner or it quietly stops happening.
Work out what your current tools can actually do. Windows Update for Business with Group Policy or Intune covers Windows machines well. Macs need a management tool for the same level of control. A patch agent that carries its own catalog of third party apps saves you from tracking each vendor by hand. Check three things before you commit: can it report on third party apps, can it force a restart, and can it reach a laptop that is not on the office network.
Decide your rings and your maintenance windows before the first push. A pilot ring of 5 to 10 percent, made up of IT and a few volunteers. A broad ring a few days later. A late ring for the finance team that runs an old payroll client which breaks on some updates. Then agree with the business on when a restart is acceptable. Ask finance about month end and sales about quarter end.
Escrow your BitLocker recovery keys and make sure you can reach them from a phone. A firmware update can trigger a recovery prompt at boot, and if the key lives only on the locked machine, you have locked out a user for the afternoon. While you are in there, check that laptops have enough free disk space for a feature update and that they are set to wake for maintenance.
How to do it
The routine has four parts. Know what is installed, publish patches on a schedule, set a deadline that ends in a forced restart, and report on what actually landed rather than what was offered.
Write it down as a one page runbook with days on it. Microsoft ships on the second Tuesday of the month. Apple and most third party vendors ship throughout. Your runbook should say which ring gets what on which day, and who signs off before the broad ring opens.
Then run the same cycle every month and review it after each one. Consistency is what makes it work, because the exceptions get smaller once people know the date is real.
- List what needs patching. Write down every category: operating system, browsers, runtimes, office suite, VPN and security agents, meeting apps and firmware. Then mark who can update each one, meaning the OS updater, the vendor's own auto updater, or your management tool.
- Assign every laptop to a ring. Create pilot, broad and late rings in the management tool itself, not in a spreadsheet. Every enrolled device should land in one automatically by group or tag, so a new hire is covered on day one.
- Set a deadline with a grace period. Pick the day patches are approved and the day they must be installed, then set a forced restart with a two hour warning. Give users a short deferral window, not an unlimited one.
- Turn on third party patching. Use the catalog in your management tool or a package manager to cover browsers, readers and runtimes. Remove apps nobody uses, because every app you delete is one less thing to patch.
- Handle firmware as its own track. Stage BIOS and dock firmware behind the OS cycle, require the laptop to be plugged in, and confirm the recovery key is reachable before the first device updates. Test on one model before the rest.
- Cover laptops that are rarely online. Set a maximum deferral so updates apply on any network, and use a maintenance window when devices are likely to be plugged in and awake. Flag any device not seen in 14 days and contact the owner.
- Run an exception process. Use a short form with a reason, an end date and a compensating control such as keeping the device off the file server. Review open exceptions monthly and close the ones that have expired.
- Report and chase weekly. Send a weekly list of devices behind on patches to the owner of each device. Direct contact from a manager moves devices faster than another automated email from the tool.
How to check it worked
Do not trust the compliant badge on its own. Pull the actual build number from the endpoint and compare it to your target. On Windows that means the full build string, not just the word updated. For browsers, read the version number from the about page or from the tool, then check it against the vendor's current release.
Look hardest at the devices that are not reporting. Silence is the failure mode here. A laptop that stopped checking in three weeks ago still shows green on a percentage chart and is wide open in reality. Set an alert for any device with no scan in 14 days and treat it as a ticket, not a curiosity.
Test the restart path on a real machine each cycle. Does the warning appear, does the user get a chance to save work, does the laptop come back up and finish installing? Do this on one pilot device and one late ring device.
Once a month, read the exception list and the breakage list together. If a patch broke an app, the pilot ring did its job and you need to know which ring caught it. If the exception list keeps growing, the deadline is not being enforced.
Mistakes to avoid
Patching only the operating system is the most common one. Attackers go after browsers, PDF readers and runtimes because those update on a different track and are often months behind. If your report only covers Windows or macOS, you are measuring half the problem.
No deadline is the second mistake. If a user can defer forever, plenty will. Set a hard date, give a warning, keep a short grace period, then enforce the restart. The opposite mistake is just as bad: pushing to every laptop on day one, so one bad patch takes out the whole company at once instead of a pilot ring.
Forgetting the machines that are off is a quiet one. A patch that fails on a laptop in a drawer for six weeks looks identical to success if you only read the first report. So is pushing firmware without a recovery key in hand, and treating firmware as optional until a dock or a drive stops working.
Treating the dashboard as the truth is another. So is running with no exception process, because people who cannot get an extension will disable the agent or find a workaround you cannot see. If you are not sure what is actually in the fleet, the Cloudverg Hardware and endpoint review is a fixed price $4,500 over two weeks and ends with a written inventory of endpoints and their support status, which is one option among others and a different job from running the monthly patch cycle.
Frequently asked questions
How often should company laptops be patched?
Run a monthly cycle for operating system and firmware, timed around the vendor release day. Browsers and other apps with auto update should update continuously, and critical out of band fixes should go out within a few days of release. The exact dates matter less than the fact that they never move.
What is a patch ring?
A patch ring is a group of devices that receives an update at a different time from the rest. A small pilot ring goes first so a bad patch shows up on ten laptops rather than two hundred. Broad and late rings follow, which also gives you a way to hold back one team that depends on a fragile app.
Do you need MDM to keep laptops patched?
No, but you need something that can report versions and force a restart. Group Policy covers a lot on Windows machines that join the domain. Macs, remote workers and third party apps usually need a management tool or a patch agent to get the same result.