TL;DR: Modern vulnerability management has moved beyond simply patching the highest CVSS scores. Effective remediation now requires teams to weigh exploitability, asset exposure, business impact, affected endpoints, available fixes, and whether remediation actually succeeded. As endpoints and attackers have become more distributed and faster-moving, the strongest approach is a closed loop of visibility, risk-based prioritization, remediation, and verification.
I started my career in vulnerability management selling, demonstrating, and deploying one of the early generations of enterprise vulnerability scanners. Before that, I spent several years at a major internet service provider and as a network consultant, which turned out to be the best possible training ground.
You can't run a traditional vulnerability scanner well if you do not understand network segmentation, gateways, subnets, and the difference between a credentialed and non-credentialed scan. My network background helped me understand what the scanner was actually seeing, and, just as importantly, what it might be missing.
Early vulnerability scanners were genuinely useful tools. They did the job they were designed to do: scan a network, find the CVEs, sort them by Common Vulnerability Scoring System (CVSS) score, follow the remediation guidance, and protect your assets fairly well.
For a long time, that was the vulnerability management playbook, and it worked because attackers largely played by the same rules we did.
After more than 25 years in cybersecurity, however, I have learned that finding vulnerabilities is not the same as reducing risk. Modern vulnerability management requires more than sorting findings by CVSS score. Security and IT teams must also consider exploitability, asset exposure, business impact, affected endpoints, remediation options, and whether the fix actually worked.
What vulnerability management looked like in the CVSS-first era
In the early days of vulnerability management, the process was fairly straightforward. Security teams scanned the network, received a list of known vulnerabilities, and used CVSS scores to decide what to patch first. High-scoring vulnerabilities were prioritized and patched first, attackers went after those same loud, high-scoring vulnerabilities, and everybody was reading from the same script.
This model worked reasonably well for the environments it was built to protect. Corporate assets were usually located behind a recognizable network perimeter. Most users worked from an office. Security teams could scan a defined set of IP ranges and build a remediation plan around what they found. CVSS also gave the industry a shared language. It helped teams describe the technical severity of a vulnerability and compare one vulnerability with another. That was valuable then, and it is still valuable today.
The mistake was not using CVSS. The mistake was treating a severity score as a complete measure of organizational risk. CVSS could tell us how serious a vulnerability might be in isolation. It could not tell us what that vulnerability meant inside a specific environment, where the affected machine was located, what information it contained, what it connected to, how exposed it was, or what an attacker might be able to reach from it.
That context has become central to effective vulnerability remediation prioritization.
Why CVSS scores alone cannot prioritize vulnerability remediation
Over time, the difference between severity and risk became impossible to ignore. The script that had worked for years changed. Attackers stopped caring about CVSS scores and, in some cases, started deliberately targeting the lower-scored vulnerabilities because those were the ones nobody bothered to patch. A 4.2 sitting quietly on a forgotten server became more valuable to an attacker than a 9.8 that every scanner flagged in bold red letters because everyone had already patched the 9.8.
The score matters, but so do the asset, the environment, and the attacker's options. That realization changed the questions security teams needed to ask:
Where is the vulnerable machine located?
Could an attacker chain a handful of low-severity issues together to reach something that actually matters?
What does it connect to?
Does it support a critical business function?
Is the vulnerability being actively exploited?
Is a reliable remediation available?
CVSS remains a useful starting point, but it should be an input into remediation prioritization rather than the entire decision.
When the perimeter disappeared, the vulnerability management playbook changed
We don't live behind walls. The perimeter that vulnerability management used to assume, the corporate network, the VPN, the trusted internal segment, has been dissolving for years, and remote and hybrid work finished the job. Assets are everywhere. People are everywhere. And now attackers have tools that move faster than either of the frameworks previously described.
AI-assisted exploitation tools can chain together exploit paths, 25 steps or more, in a fraction of the time it used to take a skilled human operator to map that same path by hand. That changes the math entirely. A 30-day patch window once seemed reasonably aggressive. Today, it's an open invitation. If a vulnerability is discovered and an AI-driven tool can weaponize a multistep exploit chain against it before your next patch cycle even starts. The old cadence isn't just outdated; it's actively dangerous.
This creates serious endpoint security gaps. An organization may own a device without having current visibility into its software, patch status, or vulnerabilities. A laptop may be outside the corporate network when a scan occurs. A vulnerable application may remain installed long after a team believes it has been removed or updated.
Modern vulnerability management therefore depends on continuous software vulnerability visibility. Teams need to know which assets exist, what software is installed, which vulnerabilities affect that software, and whether the endpoint can be reached for remediation.
The idea of a clearly defined boundary that security teams can periodically scan and secure has become mostly theoretical.
Security teams are left with a narrowing set of realistic choices. They can try to staff up and have someone prepared to identify and patch vulnerabilities around the clock, which is expensive and exhausting and still has gaps. Or they can find tooling that lets them detect and respond to vulnerabilities from anywhere they have an internet connection, on their own schedule, without being chained to a specific console in a specific building.
What risk-based vulnerability remediation prioritization looks like today
Risk-based vulnerability management does not mean ignoring CVSS. It means combining technical severity with the factors that determine whether a vulnerability creates meaningful risk in your environment.
A practical remediation prioritization process should consider six questions.
Is the vulnerability actively exploited?
Evidence of real-world exploitation should increase urgency. An available exploit, active attacker interest, or a vulnerability that is easy to weaponize can matter more than its severity score alone.
How exposed is the affected asset?
An internet-facing system presents a different risk than an isolated endpoint. Teams should consider network location, access pathways, privileges, segmentation, and the other systems an attacker might reach.
How important is the asset to the organization?
A vulnerability affecting a business-critical system, sensitive information, or a core operational process should receive additional weight. Technical severity does not capture the full consequences of disruption or compromise.
How many endpoints are affected?
A vulnerability present on hundreds or thousands of devices can create a very different level of exposure than the same vulnerability on one isolated machine. Breadth matters, especially when the issue affects commonly installed software.
Is safe remediation available?
Prioritization must lead to action. Teams need to know whether a patch, configuration change, software removal, isolation measure, or compensating control is available. They must also consider testing requirements, dependencies, operational impact, and the time needed to deploy the fix.
Can we verify that remediation succeeded?
Detection is only half the equation, and it is the half that gets most of the attention. The quieter and, in my opinion, more dangerous half are patches and updates that get deployed but don't actually install.
Every security team has a war story about a patch or update that was pushed but did not actually install. The dashboard showed green, and months later, an audit or incident response uncovered the exact vulnerability everyone thought had been closed. The update failed silently, applied only partially, or was blocked by a dependency.
A deployment attempt is not proof of remediation. Teams must confirm that the vulnerable software state has changed and that the exposure is no longer present.
A remediation process that cannot confirm its own success replaces honest uncertainty with false confidence. At least when you know you are uncertain, you know to check. When a dashboard tells you an issue is handled and it is not, people stop checking.
That gap between “we deployed the fix” and “the fix actually took effect” is where preventable exposure quietly persists.
How PDQ Connect and PDQ Detect close the vulnerability management loop
PDQ Connect can detect vulnerable software, prioritize what to fix, remediate affected endpoints, and verify the result from one place, which is enough for many organizations. PDQ Detect goes deeper by adding broader attack-surface visibility and more context for risk-based prioritization.
After more than two and a half decades in this field, I have landed on a fairly clear conclusion: The tools worth building a program around are the ones designed for detection and remediation that actually happen anywhere, on any timeline, with verification built in rather than assumed. Not a scanner that hands you a sorted list and calls it a day. Not a patch tool that reports success without checking its own work.
In my work as a vCISO, I have been spending more time on the exposure management side of client environments, which means I spend a lot of time evaluating whether a given stack can actually answer four questions:
Which vulnerabilities create the most risk?
Which endpoints are affected?
What can we do about them?
How do we know the remediation worked?
PDQ Connect and PDQ Detect are two of the tools I have been using to answer those questions, and I think they’re worth describing here because they support the same closed loop at different levels of depth rather than because of a feature list.
PDQ Connect covers the full closed loop for managed endpoints. It detects vulnerable software, shows which endpoints are affected, helps teams prioritize what to address, and supports patching, software deployment, and remediation across remote and local endpoints, the kind of distributed environment described earlier in this piece. Teams can then check device and deployment status to verify that the remediation worked. For many organizations, that makes Connect all they need to manage endpoint vulnerabilities from one place.
PDQ Detect goes deeper on the attack-surface and software vulnerability visibility piece. What matters to me isn’t simply that it finds vulnerabilities. Most scanners do that. It’s that Detect doesn’t treat every finding as equally urgent. Exploitability, impact, and environmental context factor into how findings get surfaced, which is the difference between a 40-page report and an actual remediation plan.
What I care about is the distance between identifying a vulnerability and confirming it’s actually gone from the affected device. PDQ Connect shortens that distance on its own, and PDQ Detect adds deeper exposure and prioritization context when a team needs it. The workflow stays the same: find the vulnerable software, understand which endpoints are affected, prioritize by risk, deploy the remediation, and check the resulting device and deployment status rather than assuming it took.
That’s the closed loop I think modern vulnerability management requires:
Detection. Prioritization. Remediation. Verification.
The industry has moved past the point where a vulnerability scanner could return a CVSS-sorted report and call the work complete. CVSS is still useful, but severity is only one part of risk. The location of the asset matters. Its exposure matters. Its business importance matters. Active exploitation matters. The availability of a fix matters. Verification matters.
The threats have moved. The endpoints have moved. The vulnerability management playbook has to move with them.
