Key takeaways

• With 10,000+ open CVEs, the list has to be compared with what teams can fix in a month. That comparison decides which risks the organization accepts.
• In the version used here, SSVC sets the tier from four inputs: exploitation, reachability, impact and asset consequence. Compensating controls adjust the response time within a tier and leave the tier itself unchanged.
• Every ticket should include two clocks: one showing the time at which it was detected and another showing the time given by the regulation, for example the vendor’s release under PCI DSS.
• From September 11, 2026 the CRA requires manufacturers to give an early warning within 24 hours of them realizing that a vulnerability is being actively exploited.

Every security team with a big backlog makes a risk decision each month, usually without noticing it. A team closes a fixed number of items a month, and whatever falls below that line is accepted risk by default.

The figure in Verizon’s 2026 DBIR shows that in 2025 only 26% of the vulnerabilities listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog had been completely remediated, this representing a drop from the 38% that had been completely remediated the year before.

It is simple to rank the list when there are 10,000 or more open CVEs; the difficult thing is working out what teams can close and then justifying the rest to an auditor.

How to prioritize vulnerabilities with SSVC when you have 10,000+ open CVEs

Capacity is the top priority. You should match the list to what teams close each month and then select the items that fit. As for scoring, Stakeholder-Specific Vulnerability Categorization (SSVC) provides a good foundation, using mitigation as a separate filter. CISA’s BOD 26-04, which was issued on June 10, 2026, revoked BOD 22-01 and eliminated CVSS as the required input for US federal prioritization.

In the version used here, the tier is determined by means of four questions which are asked in a fixed order. The first of these is regarding the exploitation status. For cases that are known, KEV provides an answer to this question and for the others EPSS supplies the 30-day exploitation probability. A CVE that is not present in KEV can still be exploited. Whether or not exploitation can be automated is a separate SSVC input.

Reachability is considered starting with the network and then moving on to the application; if a vulnerable library is located in a code path that the application never calls, it is removed from the urgent queue, and that decision should be included in a VEX statement, since one statement can replace forty tickets that make the same argument.

The final two questions are about the effects: whether exploitation results in the attacker gaining full control or only causes a minor inconvenience, and what a compromised asset exposes, for example privileged credentials, production data, or a trusted connection into the identity platform.

Exploitation functions as a gate and thus determines whether a finding gets to the top levels or not.

Mitigation functions as a separate filter outside of SSVC, providing protections such as a WAF rule, a segmentation boundary or an EDR detection, and it never reduces the tier. A vulnerability listed in the KEV that grants full control over an exposed asset remains at P0 even if an EDR signature is available. The mitigation then places it at the later end of the P0 response window.

The fix cost and the chaining potential break the tie; when two defects of medium severity are connected by the appropriate access path, this results in a complete compromise.

It is better to state one caveat at the beginning than to find out about it during an incident: the pipeline is CVE-shaped. Flaws that are not given a CVE identifier and cloud misconfigurations as well as identity exposure usually do not end up in it, even though they should still be included in the same risk queue.

Vulnerability management vs. vulnerability remediation: why fix rates lag behind discovery

A ranked queue only reduces risk after a person has gone through it. Picture a mechanic who hands you a binder listing thousands of worn seals and faulty sensors. There is no quote and no appointment, and the owner field is empty.

The diagnostic aspect is vulnerability management, covering the process from discovery right through to verified closure. Remediation involves the actual correction, this being either a patch, a change to the configuration, an upgrade in version, the removal of a component, or the implementation of a control which reduces exposure. It is the only step that has the effect of reducing risk; all the other steps just monitor it, and monitoring is the inexpensive one.

This difference is the reason why so many organizations manage to identify vulnerabilities easily but struggle to implement fixes. Although scanning tools can be purchased, each and every fix has to be negotiated. Since security teams are evaluated on the number of things they discover and operations teams on uptime, the practice of passing work off to others is not rewarded.

The real problem is ownership since a fix is added to the backlog along with new features, competes with the product managers’ priorities and seldom gets to the top level. It also alters the way the system behaves, which the teams oppose.

As the process of diagnosing problems is inexpensive, it makes sense to address the issue at its source. A single, hardened base image that is patched at the central level replaces 400 container tickets. Automated updates to dependencies remove the need for human review when carrying out regular version upgrades, and patching is now included in the release train as part of the standard delivery process. However, the work still has to be funded since remediation remains just a wish until it has been assigned a budget line and a specific owner.

A 100% fix rate is an unrealistic target, and accepting some risk is reasonable when a named person makes that decision. If a program detects problems and fails to close them, this shows there is an ownership issue, and a new tool leaves that ownership problem untouched.

How to build a vulnerability remediation SLA by severity that regulators accept

