Vulnerability Statuses

The status of a vulnerability can be modified to help your team prioritize the vulnerabilities that matter and to track the lifecycle of your vulnerabilities. The Kenna platform offers four vulnerability statuses:

Open: The vulnerability is still a risk in your organizational data and is available in the Kenna platform for remediation. This is the default status for vulnerabilities.

Closed: The vulnerability has been remediated by your team. Once closed, it is removed from the Open vulnerability view. 

Risk Accepted: The vulnerability truly represents a risk, but the business has decided not to remediate it for some reason. A good example of a Risk Accepted vulnerability is an Internet Explorer vulnerability on a server in a data center that is not accessed or Java vulnerabilities that cannot be remediated because a legacy application will not be replaced until the next fiscal year. 

False Positive: The vulnerability identified in your scan file is not actually a vulnerability.

To modify a vulnerability's status, navigate to the Explore page, select a vulnerability from the list, and then select a status within the Set Status dropdown.

You will see the risk status that you’ve assigned to the vulnerability when you drill into the vulnerability details via the table. You can also flag many vulnerability at once as either risk accepted or false positive right in the Vulnerability Table (or all at once using the Display dropdown). Once selected, just assign the new status using the dropdown.


Flagging a vulnerability as risk accepted or as a false positive will remove those items from the risk meter score, as only open vulnerabilities contribute to an asset score. For Risk Meters that would have contained vulnerabilities that you marked risk accepted, you will see the Risk Meters True Risk score on the Group Overview of the Reporting page. 

You can add additional information to your vulnerability statuses (such as justification of the decision or a date to reevaluate) by creating a custom field for each. For Risk Accepted items, a Due Date is also recommended so that the business can revisit the decision to not remediate the risk. More information on using custom fields can be found here.




Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.