Wouldn’t it be great if every vulnerability had a fix waiting in the wings? If patching were always fast, easy, and complete? 

That’s not the world we live in. 

Some vulnerabilities can’t be patched at all. Others are buried in systems or services you don’t fully control. And the longer your focus stays limited to internal infrastructure, the more risk slips through the cracks. 

This is where the conversation broadens, from vulnerability management to full spectrum exposure management. Because unpatchable vulnerabilities aren’t edge cases. They're part of your everyday risk landscape and deserve a seat at every CISO’s table. 

The problem? Too many organizations still equate vulnerability management with patching, and that mindset creates blind spots big enough for attackers to walk right through. It ignores the exposures lurking outside traditional infrastructure: Cloud misconfigs, expired certs, third-party software dependencies, identity abuse and more. 

What are unpatchable vulnerabilities? 

Unpatchable vulnerabilities live up to their name. They’re flaws you can’t fix with a vendor patch, and not as rare as you might think. In today’s environment, risk is as likely to come from a cloud misconfiguration or expired certificate as it is from a missing update. But if your strategy focuses only on infrastructure vulnerabilities, you’re leaving massive gaps in your defenses. 

Most teams lack total attack surface visibility and treat infrastructure as the entire attack surface. Full stop. But that’s only one layer in a much broader landscape. The reality is that there are five critical layers where vulnerabilities live, and only one of them can be reliably managed with traditional patching.  

The rest? They're unpatchable by nature. And each requires a different approach if you want to close the gaps. Let’s go through each one at a time: 

1. Infrastructure  

Infrastructure is the attack surface layer that everyone knows. It’s where traditional vulnerability management and patch management lives. And yes, it’s critical. But treating this as the whole (or only) attack surface is like locking your front door and ignoring the open windows. 

2. External attack surface 

The external attack surface is what an adversary sees when they look at your organization from the outside. Your domains, subdomains and exposed services are entry points you don’t always control directly and often aren’t picked up in infrastructure scans. 

3. Cloud services 

Cloud misconfigurations are one of today’s most dangerous blind spots and also among the most overlooked, particularly in environments that have rapidly adopted cloud services without simultaneously evolving their security practices. We’ve seen the headlines about data exposed through misconfigured storage buckets or overly permissive APIs. These aren’t software flaws. They’re setup mistakes, and no patch can fix a poorly set permission. 

4. Identity  

Then there’s identity. Every user account, credential and session token is a target. If a threat actor phishes your credentials or cracks a weak password, they’re not even exploiting a system vulnerability. They’re using your systems exactly as designed. Don’t mistake identity for a layer of access control. It serves as its own attack surface. 

5. Data 

And finally: data. The way you classify, store and secure data all represent a surface area always being probed by attackers. If sensitive information is in the wrong place, with the wrong permissions, that’s an open invitation. 

Patching is critical. It gives you remediation coverage on endpoints and servers. But it only addresses one piece of the puzzle. The rest of your environment requires a wider lens.  

The reality is: exposures aren’t buried in code. They live in misconfigurations, overly broad permissions, architectural shortcuts and legacy systems either forgotten or left to rot in the background. Those don’t get fixed with a patch. They get fixed with strategy. 

Examples of unpatchable vulnerabilities 

Log4j was a wake-up call. A single vulnerable library embedded across dozens of applications, many of them business-critical. You couldn’t just “push a patch”. You had to wait for each vendor to update their software, and/or manually disable vulnerable components until you closed that hole. 

That’s just one example of how complexity can derail vulnerability management. Other cases are even more problematic: 

IoT devices often operate as closed systems, with firmware controlled entirely by the vendor. If vendor support ends, you’re left with internet-connected assets that IT can’t update directly as firmware is locked behind vendor-controlled gates. Without updates, vulnerabilities remain exposed. 

Network Edge Devices (Firewalls, VPNs, etc.) come with layers of complex rules, configurations and dependencies, configurations and dependencies that can’t be blindly updated. Every change must be tested against business-critical services to avoid outages. One single misstep can knock systems offline or break key integrations. That’s why most teams treat these updates like surgical procedures: slow, meticulous and weighed carefully against the organization’s risk appetite.  

And then there’s cryptographic decay. It’s the slow decay of trust in encryption as attackers get faster and standards grow older. TLS and SSL protocols, once considered rock solid, become exploitable over time. 

And none of them can be addressed by traditional patching models. They live outside the boundaries of what scanners catch and patching can solve. That’s why a broader security strategy, one rooted in exposure reduction and not just patching, needs to guide your approach. 

Multifaceted risk mitigation strategies 

Start by targeting the weakest links in your environment: outdated protocols, misconfigurations and overexposed assets. Then, assess who and what has access to your systems. Shrink those access pathways to only what’s essential. This reduces the damage radius when something goes wrong. 

Next, break risk mitigation into multiple workstreams. Not every vulnerability can be addressed the same way or on the same timeline. You need parallel tracks for short-term containment and long-term resilience. 

In the short term, if you're facing an unpatchable vulnerability, ask: how do we minimize impact now? The Log4j response is a good model. There, we deployed scripts that disabled vulnerable components in real time, limiting exposure while waiting for a vendor patch. 

At the same time, build a longer-term framework. Automate configuration updates wherever possible. Create a roadmap for phasing out end-of-life apps and platforms. Map ownership across critical systems, including which teams or vendors control updates and what permissions or dependencies might block timely fixes. When an issue arises, that prep work determines whether you're reacting in chaos or executing a plan. 

The tactics will vary — scripts, segmentation, zero trust, re-architecture — but the goal stays the same: reduce the time and space adversaries have to exploit your systems. Shrink the window. Stay ahead of it. 

The organizations that succeed in managing unpatchable vulnerabilities are the ones who understand their environment inside and out. They never stop refining that understanding. That means having a real-time asset inventory, visibility into what’s running where and a comprehensive Software Bill of Materials (SBOM) that tells you what’s inside your software. 

They also monitor the entire attack surface. Not just endpoints, but external perimeters, cloud configurations, identity systems, and the data itself. Anything less than that leaves blind spots wide open. 

They build tight operational bridges between teams. When a high-risk exposure surfaces, network ops, application owners and developers already know who’s on point, what actions to take and how to move fast without triggering service disruptions. 

Above all, they know that “unpatchable” doesn’t mean unmanageable. It just means you need a different playbook: one that’s layered, cross-functional and laser-focused on reducing real-world risk. 

For more on how to elevate your approach to vulnerability management and risk mitigation, check out Ivanti’s research report: Risk-Based Patch Prioritization.