Vulnerability management (VM) has been with us for roughly three decades, but it did not start as the sophisticated discipline we recognize today. In the late 1980s and 1990s, it was largely a manual exercise: find the flaw, track the affected systems, and figure out how to patch them.

The turning point came in 1999, when MITRE introduced the Common Vulnerabilities and Exposures (CVE) system, giving the industry something it badly needed – a common language for identifying and tracking software vulnerabilities.

That standardization set the pattern for what came next: an industry exceptionally good at cataloging security problems, but much less effective at driving them all the way to resolution.

To assist in these efforts, vulnerability assessment (VA) platforms were brought to market. As the speed and volume of threats increased, it quickly became apparent that assessment alone would not be enough. Eventually the market began clamoring for genuine enablement solutions; something that would not only help operators identify and tracks vulnerabilities, but systematically address them.

Security vendors heard the call and responded by announcing a new era of products that would go beyond traditional assessment to support more end-to-end vulnerability management. Since then billions have been invested and a lot of ink has been spilled, but the promise still hasn't really been delivered. 

To be clear, vulnerability tooling has not stood still. Vendors have moved beyond basic CVSS-driven scanning, adding threat intelligence and exploitability data, asset criticality and business context, risk-based prioritization, attack-path analysis, remediation guidance, ITSM integrations, automated ticketing, ownership mapping, remediation projects, SLA tracking, exception workflows, patching integrations, and post-remediation validation.

These are meaningful advances, but most improve the information and coordination surrounding remediation rather than remediation itself. They help security teams determine what matters, who should address it, and whether it was eventually fixed. What they rarely provide is a genuinely closed operational loop for planning, testing, executing, validating, and, when necessary, rolling back changes across production environments.

The product packaging says VM, and that's echoed in the process language and data standards. But not in the enablement.  Fundamentally, it's still all about findings. As an industry, we need it to be about fixings.

The Chasm Between VA and VM Is Vast

The early vulnerability assessment era solved a real problem. Enterprise networks were growing faster than operators could inspect them manually. Scanners could interrogate hosts, identify missing patches and insecure services, and create a common inventory of technical weaknesses.

The Common Vulnerabilities and Exposures (CVE) program was launched to give different tools and teams a shared language for referring to the same vulnerability. That was an important interoperability milestone, but CVE was designed to identify and catalog vulnerabilities, not to change the state of the affected device.

The next step was supposed to be management: prioritize the exposure, determine the right corrective action, apply it safely, verify the outcome, and maintain the result.

The operating guidance was clear. In 2005, NIST described patch and vulnerability management as a systematic, accountable, and documented process that included testing the effectiveness of the program. 

The promise was never simply “find more vulnerabilities.” It was to build a repeatable system for reducing exposure in production without creating a different operational problem.

That transition never fully arrived. Instead, security vendors kept improving the assessment layer. Coverage expanded. Risk scoring became more contextual. Asset inventories became more detailed. Threat intelligence added exploitability signals. Security teams gained better ways to group findings and focus on known exploited vulnerabilities.

Those are all helpful, but they're not the same as management. The dominant workflow still looks like this:

Detect → Prioritize → Ticket → Wait

This model also creates a measurement problem. The traditional approach to vulnerabilities treats workflow progress as a proxy for security-state change: a ticket is assigned, a patch is deployed, a command executes, or a finding disappears from a scan. Each is evidence that something happened, but none independently proves that the affected asset reached the intended safe state. Management begins when the outcome, not merely the activity, can be verified.

A scanner finds a vulnerable package. A platform assigns a score. A ticket goes to an IT queue. An application owner is asked whether the change is safe. A change window is negotiated. A script or patch is prepared. Someone applies it. A dashboard later reports that the ticket is closed.

At every handoff, the action imperative becomes more opaque:

• What will change if we remediate it?
• Which applications, services, policies, or users depend on the current state?
• Can the change be staged or reversed safely?
• Did the device reach the intended state?
• Will the next reboot, image deployment, policy refresh, or exception reintroduce the exposure?

In lieu of clear answers to those questions, remediations languish in validation and coordination limbo. And that ultimately results in problems being inventoried far faster than they can be resolved - or put simply, persistent risk exposure.

The Backlog Bears An Execution Gap

