The National Vulnerability Database now gives security teams more context for deciding which vulnerabilities require action. The useful change is not another score to place in a dashboard. It is better evidence for connecting a CVE to an affected product, choosing a response, and moving the issue into remediation.
In June 2026, the National Institute of Standards and Technology expanded National Vulnerability Database feeds and APIs to include Stakeholder-Specific Vulnerability Categorization data and affected-product information. An August update brought these fields to NVD CVE detail pages and changed how affected-product history is delivered.
Remediation teams should treat these fields as new layers in an existing decision process. Severity, exploitation evidence, affected-product accuracy, asset exposure, business impact, and available remediation methods still need to work together.
What changed in the NVD?
The NVD added two useful forms of vulnerability intelligence:
• SSVC data: Decision-oriented information that helps teams assess response priority using factors such as exploitation status, automation potential, and technical impact.
• Affected-product data: Structured information identifying the products, configurations, and versions that a CVE record lists as vulnerable.
NIST says SSVC and affected-product data became available across NVD feeds and APIs on June 17, 2026. On August 26, NIST announced that both would also appear on CVE detail pages when available.
NIST also changed the CVE history feed. Affected-product modifications now point to the corresponding CVE record in GitHub instead of embedding the full affected-data payload in every audit entry. The existing CVE detail endpoint continues to return the latest full affected-product data.
For teams that consume NVD data at scale, the feed change may require an adjustment to ingestion logic. For vulnerability practitioners, the larger benefit is clearer evidence for two questions:
1. Does this CVE affect a product and version in our environment?
2. If it does, what response does the exposure require?
The new fields improve both decisions. Accurate inventory and local business context determine how useful the answers become.
Source: NIST National Vulnerability Database status updates.
What is SSVC?
Stakeholder-Specific Vulnerability Categorization is a decision-tree methodology for prioritizing vulnerability response.
CISA's SSVC model produces four possible decisions:
• Track: Monitor the vulnerability. No immediate action is required.
• Track*: Monitor it more closely because a change in exploitation or impact could raise its priority.
• Attend: Coordinate with the relevant stakeholders and prepare a response.
• Act: Take urgent remediation or mitigation action.
This structure is useful because vulnerability teams do not need another isolated number. They need a defensible decision that connects technical evidence to operational action.
CISA's model considers factors such as exploitation status, automation potential, technical impact, mission prevalence, safety, and public-wellbeing consequences. Organizations can then add their own context: asset exposure, business ownership, sensitive data, existing controls, maintenance constraints, and the operational risk of making a change.
Source: CISA SSVC Guide.
How do CVSS, EPSS, KEV, SSVC, and affected-product data differ?
Each signal answers a different question.
FIRST emphasizes that the CVSS Base Score measures severity rather than complete organizational risk. Its guidance recommends adding threat and environmental information.
EPSS estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. FIRST also explains that EPSS does not measure the potential damage from exploitation, the importance of an affected asset, or the effectiveness of local controls.
CISA describes the Known Exploited Vulnerabilities catalog as the authoritative source for vulnerabilities confirmed as exploited in the wild. CISA recommends using it as an input to vulnerability prioritization.
For a deeper comparison, see CVSS vs. EPSS vs. KEV: Which score actually matters?.
Sources: FIRST CVSS v4.0 specification, FIRST EPSS FAQ, and CISA KEV Catalog.
What should remediation teams change?
The NVD update should improve the decision process, not add two more columns that analysts must review manually.
1. Confirm that the affected product is present
Start with asset and software inventory. Compare the affected-product record with:
• Product and vendor
• Installed version
• Operating system or platform
• Deployment configuration
• Internet exposure
• Business owner
• Production, development, or test status
An affected-product match shows that a vulnerability may apply. Configuration, feature usage, network reachability, and existing controls determine what the finding means for a specific asset.
2. Establish the potential technical consequence
Use CVSS to understand the vulnerability's technical characteristics, including attack vector, required privileges, user interaction, and effects on confidentiality, integrity, and availability.
The Base Score is a starting point. FIRST's CVSS v4.0 guidance recommends adding threat and environmental metrics when teams need a result that better reflects their environment.
3. Add observed and predicted exploitation evidence
Check KEV for confirmed exploitation. A KEV entry should trigger immediate asset matching and time-bound triage, including when its CVSS score is lower than other items in the queue.
Use EPSS to distinguish among vulnerabilities without confirmed exploitation. Because EPSS is updated daily, it can highlight changes in exploitation probability before a vulnerability appears in an observed-exploitation catalog.
The signals become more useful when combined:
• KEV identifies evidence of real-world exploitation.
• EPSS estimates near-term exploitation probability.
• CVSS describes technical severity.
• Asset context reveals what is exposed and what matters to the business.
This combination helps teams reduce a patch backlog without treating every high-severity finding as equally urgent. How to reduce patch backlogs with less manual work covers the operational side of this process.
4. Use SSVC to make a response decision
Apply the relevant SSVC factors, then add organizational context:
• Is exploitation occurring?
• Can an attacker automate exploitation at scale?
• Would exploitation cause partial or total technical impact?
• Is the affected asset externally reachable?
• Which data or business process depends on it?
• Could exploitation affect safety, revenue, customers, or regulatory obligations?
• Do current controls reduce the exposure?
• What operational risk would the remediation introduce?
The output should tell the team what to do next.
Two assets can contain the same CVE and require different responses. An internet-facing production system that supports customer authentication may require immediate action. An isolated test system with effective controls may fit its planned maintenance window. The CVE is the same. The exposure is different.
5. Choose the remediation method
A priority becomes useful when it leads to an executable treatment. Available actions may include:
• Deploying the vendor patch
• Changing the vulnerable configuration
• Removing or disabling the affected component
• Applying a vendor mitigation
• Restricting access or segmenting the system
• Deploying a script-based remediation
• Applying patchless protection or another compensating control
• Accepting the risk for a defined period with a named owner
When a patch is unavailable or cannot be deployed within the required timeframe, the team still needs a way to reduce exposure. Vicarius vShield Patchless Protection provides an alternative remediation path for supported scenarios where conventional patching is not the immediate option.
6. Verify the result
A completed deployment job does not prove that the vulnerable condition is closed. After remediation, verify:
• The intended asset received the change
• The installed version or configuration changed
• The vulnerable condition is no longer present
• The relevant exploit path is no longer reachable where validation is possible
• The change did not create an availability or operational problem
• The evidence required for audit and reporting was retained
This is the difference between recording activity and proving risk reduction. What is vulnerability remediation in 2026? explains the full remediation lifecycle.
The Vicarius approach to true remediation
Vicarius treats vulnerability remediation as a closed loop. The process starts by identifying which exposures matter, continues through the appropriate remediation method, and ends with validation that the risk went down.
vScore risk-based prioritization combines CVSS, EPSS, CISA KEV data, exploit intelligence, asset criticality, and business context. The result is a prioritized queue shaped by the actual environment.
The next step is action. Depending on the vulnerability and operational requirements, teams can use patch deployment, script-based remediation, or patchless protection. Validation then confirms whether the vulnerable condition has been addressed.
This is what turns vulnerability intelligence into true remediation. Teams move from finding and ranking risk to reducing it and proving the outcome.
The new NVD fields strengthen the evidence available at the start of that process. Their value is realized when affected-product data and response intelligence lead to a concrete remediation decision.
Explore the Vicarius automated vulnerability remediation approach.
Common mistakes when adopting the new NVD data
Using SSVC as a substitute for CVSS
CVSS communicates technical severity. SSVC structures the response decision. Together with threat intelligence and asset context, they provide different parts of the evidence needed for prioritization.
Treating affected-product data as perfect inventory matching
CVE records evolve, vendor naming may differ from internal inventory, and configuration can determine whether a product is vulnerable. Teams still need reconciliation and exception handling.
Automatically patching every high-priority result
Priority determines urgency. The correct treatment depends on the system. Production, operational technology, and safety-sensitive environments may require staged deployment, maintenance windows, or compensating controls.
Stopping when a change is deployed
If the vulnerable condition remains, remediation is incomplete. Validation belongs inside the workflow.
Adding intelligence without simplifying the decision
More data can create more work. Each signal should clarify at least one decision: affected assets, urgency, ownership, remediation method, or validation.
Frequently asked questions
Does SSVC replace CVSS?
No. CVSS communicates technical severity, while SSVC guides response decisions. Use CVSS as technical input and SSVC as part of a broader process that includes exploitation evidence and organizational context.
Is an SSVC Act decision the same as patch immediately?
Not always. Act means the vulnerability requires urgent attention. The response may be a patch, configuration change, isolation, vendor mitigation, patchless protection, or another compensating control.
Does NVD affected-product data prove that an asset is vulnerable?
No. It identifies products and versions described as affected in the CVE record. Teams must correlate that information with inventory, configuration, reachability, and validation data.
How should teams combine CVSS, EPSS, KEV, and SSVC?
Use CVSS to understand technical severity, KEV for confirmed exploitation, EPSS for near-term exploitation probability, and SSVC to structure the response. Add asset exposure, business criticality, existing controls, and remediation safety before setting the final priority.
When should vulnerability priorities change?
Reassess priority when meaningful evidence changes. That may include EPSS movement, a new KEV entry, revised affected-product data, new exploitation evidence, a change in asset exposure, or a change in business importance.
What makes vulnerability remediation complete?
Remediation is complete when the vulnerable condition has been fixed or effectively mitigated and the reduction in exposure has been validated. A deployed patch or closed ticket is one step in that process.
The practical takeaway
NVD's SSVC and affected-product data give remediation teams better inputs. Those inputs become useful when they are connected to inventory, exploitation evidence, business context, remediation, and validation.
A strong workflow follows seven steps:
1. Confirm that the product and asset are affected.
2. Understand the potential technical severity.
3. Check observed and predicted exploitation.
4. Add organizational exposure and business impact.
5. Make an explicit response decision.
6. Execute the safest effective remediation.
7. Validate that the exposure is closed.
That is how vulnerability intelligence becomes true remediation.
See true remediation in action
See how Vicarius connects risk-based prioritization, multiple remediation methods, and validation in one workflow. Request a 30-minute vRx demo.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
.webp)
