By Ben Whitmore, Systems Architect, Patch My PC
I’ve worked in IT for over 20 years, and if there’s one thing I’ve learned, it’s that keeping up has always been part of the job. Just when you think you’ve mastered a technology, something changes. A new platform arrives, a familiar product gets renamed, or a perfectly good way of doing something is replaced by three new ways of doing exactly the same thing.
For many of us, that’s part of the appeal. We enjoy learning, solving problems, and occasionally pretending we understood the release notes on the first read. But the pace of change feels faster, the breadth of knowledge we’re expected to maintain keeps expanding, and nobody seems to have added any extra hours to the working day.
Patch management is a good example. We’ve spent years improving how we deploy software updates, with automated packaging, deployment rings, maintenance windows, and dashboards telling us how many devices are compliant. We’ve become pretty good at keeping software up to date, but compliance percentages don’t always tell us whether we’re addressing the vulnerabilities that matter most.
My prediction for 2027 is that vulnerability intelligence will increasingly influence not just which updates we prioritise, but how quickly they’re deployed.
We’re already good at automating software deployment. The next opportunity is connecting that automation with what we know about the vulnerabilities affecting our environments, so that urgent risks don’t simply wait their turn in the normal patching schedule.
When an Update Becomes Urgent
One morning, a security advisory lands. A vulnerability has been found in Money Tree Grower 3.0, and the publisher has released version 3.1 to fix it.
Sadly, despite the promising name, Money Tree Grower doesn’t actually grow money. Finance would have approved the purchase much faster if it did. It is, however, installed on 2,000 of your endpoints.
Your patching process is well established. Updates move through carefully managed deployment rings. A small group receives each update first, you watch installation success and application behaviour, and the rollout expands once you’re confident nothing is breaking. Version 3.1 joins the queue, sits in the first ring for seven days, then moves on.
For routine updates, that’s a perfectly sensible approach. But imagine learning that attackers are already exploiting the vulnerability in Money Tree Grower 3.0. Suddenly, leaving the update in its first deployment ring for seven days doesn’t seem quite so reassuring.
There’s nothing inherently wrong with the deployment process. It’s doing exactly what we designed it to do. The problem is that the schedule doesn’t necessarily reflect the urgency of the vulnerability.
Identifying the Vulnerabilities That Affect Us
Of course, Money Tree Grower is just one fictional application. Most organisations are managing hundreds of applications, thousands of endpoints, and more security advisories than anyone could reasonably investigate. Nobody has time to research every CVE individually, work out which versions are affected, and manually compare that information against their entire environment. Nor should we expect them to.
There’s already plenty of useful vulnerability information available. CISA maintains a catalogue of vulnerabilities known to have been exploited, while FIRST’s EPSS estimates the likelihood of exploitation over the next 30 days. Alongside severity ratings, these provide useful signals, but understanding the risk to our own organisation also means knowing which applications are installed, which devices are affected, how exposed they are, and what the business impact could be.
Much of that information already exists. The difficulty is bringing it together in a way that helps the people responsible for deploying updates, without creating another mountain of work.
Imagine your systems identifying that Money Tree Grower 3.0 is installed on 2,000 devices, that attackers are exploiting a vulnerability in that version, and that an update is available. That’s useful information, and potentially a good reason to change the deployment priority. Of course, it relies on having an accurate software inventory and correctly identifying which versions are affected. Otherwise, we risk making decisions based on incomplete information.
We’ve become increasingly good at automating software updates, but knowing an application is vulnerable doesn’t necessarily change how quickly its update moves through our existing deployment process. I think that’s where we’ll see real progress in 2027.
Adjusting the Deployment Schedule
Phased deployment is one of the most useful safeguards we have in enterprise patch management. The initial deployment ring gives us an opportunity to observe installation success and potential problems before expanding the rollout. For routine updates, allowing that process to run over several days and weeks makes sense.
But when there’s credible evidence that attackers are exploiting a vulnerability affecting our environment, we need the flexibility to respond differently.
Imagine sitting on the toilet at your in-laws’ house, scrolling through your phone, and suddenly realising you’ve left the bathroom door wide open. You don’t know whether anyone has noticed, but you’re certainly not going to wait until next Tuesday to do something about it.
That’s the kind of urgency we sometimes need in vulnerability remediation. Not every vulnerability warrants an emergency response, but some deserve more attention than their place in the normal deployment schedule would suggest.
For Money Tree Grower, we might shorten the observation period in the first deployment ring, monitor installation success and application behaviour closely, and expand the rollout sooner than usual. For particularly urgent vulnerabilities, we might supplement that process with focused checks on representative devices before deploying directly to affected endpoints.
There will also be situations where accelerating the deployment isn’t the safest option. Some applications need additional validation, and a shorter observation period may not reveal problems that only appear after several days of use. In those cases, temporary mitigations, such as disabling vulnerable functionality or restricting access, may help reduce exposure while the update is validated.
We’re balancing two risks: the possibility of disrupting business operations and the consequences of leaving vulnerable software exposed. The right decision will depend on the application, the vulnerability, the affected devices, and the potential impact of either outcome.
This is much easier when organisations have already agreed on how an accelerated deployment should work. Who can approve it? Can deployment schedules be changed quickly? Do we have the monitoring and recovery options needed if something goes wrong? Those are things worth sorting out before an urgent security advisory arrives.
None of this is a particularly new concept. NIST’s enterprise patch management guidance has long emphasised prioritisation, risk reduction, and verification. What I expect to change is how closely those principles become connected to the everyday process of deploying software updates.
Verifying the Vulnerability Is Fixed
Let’s say Money Tree Grower 3.1 has now been deployed across the organisation. The deployment dashboard looks healthy, most devices report success, and there are no obvious signs of trouble.
It’s tempting to consider the job finished, but some devices may have been offline, others may have failed to update, and in certain cases an older vulnerable version could remain installed alongside the new one. A successful deployment doesn’t necessarily mean the vulnerability has been remediated.
This is another area where I expect our approach to mature. Compliance percentages are useful, but they don’t tell us how long important vulnerabilities remained exposed or whether we’ve successfully addressed them.
An organisation reporting 95% compliance might still have hundreds of devices exposed to a known exploited vulnerability. Another reporting 90% might have already remediated its most significant exposures. Both figures tell us something, but neither provides the complete picture on its own.
I’d also want to understand where time is being lost. If it takes three weeks to remediate an important vulnerability, was the delay identifying affected devices, preparing the update, waiting for approval, or dealing with deployment failures? Knowing that gives us something practical to improve.
Ultimately, reducing the time that important vulnerabilities remain exposed is a more meaningful measure of security progress than simply deploying an increasing number of updates.
Looking Ahead to 2027
I don’t expect scheduled patching to disappear in 2027. We’ve spent years making those processes reliable, and for routine updates they work well. What I do expect is a closer connection between vulnerability intelligence and software deployment, allowing organisations to recognise when an update needs to move faster without relying on engineers to piece everything together manually. So here’s something worth considering: if a significant vulnerability affected your environment tomorrow, how quickly could you identify the affected devices, accelerate deployment, and confirm that the vulnerability had been remediated? If that involves several teams, multiple tools, and a fair amount of manual investigation, there’s probably an opportunity to improve. We’ve spent years getting better at deploying updates. Now we need to get better at knowing which ones can’t wait.
##
ABOUT THE AUTHOR
IT Veteran and Microsoft MVP, Ben Whitmore is Systems Architect at Patch MY PC where he spends his days helping organizations drive adoption and technology change within their Enterprise.