The numbers reflect the problem. Verizon’s Data Breach Investigations Report found that exploitation of vulnerabilities accounted for 20% of breaches as an initial access vector, a 34% increase from the previous report.

The issue is not that security teams lack visibility into known vulnerabilities. Even when organizations can identify and prioritize urgent exposures, the change path remains difficult.

BitSight’s analysis of more than 14 million entities found that 35.3% had an externally detectable vulnerability listed in CISA’s Known Exploited Vulnerabilities catalog. Only 40% of KEV instances were remediated by the applicable CISA deadline.

Known exploitation improves prioritization. It does not remove the operational barriers to remediation.

That distinction becomes more consequential as identification accelerates. Anthropic reports that approximately 50 partners used Claude Opus 4.6 Preview to find more than 10,000 high- or critical-severity vulnerabilities across systemically important software. As detection scales, remediation capacity does not automatically scale with it.

The emerging constraint is therefore not finding or ranking vulnerabilities. It is converting security knowledge into safe, verified changes quickly enough to keep pace.

The Most Stubborn Bottlenecks Are Operational, Not Informational

The reason this problem persists is that changing production systems safely is much harder than describing what is wrong with them.

1. The finding does not describe the change surface

A vulnerability scanner can identify a package version, service, port, or configuration condition. It usually cannot explain the full operational consequence of changing that condition on a specific endpoint.

The risk is just around the disease of the vulnerability, but the cure of the change too. And the older the environment, the more likely that an insecure setting is also supporting something the business still needs.

A patch may interact with a legacy application, while disabling a service may interrupt a required workflow. Changing a protocol may affect an old device, a vendor integration, or an operational technology dependency.

These relationships are rarely captured in vulnerability inventories, so operators often discover the blast radius only when they try to act on the finding. This is why extensive sequencing and validation are needed before any change can be deemed safe.

2. Security can identify the issue without having device-level control

Security teams are often responsible for identifying exposure while IT or operations owns the system that must be changed. The vulnerability management platform may identify the required state, but that does not mean it has the authority or technical mechanism to establish it.

That distinction becomes more consequential outside standard workstations and servers. Network devices, appliances, legacy systems, and operational technology frequently have different management planes, access controls, and change requirements.

A program cannot promise remediation at scale if it can identify the required state but cannot reliably establish it on the affected device.

3. "Closed" does not always mean remediated

A ticket can be closed without the effected assets reaching the intended states. A script can execute without changing the intended value. A patch can install while the vulnerable service remains active pending a restart. An agent can report success against an asset that is offline, mis-scoped, or subsequently drifts back into exposure.

These are forms of execution telemetry: evidence that an action was attempted or a workflow advanced. They are not necessarily outcome evidence: evidence that the vulnerable condition was removed and the intended security state now exists.

Even a clean rescan has limits. It may confirm that a detectable condition disappeared without establishing why it disappeared, whether the required control is actually in force, or whether that state will persist.

For effective vulnerability management, closure should therefore require evidence of the resulting security state, not merely evidence that the remediation process ran.

4. Remediation does not guarantee persistence

Even successful remediation may be temporary. Configuration drift, software updates, policy changes, user actions, and management tools can reintroduce previously corrected conditions.

Closing a vulnerability therefore cannot be the end of the process. The desired state must be continuously verified, with recurrence detected and corrected before it becomes another backlog item.

5. Remediation crosses organizational boundaries

Vulnerability management rarely controls every system it identifies as exposed. Security may find and prioritize the issue, while endpoint, infrastructure, application, network, or operations teams own the change.

Every handoff introduces delay, competing priorities, and another opportunity for remediation to stall. At scale, this coordination burden becomes part of the execution gap itself.

True Management Starts With a Trustworthy State

Effective vulnerability management depends on an accurate understanding of the state of each asset. A vulnerability finding alone is not enough. The system must know what is installed, how it is configured, which controls are active, what dependencies exist, and whether the asset is actually reachable and manageable.

That requires a continuously maintained view of:

• Hardware and software inventory
• Operating system and application versions
• Configuration and security-control state
• Services, ports, protocols, and exposed functionality
• Asset ownership and business context
• Management status and connectivity
• Dependencies that may affect remediation decisions

