If a vendor will not patch a flaw, you have three options: accept the risk with compensating controls and a deadline, replace the product, or wrap it with controls that shrink the exposure. Pick by exposure and replacement cost, and record the decision with a date to revisit.
Confirm the facts first
Before choosing, check what the vendor actually said. "Will not fix" differs from "fix planned" and from "end of life." Ask in writing for the status, the planned date if any, and whether a workaround exists. Keep the reply on the record. A supplier's VEX statement or advisory may help, but see should you trust a supplier's VEX statements.
The three paths
| Path | Meaning | Good when | Risk |
|---|---|---|---|
| Accept | Keep using it as is, with controls and an end date | Low exposure, hard to replace | Risk persists, and so does the dependency |
| Wrap | Add controls around it, such as network isolation, input filtering or reduced privileges | Moderate exposure, replacement costly | Controls can fail or drift |
| Replace | Move to another product or version | High exposure, alternatives exist | Cost, time, migration risk |
Most real cases end up as a wrap now plus a replace later.
Decide with five questions
- How exposed is the affected component?
- Is the flaw exploited, or is exploit code public?
- What data or access does a compromise give?
- What would replacement cost, and how long would it take?
- Does the vendor's silence signal a wider maintenance problem?
The last one matters. A supplier that will not patch this issue may not patch the next one.
Record it as an exception
Use a standard request: the flaw, the vendor statement, the chosen path, the compensating controls with tests, the approver and the end date. Add a milestone for the replacement plan if you picked wrap, with an owner. A dated exception without a plan is just a longer delay. The structure in what to put in a security exception request works here too.
Keep the pressure on
Check the vendor monthly and note replies. If the vendor later publishes a fix, the exception should end, and the fix should be scheduled. Share your decision with the contract owner, since support terms may let you raise the issue formally.
Where Safeguard fits
Safeguard's SBOM and dependency scanning show where a vendor component sits in your software, and policies and gates can require approval for any waiver you raise.
Quick check
Is wrapping a product the same as fixing it?
No. The flaw is still there. Wrapping lowers exposure, so treat it as a compensating control that must be tested and re-tested.
Should we tell customers about a vendor flaw we accepted?
That depends on your contracts and the impact. Ask legal and security leadership, and follow any notice terms you have agreed to.
Last reviewed: 19 October 2026.
