GravityZone's patch management add-on: Windows, macOS and Linux patches from the same agent and the same console.
GravityZone Patch Management is Bitdefender's patch management add-on. Through the same GravityZone agent and console, it scans for security and non-security patches on Windows, macOS, CentOS, Red Hat Enterprise Linux and SUSE Linux Enterprise systems and deploys them on a schedule; it offers a patch caching server and an Ignore patches option. It is not default in any GravityZone package and is licensed separately at every tier.
GravityZone Patch Management is the patch management module added to Bitdefender's endpoint protection agent. It detects missing patches in the operating system and in third-party applications through scheduled scans, distributes patches centrally and governs the deployment process with policy. It requires no separate agent, no separate server and no second management interface; inventory, detection and deployment all come together in the same GravityZone console.
The most widely misunderstood aspect of the module is licensing: Patch Management does not come by default in any GravityZone tier. On Bitdefender's official comparison page it is listed as an add-on alongside Full Disk Encryption, Email Security, Security for Mobile, Integrity Monitoring and Container Security (Bitdefender, 2026). Bitdefender TechZone documentation likewise describes the module as an add-on component installed onto systems by creating a package from the GravityZone console (Bitdefender TechZone, 2026).
It is no coincidence that patch management is positioned inside a security product. In The Forrester Wave: Endpoint Security, Q4 2023 report, 13 providers were evaluated against 25 criteria; Bitdefender was positioned as a "Leader" and received the highest possible score in 10 criteria including malware prevention, exploit prevention, identity protection, network threat detection and patch remediation (Bitdefender, 2023). As an authorized Bitdefender channel partner, Sora Yazılım handles add-on licensing, the design of deployment rings and the setup of audit reports together with you; you can review the entire product family on our Bitdefender solutions page.
Short answer: it finds missing patches, lets you decide which patch goes where and when, and runs the deployment centrally. The module is not limited to security patches; non-security patches can be brought into scope as well. Bitdefender TechZone defines the distinction clearly: security patches cover vulnerability and CVE fixes, while non-security patches cover bug fixes and new functionality in third-party applications (Bitdefender TechZone, 2026). This distinction matters in practice: some organizations prefer to let security patches go through automatically while making functional updates subject to manual approval.
The workflow can be summarized in four steps. Scanning: missing patches on the endpoints are inventoried through scheduled tasks and Maintenance Windows. Decision: which patches will be deployed is determined by policy; patches that cause problems or are not approved internally are excluded from the inventory and from the deployment scope with the Ignore patches action in the console. Deployment: patches are applied during scheduled windows. Reporting: which device is at which patch level is tracked from the console. This cycle produces a measurable answer to the question auditors ask most often: "how quickly are critical patches closed?"
On the bandwidth side, the module uses a patch caching server role. Bitdefender TechZone describes this component as an additional role that keeps all relevant patches on the local network, speeding up distribution and reducing internet bandwidth usage (Bitdefender TechZone, 2026). Patches are downloaded to a single point and endpoints pull them from there, so the same file is not fetched from the internet hundreds of times. When the caching server cannot be reached, systems download patches directly from the vendor sites; in other words, an outage of the caching server does not stop patch distribution entirely, but it does increase internet traffic. In organizations with a dispersed branch structure, placement of the caching server is one of the most concrete capacity decisions in the project.
None of them. Patch Management is an add-on licensed separately at every tier, from Small Business Security through to GravityZone Defense XDR. The claim frequently found online that "if you buy Premium or Enterprise, patch management is included" is wrong. Equally, the statement that "patch management can only be added to the upper tiers" is not correct; the add-on appears under the "sold separately" heading in all three of the small business, enterprise and MSP comparisons on the official comparison page (Bitdefender, 2026).
| Component | Included in the tier? | Notes |
|---|---|---|
| Endpoint Risk Analytics (risk management) | Standard in Business Security and above | Scores unpatched and misconfigured devices; does not deploy the patch itself |
| Patch Management | Not default in any tier — add-on | Scanning, deployment, caching server and ignoring patches come with this add-on |
| Full Disk Encryption | Add-on | Full disk encryption management through the console |
| Email Security / Extended Email Security | Add-on | Filtering at the email layer; native API integration for Microsoft 365 |
| Integrity Monitoring | Add-on | Monitoring of changes to system integrity |
| Container Security | Add-on | Docker, Podman, Kubernetes, ECS, EKS, AKS, GKE environments |
| Extended Detection (XDR sensors) | Add-on | Identity, Network and Productivity sensors come as optional sensors in the XDR tier; Cloud and Atlassian sensors are sold separately even in the XDR tier |
| Data Retention | Add-on | Listed on the comparison page with 90, 180 and 365-day options; the default retention period is not stated |
Source: Bitdefender official business products comparison page (Bitdefender, 2026). The distinction between risk analytics and patch management is especially prone to confusion: Endpoint Risk Analytics makes a missing patch visible, whereas Patch Management closes it. A deployment that only produces a risk score results in the "we knew about the risk but did not close it" picture at audit time. We describe the scope of the entry tier on our GravityZone Business Security page and the advanced threat analysis layer on our Business Security Premium page.
These two concepts are constantly confused, yet the difference is clear. Real patch management applies the fix published by the vendor to the software itself; the vulnerability disappears. Virtual patching, by contrast, does not touch the software; it blocks the traffic or request pattern that attempts to exploit the vulnerability using a rule set. The vulnerability remains in the code but becomes non-exploitable. This is exactly one of the standout capabilities of Trend Micro Deep Security: it applies virtual patching through host-based intrusion prevention (IPS) rules. Trend Micro's own documentation defines this as shielding known vulnerabilities with IPS rules until a patch can be applied, and as providing a control that many compliance regulations expect (Trend Micro Deep Security documentation, accessed 2026).
GravityZone Patch Management is the side that distributes the real patch; it does not perform virtual patching. On the Bitdefender side, the layers that stop an exploit attempt are Advanced Anti-Exploit and Network Attack Defense, but these are based on behavior and attack technique — they do not provide a signature-based shield written for a specific vulnerability. The two approaches are therefore not competitors but two layers solving different problems.
| Dimension | Real patching (GravityZone Patch Management) | Virtual patching (e.g. Trend Micro Deep Security IPS) |
|---|---|---|
| Effect on the vulnerability | The vulnerability is removed; the code is fixed | The vulnerability stays in place, the exploitation path is blocked |
| Point of application | Operating system and application binaries | Network/host traffic and request inspection layer |
| Restart | Varies by patch; a "restart endpoints if required" option is defined in the installation task | Usually not required, the rule takes effect immediately |
| Speed of rollout | You wait until the vendor publishes the patch | Can be applied as soon as the rule is published |
| Application compatibility risk | Behavioral change after patching is possible; a test ring is essential | Compatibility risk is low because the software does not change; there is a false positive risk |
| End-of-support systems | Offers no solution if the vendor no longer publishes patches | Provides a bridge for legacy systems that cannot be patched |
| Audit value | Produces evidence that "the vulnerability was closed" | Documented as a compensating control |
| Permanence | A permanent solution | Temporary protection; the real patch must be applied once it is released |
The correct design is usually this: everything that can be patched is patched, and systems that cannot be patched or for which no maintenance window can be found are protected with virtual patching, with that situation recorded as a temporary exception. If you cannot restart an old Windows server on the production line, virtual patching keeps you standing; but that is not a justification for postponing the patch indefinitely. We explain the Trend Micro counterpart in detail on our Deep Security page; and we position FortiGate firewalls, which perform the same function with IPS at the network layer across branch and headquarters traffic, as a complement.
GravityZone Patch Management supports CentOS, Red Hat Enterprise Linux and SUSE Linux Enterprise distributions in addition to Windows and macOS (Bitdefender B2B Support, 2026). Bitdefender Endpoint Security Tools, the agent the module is installed onto, covers a far wider range: from Windows 11 25H2 back to the first release of Windows 10, from Windows Server 2025 to Windows Server 2016 Core, Red Hat Enterprise Linux 7.x–10.x, Debian 9–13 and Ubuntu 16.04.x–26.04.x distributions, plus macOS machines with Intel and Apple M series processors (Bitdefender B2B Support, 2026). These two lists must not be conflated: not every distribution the agent supports is supported by patch management. The support document also notes two practical constraints: the lists of supported vendors and products are updated monthly and published as CSV files per operating system; and Bitdefender installs only digitally signed patches — an unsigned patch must be installed manually even if the product appears in the list (Bitdefender B2B Support, 2026).
On the third-party application side, it is best to be honest. None of the figures circulating online in the form of "Bitdefender Patch Management supports this many applications" appear in the vendor's official documentation. On its official page Bitdefender refers only to an extensive list of third-party applications, and the support document publishes the supported vendors and products as files without giving a total figure. For that reason we do not publish an application count on this page either. The right method is to produce your own software inventory before the project and compare it with that list — an application that is critical for one organization may not be on the list, and that gap should be known from the outset.
On the server and virtualization side, patch management should not be considered independently of the protection architecture. In dense virtualization environments the scanning load is offloaded to the Security Virtual Appliance and the agent stays lightweight; patch deployment windows are also planned according to this architecture. We cover the server-side design on our GravityZone Security for Servers page. Our DevOps and infrastructure services come into play for appliance placement, maintenance windows and automation.
In patch management the real risk is not the patch itself but uncontrolled deployment. That is why deployment is planned ring by ring: first the IT team's own devices, then a low-risk user group, then the general fleet, and critical servers last. A sufficient observation window is left between each ring. This approach is not a new invention; it is a standard change management practice that auditors expect as well.
If a patch causes problems internally, or if your business application is certified on a specific version, that patch should not be deployed. GravityZone Patch Management does this not through a separate "blacklist" module but with the Ignore patches action in the patch inventory: the selected patches are removed from the inventory and from the deployment scope (Bitdefender TechZone, 2026). Every ignored patch should be assigned an owner, a justification and a review date — this is not a mandatory field in the product but a governance rule we recommend. Otherwise the ignore list turns over time into a permanent list of vulnerabilities.
If an application behaves unexpectedly after patching, the rollback path must be defined in advance. That path is not left to the patching tool alone; a snapshot or restore-from-backup plan is designed for servers and a rebuild-from-standard-image scenario for clients. On critical systems, the maintenance window and the communication plan are as important as the patch itself. A "restart endpoints if required" option can be defined in the installation task; because it cannot be known in advance which patch will require a restart, the window plan is made accordingly. Verifying independently whether the patch was actually applied is the job of the reporting side.
No. Patching closes known vulnerabilities; zero-day exploits, logins made with stolen credentials and social engineering attacks are not prevented by patching. For that reason patch management is designed together with a detection and response layer. To see attack chains that go beyond the endpoint, look at GravityZone XDR, and for organizations without an internal team to monitor 24/7, at Bitdefender MDR.
Patch management is one of the technical measures for which evidence is most frequently requested during audits. Article 12 of Law No. 6698 on the Protection of Personal Data — KVKK, Turkey's data protection law — obliges the data controller to take appropriate technical and administrative measures to prevent unlawful access to personal data and to ensure their preservation. Leaving a known vulnerability open for a long period lays the ground for a "no appropriate measure was taken" assessment after a breach. A central patch report is a concrete defense document at that point.
Under ISO 27001, technical vulnerability management is a control heading of its own, and the auditor usually asks for three things: how vulnerabilities are detected, within what period they are closed, and why the ones left open were not closed. Patch Management produces all three — the inventory, the deployment record and the justification for ignoring. In cardholder data environments within PCI-DSS scope, critical security patches are expected to be applied within a defined period and this must be documented; for systems that cannot be patched, compensating controls must be recorded in writing. Virtual patching is precisely the compensating control that comes into play at that point.
The picture we encounter most often in Turkey in practice is this: the patch management tool has been purchased, but because deployment rings were never defined, automatic distribution has been left switched off. The product sits in the console, yet at audit time it cannot be said that "a patching process exists". On the Sora Yazılım side, our service scope aims to close exactly that gap: producing the software inventory, defining deployment rings and maintenance windows, establishing governance for the ignore list, placing the caching server and preparing reports usable for audit. The GravityZone console interface is not available in Turkish; we provide administrators with Turkish-language training, documentation transfer and Turkish support when something goes wrong.
Share how many endpoints and servers you have, which critical applications you use and how your current patching process works; let us work out together how much of your inventory the GravityZone Patch Management add-on covers and for which systems you will need a compensating control such as virtual patching. For add-on licensing, deployment design and audit reporting, request a quote from our contact page; we plan an evaluation deployment on a pilot group.
In regulated institutions the question the auditor asks is not "do you patch" but "how quickly was the critical patch closed and what is the justification for the ones that were not". The scheduled scan inventory, the deployment record and the ignore justifications make all three of these documentable. We establish as a process, together with you, that every ignored patch is assigned an owner, a justification and a review date.
Random restarts are unacceptable on patient admission and imaging workstations. Patch deployment is carried out in windows defined outside outpatient hours, critical devices are placed in a separate group and patched in the last ring. On workstations where the medical device manufacturer mandates a specific version, the relevant patches are placed on the ignore list and compensating controls are documented.
On a production line running twenty-four hours a day, seven days a week, some servers cannot be restarted; in that case real patching alone is not enough. Systems that can be patched are patched ring by ring, a compensating control such as virtual patching is planned for those that cannot, and this exception is recorded with a time limit. An open-ended exception turns over time into a permanent list of vulnerabilities.
Downloading the same patch separately from the internet in dozens of branches consumes line capacity. The patch caching server downloads the patch to a single point and distributes it to endpoints from there. When the caching server cannot be reached, systems continue to download patches from the vendor sites; this behavior must be factored into capacity planning from the start.
For the technical vulnerability management control, the auditor asks how vulnerabilities are detected, within what period they are closed and the justification for those that are not. A central patch report produces all three outputs. In laboratories and shared-use computers, bulk patching at the start of the term and scheduled, less frequent windows during the term are preferred.
In IT teams of one or two people, operating a separate patch management tool is not sustainable in practice. Because Patch Management runs through the same agent and the same console, it does not create a second infrastructure; protection policies and patch policies are managed from the same place. Once the deployment rings have been set up and tied to scheduled tasks, the process largely runs itself.
Organizations that must close known vulnerabilities through a documentable process, that do not have the resources to operate a separate patch management tool and that already use the GravityZone agent; finance, healthcare, public sector, education, manufacturing and multi-branch retail businesses subject to KVKK, ISO 27001 and PCI-DSS audits.
Opens the vendor's original technical documentation and product page in a new tab.
Bitdefender — GravityZone Patch Management →GravityZone's entry tier for SMBs: one agent, one console, endpoint protection without EDR.
DetailsFull EDR on top of EPP: cross-endpoint correlation, threat hunting and one-click remediation.
DetailsThe mid tier that adds HyperDetect, cloud sandboxing and attack forensics on top of Business Security.
DetailsGateway plus Microsoft 365 API-based email protection against phishing, BEC and malicious attachments.
DetailsComplementary approach through virtual patching
DetailsBitdefenderThe entry tier the add-on is built on
DetailsBitdefenderProtection architecture on the server and virtualization side
DetailsBitdefenderDetection layer for attacks patching cannot close
DetailsSora Yazılım handles licensing, deployment, training and ongoing management — all from a single team.