This state model provides the context needed to determine not simply whether a vulnerability exists, but what safe state should replace it.

The objective is no longer to move a finding through a workflow. It is to move an asset from a known vulnerable state to a known safe state, then verify that the intended state was actually established.

True vulnerability management therefore requires more than accurate detection and prioritization. It requires a trustworthy model of current state, a defined target state, and evidence that the transition between the two succeeded.

To get there, you need to know whether a corrective action can be safely applied to a specific asset, what it might affect, how to execute it with appropriate controls, and how to validate the outcome, and how to ensure it sticks.  

An exposure with high severity and low change viability should not disappear into an exception queue. It should receive a controlled remediation path: a compensating control, a staged rollout, an isolation step, a dependency review, or an approved risk decision with a clear expiry.

With that we're not only able to pave a path to finally transition from vulnerability assessment to true vulnerability management - but to take it one step further. Because in the era of AI threats, even end-to-end management isn't enough.

What we really need is prescriptive and proactive exposure maintenance.

Capability	Vulnerability assessment	Traditional vulnerability management	Prescriptive and proactive maintenance
Primary question	What is wrong?	What should we work on first?	What state should this asset be in, and how do we keep it there?
Main output	Findings and evidence	Priorities, tickets, and status	Governed state change, validation, and enforcement
Unit of work	Vulnerability or scan result	Finding and owner	Asset, dependency, corrective action, and desired state
Closure signal	Finding reported	Ticket closed or scan result changed	Exposure removed, outcome verified, state sustained
Human role	Interpret findings	Coordinate remediation	Set policy, approve exceptions, and govern autonomy

What Prescriptive and Proactive Maintenance Look Like

Traditional vulnerability management is often event-driven. A new CVE appears, a scan finds it, a report is generated, and a team begins a project to address it.

Prescriptive and proactive maintenance continuously asks whether the environment is in the intended condition and determines the safest available action when it is not.

That model has six main requirements:

1. Model: Maintain a trustworthy view of assets, owners, criticality, dependencies, current state, and desired state.
2. Detect: Identify vulnerabilities, insecure configurations, exposed services, drift, and the assets that make the exposure meaningful.
3. Validate: Determine whether the proposed remediation is appropriate and safe for this specific asset. Account for its current state, dependencies, compatibility, business context, and change constraints before execution.
4. Remediate: Apply the patch, configuration change, application control, or compensating measure at the device level, with staged rollout and rollback where required.
5. Enforce: Continuously monitor the desired state and reapply policy when drift, redeployment, or an unauthorized change reopens the exposure.
6. Prove: Establish that actions taken produced the intended security outcome. Verify that the vulnerable condition is no longer present, that the target state was actually established, and that it persists after the change.

The objective is not a single successful intervention. The objective is a reliable operating condition.

Execution requires more than a good action library. It requires least-privilege execution, separation between policy authorship and approval, protected break-glass access, immutable action records, and explicit limits on what automation can touch.

And critically, the underlying automation, should not be related to in a binary manner. Every remediation should be classified by confidence, blast radius, reversibility, dependency uncertainty, and business criticality.

Autonomy should be earned through evidence, not enabled through optimism.

Remediation condition	Recommended action
High confidence, low blast radius, repeatable, and reversible	Automatically apply within a defined scope
Known impact, moderate blast radius, and staged rollout possible	Canary, health check, then human-gated deployment
Unknown dependencies or high business impact	Require testing, approval, and explicit rollback conditions
Patch unavailable or operational risk too high	Apply a compensating control, restrict, or isolate
No acceptable action yet	Time-boxed risk acceptance with owner, evidence, and review date

This should clearly delineate which decisions require judgment, which actions can be bounded by policy, and what evidence is required before autonomy expands.

The safety mechanics should be explicit: scoped targets, dry-run mode, canary deployment, health checks, approval thresholds, rollback triggers, and an immutable audit trail.

Beyond Patching

It should be noted that patching is just one method of remediation. Patching is action-specific, while remediation is outcome-specific. Every patch serves as a remediation, but not every remediation takes the form of a patch. As such, patching, hardening, application control, segmentation, isolation, and configuration integrity all need to be a part of the conversation.

Patching is appropriate when a patch is available, compatible with the environment, operationally safe, and the most effective means of removing the condition that creates the exposure. But that won't always be the case.

