IT Glossary · Cybersecurity
Virtual patching is a security control that blocks attempts to exploit a known vulnerability before the traffic reaches the vulnerable software, without changing that software. An intrusion prevention rule inspects incoming traffic for the specific exploit pattern of a given CVE and drops it, so an unpatched server behaves as though it were patched — for that attack — while you wait for a maintenance window to install the real fix.
The problem virtual patching solves is timing. A vendor publishes a patch, attackers publish an exploit within days, and your change advisory board schedules the reboot for the end of the month. Between those two dates the server is exposed and there is nothing the patching team can do about it. Virtual patching closes that window by moving the defence off the vulnerable host and into the inspection layer: a rule written for that specific CVE watches traffic to the host and blocks requests carrying the exploit. It runs either as an agent on the server itself, inspecting traffic before it reaches the application, or on a network device in front of it. Crucially it is not a substitute for patching. The vulnerability is still present, the rule only covers the exploit patterns it knows about, and a variant attack may slip past. What it buys you is time — measured in weeks — which for legacy systems is often measured in years, because some applications will never be patched. That is the second real use case: end-of-life operating systems and vendor-locked applications where the supplier has stopped shipping updates, or where an upgrade means recertifying a whole regulated application. Virtual patching keeps those systems defensible while a replacement project runs.
Indian IT teams run more unpatchable infrastructure than they like to admit. Manufacturing lines with Windows-based HMIs the OEM will not certify on a newer OS, hospital systems tied to specific application versions, BFSI applications where any change triggers a re-audit, and the perennial Windows Server 2012 box that one critical department still depends on. Patch windows are also genuinely hard when a plant runs three shifts or a hospital never closes. Virtual patching is the control that makes those realities survivable: it lets the security team demonstrate mitigation for a known CVE to an auditor without the operations team having to reboot a production line. For CERT-In directions and internal audit, an IPS rule mapped to a CVE with logs showing blocked attempts is real, defensible evidence of compensating control. It is also why virtual patching, rather than anti-malware, is usually the feature that justifies a server security product in an Indian mid-market quote.
Related terms: IPS, CVE, Patch Management, Vulnerability Shielding, Compensating Control, Zero-Day, Deep Security, Host-Based Firewall
No, and treating it as equivalent is the classic mistake. The vulnerable code is still on the server; virtual patching only blocks the exploit traffic it recognises on the path it inspects. An attacker with local access, or one using a variant the rule does not match, is unaffected. Use it as a bridge to a real patch or as a compensating control where no patch will ever exist — not as a reason to stop patching.
Barely, when configured properly. Modern implementations run a recommendation scan first and enable only the rules relevant to what is actually installed on that host, so a typical server runs a few dozen rules rather than thousands. The measurable overhead is normally low single-digit CPU. Performance complaints almost always trace back to blanket rule sets applied without a recommendation scan.
It can, which is why detect-only mode exists. A rule occasionally matches legitimate traffic that resembles an exploit pattern — unusual API payloads are the common culprit. The safe rollout is to run new rules in log-only mode for a week, review what they would have blocked, then switch to prevent. Skipping that step on a production payment system is how security tools acquire bad reputations.
It is a standard capability in host-based server protection — Trend Micro is the best known for it, through Deep Security and now Server & Workload Protection, and it is also found in Palo Alto, Check Point and other IPS-capable products, as well as in web application firewalls for web-layer flaws. Trend's implementation is the one most often cited in Indian deals because of its rule coverage for older Windows and Linux versions.
For a patchable system, until the next maintenance window — weeks, not quarters. For an end-of-life system with no available patch, indefinitely, but only alongside other controls: network segmentation so the box is not reachable from everywhere, tight access control, and a documented replacement plan with a date on it. A virtual patch that has been the only control on a critical system for three years is a risk acceptance nobody has revisited.
Get a Trend Micro quote priced in INR with GST invoice — we size the licence, deploy it, and can run the console for you.