Author: George Klein 

What Happens When You Can’t Patch Everything? 

In the previous post in our Breaking Down Security Silos series, we explored the relationship between vulnerability management and patch management. Vulnerability management identifies and prioritizes weaknesses; patch management provides one of the primary mechanisms for eliminating them. 

But even the most disciplined patching program leaves some level of exposure. 

A newly disclosed vulnerability may not have a patch yet. A legacy application may depend on an outdated operating system. A critical server may have to wait for a maintenance window. A deployment may fail without anyone realizing it. 

This is where Endpoint Detection and Response (EDR) becomes critical. 

Patch management reduces the opportunities available to an attacker. EDR helps organizations detect and respond when an attacker attempts to use the opportunities that remain. 

When the two operate together, organizations gain something neither can provide independently: prevention informed by detection and detection informed by exposure. 

 

Patch Management Reduces the Attack Surface 

Patch management is fundamentally preventative. 

Every successfully remediated vulnerability represents one less known weakness an attacker can potentially exploit. 

A mature patch management process helps organizations: 

• Deploy security updates consistently 

• Prioritize patches based on risk 

• Reduce exposure to known vulnerabilities 

• Track failed or incomplete deployments 

• Maintain supported software versions 

But patch management has an unavoidable limitation: it primarily addresses weaknesses for which a fix exists and can safely be deployed. 

Real environments are rarely that straightforward. 

 

Why Patching Alone Isn’t Enough 

There will always be a gap between vulnerability disclosure and complete remediation. 

Sometimes that gap lasts hours. Sometimes it lasts months—or significantly longer. 

Common reasons include: 

• No vendor patch is available 

• Business-critical applications require compatibility testing 

• Legacy systems cannot support current software 

• Operational requirements limit downtime 

• Devices are offline during deployment 

• Updates fail or require additional remediation 

• A vulnerability is unknown or newly discovered 

The presence of these gaps does not necessarily indicate that a patch management program is failing. 

It means organizations need another layer of defense. 

EDR helps provide that layer. 

 

EDR Provides Visibility Into What Happens Next 

Traditional endpoint security primarily focuses on preventing known malicious activity. Modern EDR goes further by continuously collecting and analyzing endpoint activity to identify behaviors that may indicate compromise. 

Depending on the platform and deployment, this can include visibility into: 

• Suspicious process execution 

• Malicious scripts 

• Credential access attempts 

• Persistence techniques 

• Privilege escalation 

• Lateral movement 

• Unusual endpoint behavior 

This becomes especially valuable when an endpoint contains a vulnerability that cannot immediately be remediated. 

If patch management tells us where known exposure remains, EDR can help answer: 

Is anyone attempting to take advantage of it? 

 

Exposure Should Inform Detection 

This is where breaking down the silo becomes important. 

Consider an internet-facing server with a known vulnerability that cannot be immediately patched because of an application dependency. 

The patching team knows the vulnerability exists. 

The security team knows the system is exposed. 

The EDR platform is monitoring the endpoint. 

But if those pieces of information remain isolated, the organization misses an opportunity. 

Knowing that a specific vulnerability exists should influence how the system is monitored. 

Security teams may increase monitoring, investigate related behaviors more aggressively, or implement additional compensating controls until remediation is possible. 

Instead of treating the unpatched asset as another endpoint, the organization treats it according to its actual risk. 

 

Detection Should Inform Patching, Too 

The communication should work in both directions. 

Imagine EDR begins detecting suspicious behavior associated with exploitation of a known vulnerability. 

That information should immediately affect remediation priority. 

A vulnerability that was scheduled for the next maintenance window may now require emergency remediation. 

This creates another important security feedback loop: 

Identify Exposure → Prioritize → Monitor → Detect → Reprioritize → Remediate 

Threat activity changes risk. 

A static patching schedule cannot always account for that. Connected security operations can. 

 

The Zero-Day Problem 

The relationship between EDR and patch management becomes particularly important during a zero-day vulnerability. 

When a vulnerability is disclosed before a patch is available, organizations cannot immediately remediate the underlying weakness. 

Security teams instead have to reduce the likelihood or impact of exploitation. 

Depending on the vulnerability, that may involve: 

• Disabling affected services or functionality 

• Restricting network access 

• Applying vendor-recommended mitigations 

• Segmenting affected systems 

• Increasing endpoint monitoring 

• Hunting for indicators of compromise 

EDR can provide critical visibility during this period by helping teams identify suspicious behaviors associated with exploitation. 

Once a patch becomes available, patch management can address the underlying weakness. 

The controls complement each other: EDR helps manage exposure while patching works toward permanent remediation. 

 

Legacy Systems Make the Connection Even More Important 

Almost every established IT environment has systems that are difficult to patch. 

They may support specialized applications, manufacturing equipment, operational technology, or software that cannot easily be migrated. 

Simply labeling those systems “unpatchable” does not make the risk disappear. 

When immediate remediation isn’t possible, organizations need to understand the exposure and implement compensating controls around it. 

EDR can be one of those controls when the underlying system supports it. 

Other protections may include segmentation, application allowlisting, restricted access, enhanced logging, or additional network monitoring. 

The important point is that exceptions should create additional security decisions—not security blind spots. 

 

EDR Is Not a Substitute for Patching 

There is an important distinction here. 

Deploying EDR does not make patching optional. 

EDR may detect or prevent malicious behavior associated with exploitation, but leaving a known vulnerability open unnecessarily increases the number of opportunities available to an attacker. 

Likewise, a strong patching program does not eliminate the need for endpoint detection. 

Organizations need both prevention and detection because neither control is perfect. 

The objective is layered defense. 

Patch what you can. 

Understand what you cannot. 

Monitor the exposure that remains. 

And remediate it as soon as operationally possible. 

 

Measure Exposure, Not Just Patch Compliance 

A 98% patch compliance rate sounds excellent. 

But what is contained in the remaining 2%? 

If those systems include internet-facing servers with actively exploited vulnerabilities, the organization’s risk may look very different from the headline metric. 

This is why IT and security leaders should look beyond patch compliance alone. 

Useful questions include: 

• Which critical vulnerabilities remain unpatched? 

• Why have they not been remediated? 

• Are any being actively exploited? 

• What assets are affected? 

• What compensating controls are in place? 

• Is EDR deployed and healthy on those endpoints? 

• How quickly can the organization respond if suspicious behavior appears? 

The goal is not a perfect percentage on a dashboard. 

The goal is understanding and reducing the organization’s actual exposure. 

Looking Ahead 

Throughout this series, we’ve followed the flow of security information from identifying weaknesses to validating, prioritizing, remediating, and monitoring them. 

But not every attack begins with a software vulnerability. 

Sometimes the initial point of compromise is a person. 

In the final post of the Breaking Down Security Silos series, we’ll explore how phishing simulations and security awareness training can connect with technical security operations, turning human risk data into another valuable security signal—and helping organizations build a more complete picture of risk across both people and technology.