When it's not, remediation efforts should pass through the following progression: 

• Harden the state: Change the configuration, disable an unnecessary feature, enforce least privilege, or prevent unauthorized execution.
• Restrict the exposure: Remove an exposed path, limit network reachability, constrain access, or reduce the vulnerable service’s privileges.
• Isolate the asset: Segment the system, quarantine the workload, or separate it from sensitive environments until a durable correction is possible.
• Apply a compensating control: Use application control, filtering, virtual patching, enhanced monitoring, or another control that reduces the likelihood or impact of exploitation.
• Accept residual risk temporarily: If no proportionate action is available, document the business rationale, remaining exposure, compensating controls, accountable owner, and expiration date.

That last item must be taken with due caution and context. Risk acceptance is not remediation. It is a governed decision to tolerate residual exposure for a defined period while the organization works toward a better outcome or determines that the risk is proportionate to the business context.

To ensure that actions taken support the desired outcomes, be sure to ask these four questions:

1. Did the change remove or materially reduce the exposure?
2. Was the actual device, service, or control state changed as intended?
3. Can the result survive reboot, redeployment, policy refresh, and ordinary configuration drift?
4. What evidence shows that the control remains effective over time?

Ultimately, security doesn't care about the mechanism used to make the change; it care that exposure was reduced, the resulting state was verified, and that state persists.

The Coming Correction

The industry should stop rewarding vulnerability tools for producing better descriptions of work that someone else must perform.

When evaluating a platform, ask these questions:

• Is the asset inventory authoritative enough to support safe action?
• Can the platform change the relevant state at the device level?
• Can it explain dependencies and expected operational impact before the change?
• Can it select a patch, hardening change, restriction, isolation step, or compensating control based on context?
• Can it prove that the intended security condition was reached?
• Can it continuously re-enforce that condition when the environment changes?
• Are automation privileges, approval paths, rollback, and recovery governed?
• Can it trace recurrence back to the image, policy, package, dependency, or supplier that recreated the exposure?

If the answer is no, the platform may still be valuable. It may provide assessment, prioritization, reporting, or workflow. But it is not delivering the full promise of vulnerability management.

The architecture implied by this model requires more than another assessment layer. It requires an action plane capable of translating security intelligence into controlled state changes at the device and configuration layer, then validating and sustaining the result.

Remedio, for example, is built around that action plane. Its purpose is not to add another layer of findings. It is to connect vulnerability intelligence with safe, context-aware, device-level correction; dependency awareness; deterministic validation; rollback; recovery paths; and continuous enforcement.

The suite should not be understood as a replacement for every code analyzer, cloud control, or software supply-chain system. Its role is to operationalize the intelligence those systems produce by turning it into controlled change at the device and configuration layer, then sustaining the result.

This also changes what vulnerability management should measure. Metrics such as ticket closure and mean time to remediate primarily describe workflow throughput. They can show how quickly work moved without proving how quickly exposure was actually removed.

A management model centered on security state requires different measures: time to verified safe state, time to persistent safe state, recurrence rate, change-failure rate, and enforcement coverage. These metrics measure whether the intended outcome was achieved, how reliably it was achieved, and whether it endured.

The goal is not simply to close more tickets. It is to create fewer exploitable states, reduce the time they remain available, and prevent them from returning.

Systematically operationalized vulnerability management changes the state and proves it stayed changed.

It determines the appropriate corrective action for the affected asset, validates that the change is safe, executes or enforces it, verifies that the vulnerable condition was actually removed, and detects when that condition returns.

That is the transition vulnerability management has yet to complete: from managing findings and remediation workflows to managing the security state of the assets themselves.

The measure of success is no longer whether a vulnerability was found, prioritized, patched, or closed. It's whether the asset reached a verified safe state, and whether it stayed there.

---

---

FAQ

About Author

Ilan Mintz

Full-stack Marketer

A full-stack marketer with over 10 years of experience helping startups build brands for global success, Ilan's a firm believer in the transformative power of a well-crafted story. Ilan excels at generating human connection to and through technology and relishes opportunities for creative thinking and problem-solving. Ilan’s favorite things include his family, obscure facts, philosophy, gardening, and believing that this year will finally be different for the Minnesota Vikings.