For an asset you cannot patch, use approved long-term mitigations such as isolation, review them on a schedule, and decide on purpose whether the asset is worth its extra cost. NIST SP 800-40 Rev 4 treats unpatchable assets as one of four patching scenarios that need a written plan.
Why assets end up unpatchable
NIST gives two examples. The vendor does not provide patches, for instance because the asset is at end of life or does not support updates. Or the asset needs to run uninterrupted for a long period because it provides mission critical functions.
NIST adds that routine patching is typically not able to accommodate these systems within a reasonable time frame, so a different approach is needed.
Approve a menu of mitigations
NIST says there should be an approved set of long-term mitigation methods for each maintenance group, reviewed in advance by security architects or engineers to judge how well they reduce risk. It points to micro-segmentation and software-defined perimeters as examples of isolation methods, referencing NIST SP 800-207.
In practice the menu often includes:
- Network segmentation so the asset only talks to what it must.
- Removing internet exposure and administrative access from general networks.
- Turning off unused services and ports.
- Extra monitoring on traffic to and from the asset.
- Virtual patching at a gateway where the vulnerability is understood.
Pick from the approved menu per group, not ad hoc per ticket.
Cover specific vulnerabilities too
NIST says that in addition to the long-term methods, organizations should apply mitigations as needed for specific vulnerabilities the long-term methods do not adequately address. For example, segmentation does not help if the vulnerable service must be reachable from the same segment by many hosts.
Reevaluate on a schedule
NIST asks you to periodically reevaluate alternatives to patching in two ways:
- A risk assessment to see whether the alternatives are still effective.
- A cost-benefit analysis to see whether the assets provide enough value compared with the added cost of mitigating, transferring or accepting the risk.
The second one gets skipped. Sometimes the right answer is to replace or retire the system. Put a review date on the register entry. See the patch exception register.
Plan for new vulnerabilities
NIST notes that a new vulnerability in an unpatchable asset might change the mitigation you need. If a new flaw affects the service you exposed on purpose, the old plan may no longer hold. Keep a way to find affected assets quickly, which depends on a current inventory.
The software version of this problem
The same thing happens to code. An old library with no upstream fixes is an unpatchable asset. Options include replacing it, forking and patching it yourself, or isolating the code that uses it. See managing end of life dependencies.
Safeguard's reachability analysis shows whether a vulnerable function is called, and its policies can set how old a component may be before a build is flagged.
Quick check
Can we just accept the risk and move on?
Yes, if someone with authority signs it, there are compensating controls, and the decision has an end date. NIST lists accepting risk as one of the options in the cost-benefit review.
Is segmentation always enough?
No. It limits spread, not direct attack on the asset from permitted sources. Apply specific mitigations where needed.
Sources
Last reviewed: 19 October 2026.
