How to Handle Vulnerabilities You Cannot Patch

Why Can Some Vulnerabilities Not Be Patched?

The ideal remediation for any vulnerability is applying a vendor-supplied patch that fixes the underlying flaw. In practice, a meaningful percentage of vulnerabilities in any enterprise environment cannot be patched through the standard process. Understanding why patches cannot be applied helps organizations plan appropriate alternative responses rather than letting unpatchable vulnerabilities accumulate unmanaged.

Legacy systems running end-of-life (EOL) operating systems and applications are the most common source of unpatchable vulnerabilities. When a vendor stops supporting a product, security patches are no longer released, and vulnerabilities discovered after the EOL date have no vendor fix. Windows Server 2012, CentOS 6, and similar platforms that have reached end of support continue to run in many enterprises because the applications they host have not been migrated to supported platforms. Each new CVE affecting these platforms is unpatchable by default.

Vendor dependencies create another category. Custom or commercial applications may be certified only on specific versions of operating systems, databases, or middleware. Updating the underlying component to patch a vulnerability may void the application vendor's support, break functionality, or require expensive recertification. The vulnerability exists in the underlying component, but patching it is not feasible without the application vendor's involvement.

Operational technology (OT) and industrial control system (ICS) environments face unique patching constraints. Equipment running embedded software may not support updates at all, or updates may require physical access, system downtime, and regulatory approval that takes months to arrange. The operational impact of patching, potential for introducing instability in systems controlling physical processes, adds a safety dimension that does not apply to standard IT systems.

Structured Approaches for Unpatchable Vulnerabilities

Risk Assessment

Every unpatchable vulnerability should undergo a risk assessment that evaluates the vulnerability's severity and exploitability in the context of the specific environment. A critical vulnerability on a legacy server that is network-isolated, accessible to three administrators, and does not handle sensitive data poses different risk than the same vulnerability on a legacy server connected to the internet and processing customer transactions. The risk assessment informs the level of compensating controls required and the urgency of replacement planning.

Compensating Controls

Network isolation is the primary compensating control for unpatchable systems. Placing the system on a dedicated network segment with restrictive firewall rules limits access to authorized users and blocks exploitation from the broader network. Enhanced monitoring through IDS/IPS, EDR (where supported), and increased logging provides detection capability for exploitation attempts. Access hardening through least-privilege enforcement, MFA, and credential rotation reduces the attack surface even when the vulnerability cannot be removed.

Formal Risk Acceptance

Unpatchable vulnerabilities require formal risk acceptance from an appropriate authority. This is a business decision, not a security team decision. The business owner of the system and an executive sponsor must acknowledge the risk, approve the compensating controls, and accept accountability for the residual risk. The risk acceptance should be documented with the vulnerability details, compensating controls, the risk assessment, and the approver's signature or electronic approval. Risk acceptance should have an expiration date that triggers re-evaluation.

Replacement Planning

Every unpatchable system should have a replacement plan. Accepting the risk of unpatchable vulnerabilities indefinitely is not a sustainable strategy. The threat landscape evolves, compensating controls degrade, and the risk accumulates over time. The replacement plan should identify the target platform or solution, the migration timeline, the resource requirements, and the dependencies that must be resolved before migration can occur. Tracking replacement plan progress alongside vulnerability metrics ensures that unpatchable systems are not forgotten in technology roadmaps.

Managing the Unpatchable Portfolio

Most enterprises have a portfolio of unpatchable systems that must be managed collectively, not just individually. Tracking all unpatchable systems in a dedicated register that includes the system, the vulnerability count, the compensating controls in place, the risk acceptance status, and the replacement timeline provides program-level visibility. Regular reporting to leadership on the unpatchable portfolio size, risk exposure, and replacement progress ensures that the organizational investment needed to retire these systems receives appropriate attention.

The unpatchable portfolio should be a factor in technology investment decisions. When evaluating new software or platforms, the total cost of ownership should include the cost of managing unpatchable vulnerabilities after the product reaches end of life. Platforms with long support lifecycles, active security response teams, and clear EOL policies reduce the future unpatchable burden. Choosing supported, actively maintained technology is the most effective long-term strategy for minimizing the population of unpatchable vulnerabilities in the environment.

Prioritizing Unpatchable Vulnerability Response

Not all unpatchable vulnerabilities pose equal risk, and the response should be proportional. A critical vulnerability with active exploitation on a legacy internet-facing server demands immediate compensating controls and accelerated replacement planning. A low-severity vulnerability on a legacy system that is network-isolated and accessed by two administrators warrants documentation and monitoring but not emergency action. The same risk-based prioritization principles that apply to patchable vulnerabilities apply to unpatchable ones: severity, exploitability, asset criticality, and network exposure determine the urgency and depth of response.