Ownership only becomes enforceable via deadlines, and since the deadlines vary depending on the rule, the first thing to do is to establish which rules apply. Under PCI DSS, one month is given for critical patches in the cardholder data environment, starting from the date the vendor releases them. BOD 26-04 specifies three calendar days for the top tier, but only applies to US federal civilian agencies. The CRA’s 24-hour rule relates to manufacturer reporting, meaning that the fix deadlines come from other sources.

Each ticket is therefore operated on two clocks. The clock that is used for operations begins at the moment of detection and determines priority. The compliance clock begins at the point specified by the regulation, which in the case of PCI DSS is when the vendor releases it. Programs which monitor only the operational clock will fail the audits.

The policy described here sorts each finding into five tiers:

• P0: being actively exploited, facing the internet, full control. It must be contained within 24 hours, remediated in 72, and have a forensic triage carried out.
• P1: has been exploited or is so simple as to be trivially automatable, and is exposed. 14 days.
• P2: is exposed and there is no sign of exploitation. Either 30 days or the vendor’s clock, if that is shorter.
• P3: internal only, with compensating controls in place. For a period of 90 days or until the next release train.
• P4: there is no reachable path. The next planned upgrade.

A P3 is promoted on the day that an exploit appears.

Before an auditor makes a request, definitions of pause states are required; the „Awaiting vendor fix” pause only affects the operational clock, demands a documented mitigation, and is presented as a separate category, outside of the compliant column.

It is in the case of exceptions that the frameworks fail. Each exception must have a named risk owner, a written justification together with the compensating controls associated with it, as well as an expiry date and a mechanism for escalation which increases the approval level each time the exception is renewed. An exception that lacks these elements is simply a backlog which has been reclassified as risk acceptance.

Tiers will only remain in effect so long as they correspond to actual capacity; once the volume for P1 exceeds the amount that the teams are able to handle, the P1 deadline ceases to be real. Report percentiles over averages: the p90 for each tier, the age of the open items, the number of active exceptions, and the rate at which findings are reopened after verification.

How CVSS scores fail in practice and what context to add

Every tier described above uses context that the CVSS base score leaves out. CVSS is good at assessing software flaws. If you use it by itself, it is like evaluating the risk of a fire by looking only at its ignition temperature and ignoring whether the material is close to a spark or behind a fire door.

The standard stands up well: version 4.0 has replaced „Temporal” with „Threat”, included a Supplemental group covering safety, automatability and recovery, and removed „Scope”. The real problem lies in the supply chain associated with the scoring. The NVD publishes only the base metrics and still assigns scores to most entries under version 3.1, and since its 2024 backlog many CVEs have arrived unanalyzed.

So the number on a ticket describes a worst case that may never happen. It inflates a defect in a component the application never calls, and it undersells a flaw that attackers are already using. A finding that has been mitigated receives the same score as one that is unprotected.

Some of the corrections are free since threat and environmental metrics are used to make local adjustments to the base score and since the data relating to KEV and EPSS is publicly available; yet very few people fill them in.

The parts left over are those which the organization has to develop itself: exposure, compensating controls and asset criticality. The aspect of compensating controls is the most obvious area of weakness, since a WAF rule has no effect on the base score. Criticality needs a live source too, because a dull service becomes high risk the moment it holds privileged credentials or connects to the identity platform.

CVSS is fine for parking findings that can wait. Exploitation, exposure and asset criticality should order the rest. Drop the „number of criticals” as a status metric, because it only reflects the scanner’s opinion.

What to automate in vulnerability management and what needs human judgment

Applying this context by hand to all 10,000 findings would use up the capacity that it is intended to safeguard. Discovery scales on its own and another scanner mainly increases the backlog. The appropriate test for automation is reversibility: automate those tasks that are repeatable and easy to reverse, and have people make the decisions that are irreversible or in dispute. Based on that rule, automation should be applied in the following steps:

• Ongoing discovery across multiple clouds, containers and endpoints, with duplicates removed down to the root cause.
• The necessary background information from the EPSS, KEV and the exposure data means that the tiers can be determined without having a meeting.
• Suppressing unreachable findings using SBOMs and VEX means that „shipping the library but never calling the affected function” can be made machine-readable. The CRA support obligations run on this pipeline.
• Routing tickets according to ownership, with each ticket specifying the fix and the deadline; in the case of a simple entry such as „CVE-XXXX on 10.4.22.17” the engineer has to work out both details.
• Staged deployment together with regression tests and an automatic rescan when the task is closed; the rescan is the step which most programs leave to manual action.
• Mechanics of governance: escalating approvals, the expiry of exceptions and SLA clocks.

The responsibility for managing the impact of patches and deciding when to release them remains with people, since applying patches during a business peak can cost more than the fault itself. Likewise, people still have to deal with risk acceptance, the adequacy of any compensating controls, unclear findings, and logical flaws in custom code. They also carry out forensic triage at P0, because a patch does nothing about an attacker who is already inside.

