By Manu Santamaría Delgado, Director of product management at WatchGuard Technologies
Vulnerability management has relied on a relatively straightforward model where vulnerabilities are identified, their severity assessed and those considered most critical for remediation are prioritised. Centralised vulnerability databases have played an important role in that process, providing security teams with the information they need to understand newly disclosed vulnerabilities and decide how quickly they need to respond.
That model is now changing. Changes to the way the National Vulnerability Database (NVD) operates mean that organisations cannot assume every vulnerability will receive the same level of contextual information from NIST. Although the NVD is still an important global source of vulnerability information, since April 2026 NIST has prioritised enrichment for higher-priority vulnerabilities, including those listed in CISA’s Known Exploited Vulnerabilities (KEV) catalogue and vulnerabilities affecting critical or US federal government software. CVEs outside these categories will still be added to the NVD but they may not receive immediate enrichment. According to NIST, this is due to the growth in CVE submissions, which increased by 263% between 2020 and 2025.
For UK organisations, the change reinforces that vulnerability databases are an important starting point but they cannot provide all the context needed to understand risk within an individual environment. This is reflected in NCSC guidance, which recommends taking factors such as active exploitation, system exposure and potential business impact into account when prioritising vulnerabilities.
Severity is not the same as risk
A vulnerability with a high severity score will not automatically be the most urgent issue facing an organisation. If it affects an isolated, non-critical system with strong controls around it, the immediate risk may be limited. On the other hand, a vulnerability that appears less severe on paper may actually need much faster action if it affects an internet-facing system, sits on a business-critical asset or is already showing signs of suspicious activity.
This is the limitation of relying on vulnerability scores on their own. They describe characteristics of a vulnerability but they do not always capture the context in which that vulnerability exists. The same vulnerability can represent very different levels of risk for different organisations, or even for different systems within the same organisation.
For an MSP, the challenge is even greater. A vulnerability affecting the same piece of software across multiple customers may not need the same response everywhere. One customer might have the vulnerable system exposed to the internet and connected to sensitive infrastructure, while another might have it on an isolated system with additional controls in place. The vulnerability has not changed. The risk has.
Building the context
As organisations are less able to rely on vulnerability databases to provide all of the context they need, they will need to build that context from information within their own environments. The starting point for this is knowing what assets exist and what role they play. An organisation cannot make an informed decision about a vulnerability if it does not know which systems are affected, where those systems are located, what they support or how exposed they are.
That means vulnerability management should be connected to asset visibility. Security teams need to understand which endpoints, servers and applications are actually affected, whether patches are available and what deploying those patches might mean for the business.
Exposure is another critical part of the picture. A vulnerability on an isolated system does not present the same urgency as one affecting an internet-facing asset or a system with access to sensitive networks. Understanding network connections, exposed services and accessibility fundamentally changes the priority assigned to a vulnerability.
Activity also needs to be considered. If a vulnerable endpoint is exhibiting unusual behaviour, showing signs of attempted exploitation, running suspicious processes or generating indicators of compromise, that should change the response. Vulnerability information is more meaningful when it can be considered alongside what is actually happening on the affected system.
This is why vulnerability management needs to connect with the wider security environment and not operate as a separate discipline.
From vulnerability management to risk management
What we are talking about here is a shift from focusing on how severe a vulnerability is to the actual risk the vulnerability creates. Identifying the risk requires information from across the environment. Vulnerabilities have to be considered alongside assets, endpoints, networks, identities and observed activity. When those different sources of information are connected, security teams can start to understand which vulnerabilities could have the greatest impact.
This also changes remediation. Prioritising a vulnerability doesn’t always mean immediately applying a patch. Patching will clearly be the right response sometimes, but other times the most effective way to reduce risk might be to isolate a device, restrict access, block a connection, remove an exposed service or increase monitoring until a permanent fix is available.
The important thing is that the action should be driven by the risk presented by the vulnerability and not just its score.
Remediation should not be considered complete just because a ticket has been closed or a patch has been deployed. Security teams need to verify that the vulnerability has actually been addressed, that unnecessary exposure has been removed and that there are no continuing signs of malicious activity.
More data doesn't automatically mean better decisions
Organisations are discovering more vulnerabilities than ever and are having to make decisions about which of those vulnerabilities deserve their limited time and resources. More data should make those decisions easier. But in practice, without the right context, it can make them harder.
A long list of vulnerabilities may give the impression of visibility, while leaving security teams unsure about where the greatest risk lies. The answer is to connect the information available with the wider context of the environment and not just to collect even more vulnerability data.
That means bringing together vulnerability intelligence with asset inventories, exposure information, endpoint and network telemetry, identity data and security events. The objective here is to develop a clearer picture of which vulnerabilities matter and why. Technology can help with this, particularly as security teams look to correlate large volumes of data. But the underlying principle is not technological. It is about recognising that a vulnerability is only one part of a risk assessment.
The next step for vulnerability management
The changes taking place around the NVD are a useful reminder that vulnerability management cannot be dependent on a single external source of context. Vulnerability databases will continue to be an important part of the security ecosystem but organisations need to put the information into the context of their own environments.
The future of vulnerability management will be about understanding which vulnerabilities create meaningful risk. Security teams need to know what is vulnerable, where it is, what it connects to, how exposed it is, what is happening on the system and what controls are already in place. Only then can they make informed decisions about what needs to happen next.