A patch fixes the flaw itself by changing the vulnerable software. A mitigation leaves the flaw in place but makes it harder to exploit or less damaging, for example by blocking a path to it. Both are legitimate responses, but they are not the same status, and you should not describe them as equal.
The door analogy
A patch replaces the broken lock. A mitigation puts a guard in front of the broken door. The guard helps, and the lock is still broken. If the guard leaves, the risk returns.
Why the distinction matters
Teams outside security often hear "mitigated" and read it as "fixed." That error turns into customer statements like "the issue is resolved" when the underlying flaw is still present. Keeping the words distinct protects both the company and the customer.
| Patch | Mitigation | |
|---|---|---|
| Flaw still present | No | Yes |
| Typical form | Software update | Configuration change, filter, disabling a feature, extra monitoring |
| Reversible by accident | Rarely | Easily, if a setting is changed back |
| Customer message | A fixed version is available | A step to take now, and a fix is planned |
| Needs follow-up | Verify deployment | Schedule the real fix |
How it maps to VEX statuses
The OpenVEX specification defines fixed as product versions that contain a fix, and requires that an affected statement include an action statement describing how to remediate or mitigate. So "affected, with a mitigation" and "fixed" are different statuses and should read differently to customers.
What each team should say
- Support: "A fix is available in version X" or "A mitigation is available now and a fix is planned." Never "resolved" for a mitigation.
- Sales: Same wording, plus a pointer to the written statement.
- Executives: "Exposure is reduced, not removed. The real fix lands on [date]."
- Legal and comms: Do not describe a mitigated product as fixed in any public text.
Choosing between them
A mitigation is the right first move when a patch is not yet available, cannot be deployed safely right now, or needs testing. Choose a patch when it exists and is safe to deploy. Always give a mitigation an owner and an end date, so it does not become a permanent workaround.
Checking that a mitigation works
Test it. If the mitigation is a filter rule, try the blocked request in a safe environment. If it is a disabled feature, confirm it is disabled in every deployment. Record the evidence.
Retiring a mitigation
Once the patch is deployed, remove the temporary controls or document why they stay, and update the status from affected to fixed with the fixed versions listed.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see a fix applied and the status change. Notice the difference between available and deployed.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests, off by default with every category on Manual, plus policies and gates to track deadlines. The free scan is at gold.safeguard.sh/scan.
Quick check
Is a mitigated vulnerability fixed?
No. The flaw is still present and the exposure is reduced. Call it mitigated, not fixed.
How long can a mitigation stay in place?
Set an end date when you apply it and review at that date.
Sources
Last reviewed: 19 October 2026.
