Vulnerability and patch management that fixes what can reach you.
More than a hundred CVEs are published every day and you cannot patch them all. We scan your whole estate, rank the handful that are being exploited or can reach you, drive the fix, and keep the audit log NIS2 asks for.
Vulnerability and patch management is the program that finds the weaknesses across your systems, decides which ones actually matter, gets them fixed, and proves it. It is a security discipline rather than an admin task, because well over a hundred CVEs are published every day and only a small fraction are ever exploited. Argus Root runs that program across your whole estate from inside the EU, and closes the gap between knowing about a vulnerability and having fixed it.
In short
- A record 48,185 CVEs were published in 2025 — about 131 a day, up from ~40,000 in 2024 — so patching everything is no longer possible.
- Volume is not risk: of those 48,000+ CVEs, only around 800 were exploited in the wild, and just 2.3% of CVSS-7-and-above vulnerabilities are ever seen being exploited.
- Prioritising by CISA KEV (known exploited) and EPSS (exploitation probability) can cut the patching workload by roughly 95% while still covering most of what attackers actually use.
- In April 2026 the NVD moved to a triage model, enriching only a fraction of CVEs, which makes KEV and EPSS outweigh a raw CVSS score for deciding what to fix first.
- Edge and VPN exploitation rose roughly eightfold, and 46% of actively exploited flaws predate 2021 — patch the internet-facing edge and the old, forgotten systems first.
Can you patch every CVE?
Around 132 CVEs are published daily, with exploit windows measured in days, yet only about one in ten known vulnerabilities ever gets a public exploit. Treating every high CVSS score as urgent buries the few that count. The job is prioritisation: cross-reference what is being exploited right now, what is likely to be, and whether it can even reach you. Edge devices, VPNs and firewalls draw a disproportionate share of attacks, so they go to the front of the queue. The uncomfortable benchmark is that critical vulnerabilities sit unpatched for months on average, and closing that gap is the point of the service.
| Signal | What it tells us | How we act |
|---|---|---|
| CISA KEV | It is being exploited right now | Emergency patch within 48 hours |
| EPSS | How likely exploitation is soon | Raise above its CVSS when high |
| CVSS | Worst-case impact | An input, not the verdict |
| Exposure & criticality | Whether it can reach you | Reachable production beats isolated lab |
| No patch yet | A window with no fix | Compensating control the same day |
The volume has gone from a queue to a firehose. More than 48,000 CVEs were published in 2025, with submissions up over 260% since 2020, and in April 2026 the US National Vulnerability Database stopped trying to keep pace: it now fully enriches only an estimated 15 to 20% of incoming CVEs, prioritising the ones that are exploited or sit in critical software. A program that still triages by the NVD severity score now misses roughly a third of the bugs being exploited in the wild, because the score is simply not there for most of them.
So the queue starts somewhere else. The signals that matter operationally are active exploitation, from the CISA Known Exploited Vulnerabilities catalog, and the probability of imminent exploitation, from EPSS, with the raw severity score as a third input rather than the deciding one. The urgency is real: exploitation now routinely beats the patch, with the average time to exploit estimated at around negative seven days in 2025, meaning attackers are weaponising a flaw before most organisations have applied the fix. Triaging the firehose by what is being used against people is the only way to spend a finite team on the few hundred findings a year that can hurt you rather than the forty thousand that cannot.
Remediation, and the proof you fixed it.
Finding a vulnerability is half the work; fixing it and showing the fix is the rest. We drive remediation rather than hand you a report. The operating-system patches run through our server management, and where no patch exists yet we put a compensating control in place the same day, a firewall or WAF rule, rather than wait for a maintenance window that leaves the door open.
Every decision is recorded with its reasoning, including a deliberate choice to defer or accept a risk, which is the audit-ready log NIS2 and SOC2 expect rather than a spreadsheet reconstructed before an assessment. The program reduces what an attacker can use; our managed security catches what still gets through, and the evidence feeds compliance.
Speed is governed by who can act, rather than by what needs acting on alone. A critical finding routed to a team with deployment access and a 72-hour SLA closes on a different timescale than one waiting three weeks for a change window, so the program assigns each finding to whoever can fix it with a deadline tied to its risk, and tracks the metric a board now watches: the share of top-tier findings closed inside their SLA. A vulnerability is not managed when it is known; it is managed when it is closed and the closure is proven to have held.
What we run.
A continuous program across the whole estate, not a quarterly scan and a PDF.
Discovery & continuous scanning
An inventory of what you really run, scanned continuously, including the software dependencies and edge devices that a server scan alone would miss.
Risk-based prioritisation
Findings ranked by active exploitation, likelihood and reachability rather than raw severity, so effort lands on the few that can hurt you.
Remediation orchestration
Patches driven through server management, or a compensating control where no patch exists, each routed to whoever can act with an SLA tied to the risk.
Verification
Every fix re-checked to confirm it held, because a closed ticket and a closed vulnerability are not always the same thing.
Edge-first cadence
VPNs, firewalls and load balancers on the tightest cycle, because that is where initial access has shifted and where a miss costs most.
Audit-ready reporting
A prioritisation log with the rationale for every call, ready for an NIS2 or SOC2 assessor. See compliance →
We've patched the emergencies ourselves.
When a serious vulnerability lands without a vendor patch ready, we have applied kernel-level mitigations on our own servers to close the window before the fix shipped, which is the difference between reading about a CVE and having handled one. We are honest about the limit that every team faces: you cannot patch everything, so the work is choosing correctly and proving the choice. The program is built to make that call well and leave a record an auditor can follow.
# only fixable HIGH/CRITICAL — skip what has no patch yet $ trivy image --severity HIGH,CRITICAL --ignore-unfixed app:1.4.2 app:1.4.2 (debian 12.5) Total: 3 (CRITICAL: 1, HIGH: 2) LIBRARY VULNERABILITY SEVERITY INSTALLED FIXED openssl CVE-2025-XXXX CRITICAL 3.0.11-1 3.0.14-1 ← on CISA KEV: patch now glibc CVE-2025-YYYY HIGH 2.36-9 2.36-9+deb12u7 curl CVE-2025-ZZZZ HIGH 7.88.1-10 7.88.1-10+deb12u8 # of ~131 CVEs/day, the ones on KEV or with high EPSS are the few that matter
Is a high severity score the same as high risk?
The mistake that buries most programs is treating the severity score as the priority. A vulnerability rated critical on paper may sit behind three controls on an isolated box no attacker can reach, while a medium-rated one on an internet-facing appliance with a public exploit is the real emergency. Severity describes the flaw in the abstract; risk describes what it means in your environment, which turns on whether it is being exploited, how likely exploitation is, and whether an attacker can reach it at all.
We prioritise on those together. Active exploitation comes first: anything in the KEV catalog jumps the queue. The EPSS probability of near-term exploitation comes next, then the raw severity, and over all of it sits reachability, whether your own controls would stop the exploit before it landed. Layering exploitation, probability and reachability over the severity score is what cuts the urgent workload sharply, by as much as 95% in some analyses, because it strips out the critical-rated findings that pose no real risk to you.
| Signal | What it tells you | Weight |
|---|---|---|
| KEV | It is being exploited now | Top of the queue |
| EPSS | Probability of exploit in 30 days | Second |
| Reachability | Can an attacker reach it here | Context multiplier |
| CVSS severity | How bad in the abstract | One input, not the answer |
What should you patch first?
If a program does one thing well, it should be the edge. The network appliances meant to protect the perimeter, the VPNs, firewalls and load balancers, now account for around 44% of zero-day exploitation, and of the ransomware-linked vulnerabilities added to the KEV catalog in 2025, roughly a third targeted exactly those devices: Ivanti, Fortinet, Citrix, Palo Alto and the like. The box you bought to keep attackers out has become a favourite way in.
So the edge runs on the tightest cadence we operate, a 24 to 48 hour SLA for a KEV-listed appliance flaw, because that is where initial access has shifted and where a missed patch costs most. Internet-facing systems are treated as the highest tier by default, scanned and fixed ahead of the internal estate, since an attacker reaches them first. A program that patches workstations on schedule while a perimeter appliance waits for the monthly window has its priorities exactly backwards.
What do you do when there is no patch yet?
A vulnerability does not wait for a vendor to ship a fix, and neither can the response. When a flaw is being exploited and no patch exists, we put a compensating control in place the same day, a firewall or WAF rule that blocks the exploit path, a configuration change that removes the exposed feature, a network restriction that takes the asset out of reach, rather than leave the window open until the vendor catches up.
The mitigation is recorded as a deliberate, temporary measure and then replaced with the proper patch once it ships, so a stopgap does not quietly become permanent. This virtual-patching discipline closes the gap between disclosure and fix, the days or weeks in which a known, unpatched flaw is most dangerous because everyone, attackers included, now knows it exists. Waiting for the patch is not a plan when exploitation beats the patch by a week.
Beyond CVEs: managing exposure, not the bug list alone.
A modern program has outgrown the CVE list. Attackers do more than walk through unpatched software; they use misconfigurations, exposed credentials, end-of-life systems no longer receiving patches, and the attack paths that chain several minor weaknesses into one serious route in. Nearly half of the actively exploited vulnerabilities in the KEV catalog target software released before 2021, which is to say end-of-life boxes that a CVE-only program records forever and never resolves.
Continuous exposure management widens the lens to all of it: the misconfigurations, the identity risks, the shadow IT and the EOL systems alongside the CVEs, ranked by which combination an attacker could realistically use to reach something that matters. We run the program as exposure reduction rather than ticket-closing, so an end-of-life system gets a migration timeline instead of a perpetual open finding, and a chain of small issues is broken at its cheapest link rather than ignored because no single piece scored as critical on its own.
You cannot fix what you cannot see.
Every vulnerability program rests on an inventory, and the inventory is where most quietly fail. The systems that get breached are often the ones nobody knew were there: a forgotten server still answering on the internet, a test box that became production, a SaaS account spun up by a team without telling anyone, a dependency buried three layers inside an application. A scan of the assets you remember leaves the ones you forgot wide open, and those are the ones an attacker finds first.
So discovery comes before scanning. We build a live inventory of what you really run, internal and internet-facing, including the software dependencies, the edge devices and the shadow IT that a server-by-server view misses, and we keep it current as the estate changes rather than refresh it once a year. The continuous scan then runs against the real attack surface rather than a stale asset list, because a finding you never generated on a system you never catalogued is the most dangerous kind: the one you will not be looking at when it is exploited.
The gap between knowing and fixing.
Most organisations are not short of findings; they are short of fixes. The scanner produces a list, the list grows faster than anyone can work it, and the genuinely dangerous items sink into a backlog of thousands that no one has time to read. The problem is rarely that the vulnerability was unknown; it is that knowing did not turn into fixing fast enough, and the window between the two is exactly where an attacker operates.
Closing that gap is the part we own. A finding is routed to whoever can act on it with an SLA set by its risk, the remediation is driven rather than suggested, and the item stays open in our tracking until it is verified closed rather than marked done when a ticket is. Where remediation needs a change window, a rollback plan or coordination across teams, that is arranged rather than left as the reason a critical fix waited a month. The measure of a program is not how many vulnerabilities it found but how fast it closed the ones that mattered, and that it can prove they stayed closed.
Scanning without drowning your team.
A scanner pointed at a large estate produces an overwhelming amount of output, much of it duplicated across tools, some of it false, and most of it irrelevant to your actual risk. A team handed that raw feed burns its time confirming false positives and triaging noise, which is how the one finding that mattered gets lost in the ten thousand that did not. Volume without filtering is not visibility; it is paralysis with a dashboard.
We normalise and de-duplicate across sources, validate findings before they reach a person, and surface the short list that combines real exploitability with reachability in your environment. The work the machine can do, correlation, enrichment, ruling out the unreachable, is done before a human looks, so the time of the people in the loop goes to the decisions and the fixes rather than to clearing a queue. The output is a handful of things worth doing this week, not a report nobody finishes reading.
Reporting a board and an auditor can use.
A raw count of open vulnerabilities tells a board nothing useful; the number is always large and always frightening, and it moves for reasons that have little to do with how exposed the business is. What leadership needs is the trend that matters: whether the dangerous findings are being closed inside their SLA, whether exposure is falling over time, and where the risk that remains is concentrated. We report in those terms, the share of top-tier findings closed on time, the direction of travel, the residual risk being deliberately carried, rather than a headline figure that alarms without informing.
The same record answers the auditor. Every prioritisation decision is logged with its reasoning, including the deferrals and the accepted risks, with the SLA each finding was held to, so the documentation NIS2 and SOC 2 expect exists as a by-product of running the program rather than a reconstruction before an assessment. The evidence that the program is working and the evidence a regulator asks for are the same evidence, produced once and used for both.
How does a vulnerability program start?
A program opens with a baseline rather than a bill. We discover the estate, run the first full scan across it, and produce a prioritised picture of where you stand: the KEV-listed and high-EPSS findings that need acting on now, the edge exposures, the end-of-life systems, and the longer tail that can wait. That first assessment is usually a sobering and useful document, because it is the first time the real attack surface has been seen whole rather than guessed at from a partial scan.
From there the program becomes continuous: ongoing discovery and scanning, risk-based prioritisation, driven remediation with SLAs, verification, and the reporting that feeds the board and the auditor. We integrate with the ticketing and change process you already use rather than impose a parallel one, so remediation lands in the workflow your teams already follow. The aim is a steady downward trend in exposure that you can watch month over month, rather than a scan that lands in an inbox and changes nothing.
Questions buyers ask.
What is vulnerability management?
Why can't you just patch everything?
How do you decide what to patch first?
How is this different from your server management?
What if there is no patch available yet?
Does this help with NIS2?
How many CVEs are published now?
What changed with the NVD in 2026?
What is the difference between CVSS, EPSS and KEV?
Why do you patch edge devices first?
What is continuous threat exposure management?
How do you find assets we have forgotten about?
We already have a scanner. Why is that not enough?
How do you report this to our board?
Do you only scan, or do you fix it too?
How does this fit with our existing ticketing and change process?
Is this a one-off assessment or ongoing?
Does this cover cloud and containers as well as servers?
How often do you scan?
Let us scan your estate. We'll show you the few that matter.
Point us at your systems and we run a first scan across them, rank what we find by active exploitation and reachability, and show you the short list that needs action now, with what remediation would take, before you commit to anything.