Use fixed for a release that contained the problem and now carries the fix. Use not affected when the product never had the vulnerable code in a reachable form, with a justification. Older releases that still ship the vulnerable component remain affected, with an action statement telling customers to upgrade.
The definitions
CISA's minimum requirements define the statuses. Not affected means no remediation or mitigation is required and the vulnerability does not affect the listed products. Affected means actions are recommended by the author. Fixed means the listed products contain fixes for the vulnerability. Under investigation means no final status has been declared yet.
Worked example
Suppose a library flaw was disclosed. Your product shipped three releases.
| Release | Situation | Status | Required extra |
|---|---|---|---|
| 1.0 | Included the vulnerable version, code reachable | affected | Action statement: upgrade to 1.2 |
| 1.1 | Included the vulnerable version, code reachable | affected | Action statement: upgrade to 1.2 |
| 1.2 | Upgraded the library to a patched version | fixed | None |
| 0.9 (older) | Never used the vulnerable function, feature compiled out | not_affected | Justification, for example vulnerable code not present |
CISA says an affected statement must include an action statement, and a not-affected statement needs a justification or an impact statement.
Steps to follow
- Write the vulnerability identifier and list every product version you ship.
- For each version, decide whether the vulnerable component is present, and whether the vulnerable code can run.
- Group versions that share the same answer.
- Write one statement per group. CISA says if the status changes for a subset of products, additional statements must be created for that subset.
- Raise the document version and update the timestamps when you publish, because CISA requires the document version to increase whenever anything inside changes.
Common mistakes
- Marking the upgraded version not affected. It was affected before the upgrade, so fixed is the honest status.
- Marking old versions fixed. They have not changed.
- Leaving an affected statement without an action. Customers cannot act on it.
- Forgetting that fixed is about the listed products. Name them exactly, ideally with the identifiers in your SBOM.
For how statuses move over time, see the statement lifecycle from under investigation to final.
Try it yourself
Open the demo and look at how a fix version is shown next to a vulnerable one. That is the information your fixed and affected statements carry.
Click through it at your own pace, or open it full screen.
Quick check
Can one statement cover fixed and affected releases?
No. A statement carries a single status. Use separate statements for different statuses.
Is fixed the same as not affected?
No. Fixed says the product was affected and now contains the fix. Not affected says it never needed remediation.
Safeguard can open fix pull requests for you, off by default with every category on Manual, and the free scan shows available fixes.
Sources
Last reviewed: 19 October 2026.
