When you cannot rebuild or patch a system, first confirm whether it is actually affected, then cut its exposure, record a time limited exception with an owner, and plan its replacement. Leaving it unrecorded is the worst option, because it becomes invisible risk.
Step 1: Confirm you are affected
Many findings are not exploitable in a given deployment. The OpenVEX specification names the statuses a statement can take: not_affected, affected, fixed and under_investigation. For not_affected, it lists justifications such as component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. Use that vocabulary, because a plain "false positive" tells the next reader nothing.
Only claim not_affected with evidence, such as a build file or a reachability result.
Step 2: Reduce exposure
If you are affected, make the system harder to reach and less useful to an attacker.
- Remove internet reachability or put an access layer in front.
- Limit inbound connections to the few callers that need them.
- Remove stored credentials that grant wider access than the system needs.
- Increase logging around the vulnerable function so abuse is noticed.
- Disable the vulnerable feature if configuration allows it.
Step 3: Record an exception
| Field | Content |
|---|---|
| Finding | Component, version, advisory |
| Reason it cannot be fixed | Vendor end of life, dependency lock, downtime cost |
| Compensating controls | The list from step 2 |
| Owner | A team and contact route |
| Review date | A real date, not "later" |
| Exit plan | What replaces it and when |
An exception without a review date silently becomes permanent.
Step 4: Plan retirement
Add the system to a retirement list with an owner and a target quarter. Check whether its operating system or runtime is already out of support, since that changes the urgency for every future finding.
Step 5: Watch it
Check the known exploited list for the affected component. CISA describes its catalog as an input to prioritisation. If your component appears, the compensating controls need another look.
In a hybrid estate
Legacy systems cluster in on premises sites and old accounts. Keep them in the same inventory as everything else so their exceptions show up in the same reports.
An example exception record
A reporting server runs a vendor product that has reached end of support. A library inside it has an advisory. The server is not reachable from the internet, two internal hosts connect to it, and its stored credentials were reduced to read access. The record lists those controls, names the data team as owner, sets a review in three months, and links a migration ticket for the next planning cycle. If the review finds the controls have slipped, the priority rises.
Quick check
Can I mark it not affected because it is behind a firewall?
Usually that is a mitigation, not proof the vulnerable code is absent. Record it as a compensating control unless you meet a not_affected justification.
How long can an exception last?
Set the limit in your policy. Short reviews, such as each quarter, keep the risk in front of someone.
Safeguard's policies and compliance and evidence automation help track exceptions and the controls around them. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
