Vulnerability remediation stays manual because finding a flaw and fixing it involve different teams, different approval chains, and often a different definition of "done." Vicarius surveyed 300 IT and security leaders for its 2026 State of Vulnerability Remediation report and found that 58% of remediation activity still requires a human, and 82% of organizations can't close a vulnerability without handing it to another team.
That gap is the whole story. Not the scanning, not the discovery, not the dashboards. The gap between finding a problem and actually closing it.
Detection got faster. Remediation didn't.
Cybersecurity teams have spent the better part of a decade buying visibility. Cloud security platforms, attack surface management tools, continuous monitoring, and now AI-assisted discovery have made it possible to find more vulnerabilities, across more assets, faster than at any point in the industry's history.
The systems built to find problems improved. The systems built to fix them didn't keep pace. Vicarius surveyed 300 IT and cybersecurity leaders at companies with 500 to 2,000 employees, across financial services, manufacturing, healthcare, government, automotive, and IT services, and the pattern held everywhere. This isn't a niche industry problem. It's structural.
Only 7% have removed the human from the loop
Ask a security leader whether their remediation process is automated and most will say some version of yes. Ask them what percentage of their remediation work still requires a person to initiate, approve, deploy, or verify a fix, and the number tells a different story.
On average, 58% of remediation activity requires direct human intervention. Half of all respondents land between 50% and 74% manual. Only 7% report having eliminated human involvement entirely.
The pattern makes sense once you look at what got automated first. Discovery, scanning, and reporting were the easy parts, and teams built pipelines for them years ago. Remediation is where the automation stopped. Prioritizing what to fix, approving the fix, deploying it, and confirming it worked are still, for the overwhelming majority of organizations, jobs for a person.
The team that finds it usually can't fix it
Here's a number that should sting a little more than it does: only 18% of organizations report that the team identifying a vulnerability can consistently remediate it without looping in someone else. For everyone else, fixing something depends on a handoff, a shared ownership model, or a workflow where responsibility shifts depending on the situation.
Worse, 38% say ownership "depends" or is flatly unclear. That's more than a third of vulnerabilities entering a workflow with no defined path to resolution before anyone's even started fixing anything. Every handoff is a delay. Every unclear ownership question is a chance for the fix to stall while people figure out whose job it actually is.
Bigger organizations do somewhat better, 23% of companies with 1,000 to 1,999 employees can fully remediate without a handoff, versus 13% of companies with 500 to 999 employees. That's a real gap, but it's not a large one. More headcount helps. It doesn't solve the underlying design problem.
Leadership thinks the program is more mature than it is
Ask leadership how mature their remediation program is and 62% will say somewhat or very mature. Ask them how frontline IT and security staff would rate the same program, and 57% still expect a positive answer.
Here's the disconnect: if these programs were genuinely mature, you wouldn't expect 58% of remediation work to still require manual intervention. Mature programs, the kind that show up in a board deck, tend to have far less hands-on-keyboard involvement in the fixing itself. What's actually happening is that many organizations have built mature processes for tracking and reporting on vulnerabilities, while the underlying work of fixing them stays dependent on people.
Interestingly, directors are the most likely to call their program "very mature" at 29%, while VPs, the people closest to reporting up further, are the least likely at 13%. The leaders with the most visibility into what remediation actually looks like day to day are also the most cautious about calling it mature.
The barriers aren't technical
Only 10% of respondents say they face no major challenges in vulnerability remediation. The other 90% report friction, and the top reasons aren't about tooling.
Six of the top seven reasons are organizational or process related. Only one, insufficient tooling, is genuinely technical, and it ranks fourth. Remediation isn't slow because teams lack scanners or automation platforms. It's slow because remediation loses priority battles against outages, other projects, and business demands, and because every additional approval step adds time between finding a problem and actually reducing risk.
When a critical vulnerability shows up, the most common first move isn't remediation. It's a ticket. 42% of respondents said their primary action after identifying a critical vulnerability is creating a task in a system like Jira or ServiceNow. Only 25% deploy an automated remediation action directly from the platform. The rest send an alert for manual review or notify an asset owner and hope for the best, sometimes literally handing responsibility to someone who has no security context for the decision they're being asked to make.
What this means before you read part two
None of this is a story about bad tools or lazy teams. It's a story about design. Organizations built strong pipelines for finding problems and never finished the pipeline for fixing them, so the fixing work defaults to people, approvals, and tickets.
In the next piece in this series, we go back into the raw survey data behind this report to answer two questions the published findings didn't fully address: what did the small group of organizations that eliminated manual remediation entirely actually have in common, and does how loosely an organization defines "remediated" predict how often it gets hit by something it already knew about. The answer to the second question is more statistically decisive than we expected going in.
If your team is still routing critical vulnerabilities through a ticket and hoping it gets picked up, vRx was built specifically to close that gap, from discovery through verified remediation, in one platform instead of three.
Want to see the complete findings?
Join our upcoming webinar where we'll break down the key insights from the 2026 State of Vulnerability Remediation Report, explain what separates high-performing remediation programs from the rest, and share practical strategies to reduce manual work and close vulnerabilities faster. Register here
Frequently asked questions
What percentage of vulnerability remediation is still manual?
Vicarius's 2026 survey of 300 IT and security leaders found that 58% of remediation activity requires direct human intervention on average, with 74% of organizations reporting that more than half of their workflow is still manual.
Why can't the team that finds a vulnerability usually fix it?
In 82% of organizations, remediation depends on a handoff to another team, shared ownership, or a workflow where responsibility changes based on the situation, rather than the identifying team having consistent authority to fix what it finds.
Is vulnerability remediation more of an organizational problem or a technical one?
The data suggests organization. 90% of respondents report friction in remediation, and the top reasons, competing priorities, approval processes, and unclear ownership, are organizational rather than technical. Insufficient tooling ranks fourth among cited challenges.
What happens most often when a critical vulnerability is identified?
42% of organizations create a ticket or task as their first response, rather than deploying an automated fix. Only 25% take automated remediation action directly from their platform.
.png)
