When a vendor will not fix a known vulnerability, you have six options: apply a workaround, isolate the system, replace the product, patch it yourself if you can, accept the risk for a stated period, or escalate through a coordinator. Pick one deliberately and write it down with an end date.
First, confirm the situation
Make sure the vendor really will not fix it. Ask in writing whether a fix is planned, when, and whether the product is end of life. NIST SP 800-40 Rev 4 lists vendors not providing patches, for example because an asset is at end of life, as a main reason an asset becomes unpatchable.
Also check whether the issue is exploitable in your setup. A flaw in a feature you have disabled, or in code you never call, changes the urgency. See what is reachability analysis.
The options
- Workaround. Use any vendor documented configuration change that removes the exposure. Test it.
- Isolation. NIST names isolation and micro-segmentation as long-term mitigation methods for unpatchable assets. Limit who and what can reach the system.
- Replace. Move to a supported product. Plan the cost, since NIST suggests a cost-benefit review of whether such assets are worth the added cost of mitigating.
- Patch it yourself. For open source, fork and apply a fix. See fork and patch vulnerable packages. For closed software this is rarely possible.
- Accept the risk. Record who accepted, why, the compensating controls and an expiry date. See the exception register.
- Escalate. Ask a coordinator to engage the vendor, or push through your contract and account contacts.
Escalating through a coordinator
CISA's coordination process includes contacting the supplier, technical analysis and vendor confirmation, timeline tracking and mediation between reporter and vendor. It says it may disclose as early as 45 days after the first contact attempt when a vendor is unresponsive or will not set a reasonable remediation timeframe. That is a lever for the public record, though it applies to reports CISA accepts and coordinates. See what happens after you report to CISA.
Use your commercial weight
If you are a paying customer, put the issue in writing to your account team and ask for a response from product security. Contract language about security obligations, if any, may apply. Ask your legal team before relying on it.
Decide with evidence
Write a short decision record: the vulnerability, the exposure in your environment, the options considered and the one chosen. Review it on a schedule, since NIST asks that alternatives to patching be reevaluated periodically through risk assessment and cost-benefit analysis.
Tell your own customers when it matters
If the flaw affects data you hold for others, your own obligations may include notice. That is a legal question beyond this guide.
Safeguard's SBOM and dependency scanning identifies where a vulnerable component sits in your own software, and its policies can block new use of a component that has an unresolved critical flaw.
Quick check
Can we just stop using the vulnerable feature?
Often yes, and that is a valid workaround if you verify it is really disabled and nothing else exposes the flaw.
Is accepting the risk a failure of security?
No, if it is a documented decision by someone with authority, with controls and an end date.
Sources
Last reviewed: 19 October 2026.