Before closing security logic flaws, AI coding agents must be subject to human review since, although the writing of the code can be outsourced, the responsibility remains with the organization.

What the CRA changes in vulnerability management for product manufacturers

For manufacturers the CRA turns a number of these options into legal obligations and passes the responsibility for product security from the customer to the manufacturer, the aim being to ensure that products are shipped without any known exploitable vulnerabilities and to remedy those which come to light during support.

Reporting duties have applied since September 11, 2026. The full product requirements follow on December 11, 2027. Two things trigger a report: a vulnerability that is being actively exploited and a severe incident that affects the product’s security. Routine scanner results fall outside that scope.

The reports are sent through ENISA’s single reporting platform to ENISA and to the coordinating CSIRT. An early warning must be provided within 24 hours of awareness and a more detailed notification issued within 72 hours. The final report is submitted 14 days after a corrective or mitigating measure is available for a vulnerability that has been exploited, or one month after the 72-hour notification in the case of a severe incident. Fines can amount to millions of euros.

The situation is set in motion by becoming aware of it. According to the guidelines issued by the Commission, awareness is described as a reasonable degree of certainty following an initial assessment. The clock provides an opportunity for the first triage; waiting until full forensic confirmation has been obtained would mean that the manufacturer goes beyond the deadline.

Reporting applies to products that are already on the market, whereas the full requirements only apply to older products after they have undergone substantial changes. These requirements involve providing technical documentation, carrying out a conformity assessment and obtaining CE marking, along with providing free security updates that are supplied separately from feature updates. The five-year support period is a minimum and has to correspond to the way the product is expected to be used; it will only be shorter in cases where that use is temporary.

Enterprise IT could always isolate a legacy system that was too fragile to patch and accept the associated risk. However, in the case of a product that is already on the market, this option is no longer available, since the manufacturer would then have to take on that risk for its customers. As a result, technical debt becomes more costly, and SBOM tracking, a reliable update channel and proper vulnerability management become a sales point.

FAQ

What is SSVC and why use it for vulnerability prioritization?

SSVC (which stands for Stakeholder-Specific Vulnerability Categorization) is a decision-tree approach to prioritization; the version used here sets a priority level by means of four questions: whether the flaw is being exploited, whether an attacker can get to it, what exploitation would give the attacker, and what consequences a compromise of that asset would have. It is well suited to large numbers of vulnerabilities since it takes into account the specific circumstances of each case. In June 2026, CISA’s BOD 26-04 abolished the requirement to use CVSS for prioritization in the United States federal sector.

How many days should a remediation SLA allow for critical vulnerabilities?

The time frame varies according to the tier and the particular rule in question. In the type of model referred to in this case, any flaw that is exploited, internet-facing and gives full control is contained within 24 hours and corrected within 72 hours. Exposed flaws that are exploited or can be easily automated are given 14 days, and those that are exposed but show no sign of being exploited receive 30 days. Under PCI DSS, one month is allowed for critical patches, the period beginning at the time the vendor releases them.

Do compensating controls lower a vulnerability’s priority?

The priority level remains the same when compensating controls are in place. For example, if a WAF rule, network segmentation or an EDR detection is in effect, the longer end of the response time within that priority tier can be used. However, a flaw that is being actively exploited and which gives full control of an exposed asset will still be assigned a priority of P0 even though an EDR signature exists. Since CVSS base scores do not take these controls into account, teams have to evaluate them on their own.

What is the difference between vulnerability management and remediation?

Vulnerability management is a diagnostic procedure which involves discovery, deduplication, prioritization, assignment of owners, tracking of deadlines and verification that the vulnerabilities have been closed down. The actual correction, remediation, can consist of patching, reconfiguring, upgrading, removing a component or adding a control that reduces exposure. A great many organizations manage the first of these stages well but have difficulty with the second, mainly since it is not clear who is responsible and what the budget is for carrying out the fixes.

When does CRA vulnerability reporting start and what triggers it?

CRA reporting obligations apply from September 11, 2026. They are triggered by actively exploited vulnerabilities and by severe incidents affecting product security, while routine scanner findings stay outside that scope. Manufacturers send an early warning within 24 hours of becoming aware, a fuller notification within 72 hours and a final report later, all through ENISA’s single reporting platform. Full product requirements follow on December 11, 2027.

What should be automated in vulnerability management?

Automate the steps that are repeatable and easy to reverse: continuous discovery and deduplication, enrichment with KEV, EPSS and exposure data, reachability suppression through SBOM and VEX, ownership-based ticket routing, regression-tested deployment with rescans, and SLA and exception tracking. People should keep decisions on production timing, risk acceptance, ambiguous findings, logic flaws in custom code and forensic triage of the most severe cases.