Virtual patching or a vendor patch? Choosing a remediation path in vRx

A vendor patch addresses a vulnerability in the software. Virtual patching reduces the opportunity to exploit it without applying that update. When a patch is ready for deployment, move toward the permanent fix. When it is unavailable or still being tested, use applicable protection to reduce exposure while the patching process continues.

That choice should be part of how remediation runs, not a fresh debate for every endpoint.

For remediation teams, the practical question is what can safely reduce exposure now, what can run automatically under an established policy, and what evidence will confirm the result. A maintenance window answers when an update can run. It does not answer how the system should be protected until then.

Vicarius vRx brings patch deployment and patchless protection into the same remediation approach. The value is in connecting those options: protect an applicable workload during the delay, deploy the vendor fix through the appropriate workflow, and verify that the vulnerability has been addressed.

Virtual patching and vendor patching solve different parts of the problem

Virtual patching is a protective control rather than a change to the vulnerable source code. OWASP describes it as a way to prevent exploitation while the underlying application remains unchanged. Its guidance includes web application firewall examples, but virtual patching is not limited to one implementation. OWASP Virtual Patching Best Practices.

In vRx, vShield provides patchless protection at the application's memory level. It is designed to protect applicable exploit paths without installing a vendor update or requiring a reboot. This makes it a different mechanism from filtering web traffic at a network boundary. Vicarius vShield.

A vendor patch changes the installed software. Where it corrects the relevant flaw, it provides the route to removing that vulnerability rather than continuing to depend on a compensating control.

The distinction matters in reporting. “Protected while awaiting a patch” and “patched and verified” describe different outcomes. Both deserve visibility. Combining them into one closed count makes it harder to see which systems still depend on active protection.

For background on the underlying approach, see Virtual Patching & Legacy Software. Here, the focus is the operational transition between protection and a permanent fix.

When should the vendor patch take priority?

Use the vendor-patch route when the update applies to the affected software and can be deployed within the organization's change requirements. An available, tested fix should keep moving toward installation and verification.

vRx supports on-demand, scheduled and rule-based patch deployment. Teams can use static patch groups for a deliberate selection or dynamic groups whose membership changes with matching patch data. Those options let routine updates follow established rules instead of depending on someone to rebuild the same deployment repeatedly. Vicarius patch management.

Our recommendation is to make the recurring work policy-driven. Define the deployment scope and timing for a class of systems, then reserve individual review for exceptions: a failed compatibility test, an application dependency or a machine that did not complete the update.

This changes the team's daily question. Instead of asking which administrator will install each patch, ask which systems have not reached the intended state and why.

NIST includes verification within enterprise patch management, alongside identifying, prioritizing, acquiring and installing updates. Sending an update is therefore only part of the job. The endpoint's resulting state matters. NIST SP 800-40 Rev. 4.

What should happen while a patch is pending?

Treat the waiting period as an active remediation stage. Where patchless protection applies, it can reduce exposure while testing or scheduling proceeds.

The important boundary is applicability. A category name such as virtual patching does not establish coverage for a particular vulnerability. The protection needs to match the application, environment and exploit path involved. OWASP's framework likewise emphasizes testing and maintaining virtual patches, rather than assuming a deployed rule is effective. OWASP guidance.

Use that distinction to set an operational expectation: a delayed patch should have an identified protective action where one is available, and a clear condition for moving to the permanent fix.

The following decision table is our recommended way to distinguish those outcomes. It is not a claim that every vulnerability supports every method.

Keep the distinction visible even when execution is automated. Otherwise a temporary control can disappear into a completed-work total, while the underlying patch dependency remains unresolved.

Connect protection to automated remediation

The useful outcome is a continuous route from exposure to resolution. vShield is designed to work alongside the patch cycle: protection covers the intervening period, followed by a transition after patch deployment and revalidation. Vicarius's patchless-protection workflow.

For teams designing that workflow, the policy should establish the normal path before the next urgent finding arrives. Routine patch execution should follow the approved deployment rules. Exceptions should identify the blocked transition and its owner, rather than restart the entire process.

Consider a hypothetical application update awaiting compatibility testing. The test group receives the update through the selected deployment workflow. Applicable protection addresses the relevant exposure on systems still waiting. Once the update is cleared for the remaining scope, deployment proceeds and verification establishes which systems reached the fixed state.

An endpoint that missed the rollout remains an exception. It should not inherit the successful status of the rest of its group. A workload still dependent on protection should remain distinguishable from one running the corrected software.

This is where remediation options become operationally useful. The team can keep reducing exposure without abandoning the permanent fix or repeatedly assembling a manual response for every asset.

Measure the transition, not only the deployment

We recommend keeping two milestones separate: when effective mitigation is confirmed and when the permanent fix is verified. Reporting both makes the waiting period visible without treating mitigation as a failed patch.

For the patch itself, vRx calculates CVE coverage per asset using the difference between its current and target versions. Two machines receiving the same target version can therefore address different vulnerability sets. How vRx calculates patch coverage.

That detail supports a more useful review than a single deployment-success percentage. Ask whether the intended exposure changed on the systems in scope. Then examine the remaining exceptions: systems still waiting, systems still protected by a compensating control, and systems whose final state has not been verified.

An ambiguous success label can hide unfinished remediation. Keep the remaining work visible until the endpoint evidence supports closure.

Keep the remediation options connected

Some exposures require a configuration change or another corrective action as well as an update. Vicarius's scripting capability supports script-based remediation, giving teams another way to apply a suitable fix rather than leaving the issue in a patch-only queue.

Choose the action that addresses the exposure, automate repeatable execution within its established scope, and judge completion by the resulting state. For a longer discussion of systems that cannot be patched promptly, see how Vicarius Patchless Protection addresses unpatchable assets.

Frequently asked questions

Does virtual patching replace a vendor patch?

Usually, it serves a different purpose: reducing exploitability while the underlying software remains unchanged. Continue toward an applicable vendor fix when it becomes deployable. OWASP describes virtual patching as protection during patch availability, testing and deployment delays. OWASP guidance.

Can patchless protection and automated patching work together?

Yes. In vRx, vShield works alongside the patch cycle, supporting protection during the delay and transition after deployment and revalidation. Automated patch execution follows the team's configured deployment approach. vShield and patch management.

What should a team verify before ending temporary protection?

Confirm that the intended fix reached the affected systems and that verification supports closure of the relevant vulnerability. Do not use the planned deployment date as evidence of completion. NIST explicitly includes verification in enterprise patch management. NIST SP 800-40 Rev. 4.

What if the vendor has not released a patch?

Evaluate protective controls that apply to the actual exposure, keep their scope visible, and revisit the decision when the software or available remediation changes. A missing patch is a reason to evaluate another action, not to leave the finding without a response.

See how the remediation paths work together

Bring an application that is waiting for a patch and one ready for automated deployment. Request a vRx demo to discuss how patching, applicable patchless protection and validation can support your remediation workflow.