Organizations should maintain a dedicated register of unpatchable vulnerabilities separate from the standard remediation queue. This register tracks each unpatchable finding alongside its compensating controls, risk acceptance status, and replacement timeline. Reviewing the register quarterly ensures that compensating controls remain effective, replacement plans are progressing, and the cumulative risk from the unpatchable portfolio is understood and reported to leadership.

Long-Term Strategies for Reducing Unpatchable Exposure

The most effective long-term strategy for reducing unpatchable vulnerability exposure is technology lifecycle management. Organizations that proactively plan system replacements before end-of-life dates, maintain upgrade paths for custom applications, and select technology with long vendor support windows minimize the future accumulation of unsupported, unpatchable systems. Including security support lifecycle as a selection criterion during technology procurement prevents the purchase of systems that will become unpatchable prematurely.

Application modernization programs that migrate legacy workloads to supported platforms reduce the unpatchable portfolio over time. These programs are expensive and complex, but the alternative, maintaining an ever-growing population of unsupported systems with compensating controls of decreasing effectiveness, is also expensive and significantly riskier. Framing modernization investment in terms of reduced security risk and reduced compensating control overhead provides a cost-benefit narrative that helps justify the expenditure.

Vendor engagement is important for unpatchable vulnerabilities caused by vendor dependencies rather than end-of-life. If a vendor's product requires a specific, now-vulnerable version of an underlying component, engaging the vendor for a compatibility update or certified workaround may resolve the unpatchable status. Tracking vendor responsiveness to these requests informs future vendor selection decisions: vendors that leave customers exposed to unpatchable vulnerabilities due to slow compatibility updates represent increased supply chain risk.

For operational technology and industrial control systems, industry-specific guidance from organizations like ICS-CERT (now CISA), NIST (SP 800-82), and sector-specific ISACs provides frameworks for managing vulnerabilities in environments where traditional patching is constrained by safety, availability, and regulatory requirements. These frameworks emphasize defense-in-depth strategies that combine network segmentation, access control, monitoring, and physical security to reduce risk when software patching is not feasible.

Communicating Unpatchable Risk to Leadership

Unpatchable vulnerabilities represent an area where security teams must communicate risk clearly to business leadership. The communication should frame the issue in business terms: what systems are affected, what the potential business impact would be if the vulnerability is exploited, what compensating controls are in place, what the replacement timeline is, and what resources are needed to execute the replacement plan. Technical vulnerability details matter less to leadership than the business risk and the path to resolution.

Aggregate reporting on the unpatchable portfolio provides strategic visibility. The total count of unpatchable systems, their distribution across business units, their collective risk exposure, and the trend over time (growing, stable, or shrinking) tell leadership whether the problem is improving or worsening. A growing unpatchable portfolio signals that technology lifecycle management is not keeping pace with end-of-life transitions. A shrinking portfolio signals that replacement investments are producing results.

Connecting unpatchable vulnerability risk to budget requests makes the business case for modernization investment concrete. "We have 47 systems running unsupported software with 312 unpatched vulnerabilities, maintained through compensating controls at an annual cost of $X in security monitoring and operational overhead. Replacing these systems would eliminate the unpatchable exposure and the ongoing compensating control cost." This framing connects the technical debt to financial impact and provides a cost-benefit basis for the replacement investment.

Insurance and third-party risk assessments increasingly examine unpatchable system exposure. Cyber insurance underwriters may ask about end-of-life system prevalence and compensating control adequacy. Customer security assessments may flag unpatchable systems as risk factors. Maintaining accurate, current documentation of the unpatchable portfolio, compensating controls, and replacement plans satisfies these external inquiries and demonstrates responsible risk management even when patching is not feasible.

Organizations should also consider the cumulative risk of their unpatchable portfolio. Individual risk assessments for each unpatchable vulnerability may conclude that compensating controls adequately mitigate each one. But collectively, a large portfolio of unpatchable systems represents a brittle defensive posture: if any single compensating control fails, the corresponding vulnerability becomes immediately exploitable. Stress-testing the compensating control portfolio through breach and attack simulation or red team exercises reveals how resilient the overall defensive posture is when multiple controls are tested simultaneously rather than individually.

Risk quantification for unpatchable systems helps leadership understand the financial exposure associated with maintaining unsupported infrastructure. Models that estimate the annualized cost of a potential breach resulting from an unpatchable vulnerability, factoring in incident response costs, regulatory penalties, customer notification expenses, and reputational damage, provide the business case for replacement investment in terms that financial decision-makers understand. When the annualized expected loss from maintaining an unpatchable system exceeds the cost of replacement, the business case for modernization is clear.