Bitdefender GravityZone Patch Management: Setup, Limitations, and What Breaks

TL;DR

Bitdefender Patch Management is a GravityZone module that pushes Microsoft Updates and a curated catalogue of around 150 third-party apps from one console. Good enough for most SMEs, saves the cost of a separate patcher, reports cleanly against cyber-insurance questions on patch cadence. Not a replacement for Intune on a Windows-only fleet or a dedicated patcher on vertical-app-heavy estates. Niche apps are slow to land and reboot orchestration on file servers needs care.

Patch Management is one of the most under-used modules in GravityZone. Clients buy Business Security Premium or EDR, get patching included, leave it switched off because nobody tuned it. We audit them three years later and find unpatched Chrome from 2023.

This is the setup guide and what the module does not do.

What does GravityZone Patch Management actually do?

It inventories every application on every managed endpoint with the BEST agent installed. OS version, build, installed third-party apps. You cannot patch what you have not catalogued, and most SMEs we audit have no central inventory at all.

It then scans each endpoint against Bitdefender’s vulnerability database. That database covers Microsoft Updates (including Patch Tuesday content the same day Microsoft ships it) and a curated list of around 150 third-party apps. The dashboard shows open CVEs sorted by CVSS score, with affected-endpoint counts.

Finally it deploys patches according to the policy you set. Auto-approve a whole category, auto-approve only “Security” or “Critical”, stage to a pilot ring, exclude specific KBs that break line-of-business apps. The policy engine is per-group: aggressive on developer laptops, conservative on the file server.

The module also keeps a deployment history per endpoint per patch. That is the artifact a cyber-insurance auditor or a SOC 2 reviewer wants. “We patch within 14 days” is a claim. Deployment history is the evidence.

How does it compare to WSUS / Intune patching?

WSUS has been deprecated since 2024 and Microsoft is no longer investing in it. It still works for Microsoft Updates on Windows. Microsoft updates only, no third-party coverage, UI from 2008. Most SMEs we see running WSUS abandoned it years ago after it became a graveyard of pending KBs nobody approved. If you are still on it, the writing is on the wall. Plan your move.

Intune (Windows Update for Business via Intune policies) is the modern Microsoft answer, and it is good for Windows-only fleets where Intune is already paid for via M365 Business Premium or E3. It handles quality and feature updates with deferral rings, expedited security patches, and Microsoft-catalogue drivers. What it does not do natively is third-party app patching. For Chrome, Firefox, Reader and 7-Zip you bolt on Winget, the Microsoft Store, or a third-party patcher. Intune Suite added patch capabilities in 2024 but stays Microsoft-first.

Bitdefender sits between the two.

Setting up the policy: what to switch on

The default policy is sensible but conservative. Five settings actually matter.

Patch scan schedule: daily. Leave it daily. Scans are cheap and catch new CVEs published overnight.

Patch deployment schedule: default is “do not deploy automatically”. Change that. Set automatic deployment for Security and Critical, with a daily window during business hours for laptops, and a weekly window for servers (Saturday or Sunday, after hours).

Patch categories to auto-approve: “Security” and “Critical” without exception. “Important” is reasonable for laptops, debatable for servers. “Low” and “Optional” need manual approval. Feature updates go through a pilot ring. Microsoft 24H2 broke enough Bitdefender deployments in 2025 that we now treat all feature updates as pilot-first.

Vendor and app exclusions: build a deliberate exclusion list. Common entries include any line-of-business app whose vendor specifies a particular runtime (an ERP requiring .NET 4.7.2, an accounting package requiring Acrobat Reader DC that breaks on the 64-bit version). Document why each exclusion exists.

Reboot policy: prompt the user (with a deferral cap of 1, 4 or 24 hours) or force after a window. Laptops prompt; servers force inside a maintenance window with a snapshot first if virtualised. The “no reboot” option exists; we have never recommended it. An unrebooted patch is not a deployed patch on Windows.

Policy lives under Configuration Profiles → Update. Build per ring. Pilot first (10–20 endpoints across the actual OS mix), watch for a week, promote group by group.

A non-obvious gotcha: BEST policies and Update policies are separate objects. You can have a perfectly tuned BEST policy applied to a group and forget to apply the Update policy to the same group. Audit assignments.

What apps does it cover?

This is the most important question and the answer is: a curated subset.

The Microsoft side covers everything Microsoft publishes through Windows Update: quality updates, .NET, Visual C++ Redistributables, Office (click-to-run), Edge, OneDrive, Teams, the lot. If Microsoft ships it through Windows Update or the Update Catalog, GravityZone deploys it.

The third-party catalogue is curated. The full list is not published, but apps reliably covered include:

• Browsers: Chrome, Firefox, Opera
• PDF: Adobe Acrobat / Acrobat Reader DC, Foxit Reader, Foxit PDF Editor
• Compression: WinRAR
• Media: VLC, GOM Player, iTunes
• Communication: Zoom, Microsoft Teams (Machine-Wide Installer / New Teams), Slack, Cisco WebEx (Meetings and Teams)
• Remote access: TeamViewer
• Dev tools: Notepad++, Git for Windows, Python, Node.js
• Runtimes: Java (Oracle JDK/JRE, Eclipse Adoptium Temurin, Microsoft OpenJDK, AdoptOpenJDK)
• Utilities: PuTTY, WinSCP, GIMP, Audacity

What it does not cover: niche line-of-business apps, most accounting and ERP suites, most CAD and engineering software, most security and pentesting tools, custom internal applications. If you run Sage 300, Pastel, Buildsmart, AutoCAD, SolidWorks, MATLAB or any specialised vertical app, GravityZone will not patch it. Those stay a manual job, an MSI repackage in Intune, or a dedicated patcher’s coverage.

macOS third-party patching exists but is significantly thinner. Linux patching defers to the distribution’s package manager (apt, yum/dnf, zypper); GravityZone’s role is visibility and trigger, not the patch logic.

What about reboot and downtime windows?

Reboot orchestration is where most patch deployments fall over.

Laptops are the easy case. Set a 4-hour deferral cap with a maximum of three deferrals before forced reboot. Most users reboot the second or third time it asks; the minority who never reboot get the forced reboot at the next maintenance window. Communicate this. A note explaining that “from next month, your laptop will reboot every second Wednesday at 1pm if you have not rebooted it yourself” prevents the support tickets.

Servers are harder. The pattern that works:

• Group servers into reboot waves so a single failure does not take out a whole tier.
• Take a hypervisor snapshot before the patch window (VMware, Hyper-V, Proxmox).
• Stage the deployment for after-hours on a maintenance window the business has accepted.
• Force the reboot after the patch but only inside the window. Outside, queue.
• Verify services come back. GravityZone reports “patched and rebooted” but does not validate that SQL Server started or that the file shares are reachable. That is your monitoring tool’s job (PRTG, Datadog, Zabbix).

The most common failure: a domain controller, file server or SQL server with auto-reboot enabled rebooting mid-workday because somebody forgot to apply the maintenance-window policy to that specific group. It is not a product flaw; it is a group-assignment flaw. Audit groups quarterly.

File servers deserve a specific note. A reboot during business hours on a Windows file server with active SMB sessions is a productivity event for the whole company. Force-reboot policies on file servers should always have a maintenance window and an “abort if active sessions over N” check. GravityZone does not enforce that natively; you script it via BEST pre-reboot hooks or you accept the risk.

Real-world limitations

After three years of running this in production, here is what bites.

The third-party catalogue is curated and slow to add niche apps. Already covered, but worth repeating because it is the most common reason clients add a second patcher. If your stack is Chrome, Acrobat, Zoom and a couple of dev tools, GravityZone has you covered. If your stack includes specialised vertical apps, plan for the gap.

Sometimes a vendor MSI behaves better than the GravityZone-pushed update. We have seen this with Java (the Oracle MSI handles legacy compatibility better in edge cases), Acrobat Reader (the Adobe enterprise installer exposes options the GravityZone update does not), and Zoom (the MSI handles per-user vs per-machine more cleanly). For these apps, exclude them from GravityZone patching and deploy from your software-distribution path instead.

Patch reporting can be misleading. The “patch compliance” percentage is calculated against the apps GravityZone knows about. If Sage is installed on every endpoint and is not in the catalogue, it does not factor into the compliance score. You can be at 98% on the dashboard and have a critical unpatched ERP. Use the inventory view, not just the compliance view.

Patch rollback is limited. If a patch breaks something, your options are: uninstall the patch (works for Microsoft Updates, hit-or-miss for third-party), restore from snapshot (the right answer for servers), or reinstall the previous app version manually. Keep your own MSI archive of vendor installers for the apps that matter.

Bandwidth on small offices with thin links is a problem during Patch Tuesday. The Relay role (a BEST endpoint as a local update cache) fixes it. Designate one workstation per branch as a relay; the office downloads each patch once instead of per-endpoint. Five-minute change. Often not done.

When you should use Patch Management vs a dedicated tool

Use GravityZone Patch Management when:

• Your stack is mainstream: Windows, macOS, common third-party apps.
• You already pay for Business Security Premium or EDR.
• You want one console for AV, EDR, FDE and patching.
• Compliance asks “do you patch within N days” and you need the audit trail.
• You do not have a dedicated sysadmin to run a separate patcher.

Look elsewhere when:

• You run a heavily regulated environment with strict patch SLAs (financial, healthcare). A dedicated tool with deeper reporting and approval workflows is worth the extra licence.
• Your stack is heavy on vertical apps. Dedicated patchers carry catalogues two to four times the size of Bitdefender’s, with explicit support for hundreds of vertical apps.
• You are 100% Windows on M365 Business Premium. Intune Windows Update for Business is already paid for, and integration with Conditional Access and Defender is tighter than any third party can match.
• You need patch automation across Linux at scale. Ansible, Salt, or a dedicated Linux-aware patcher will beat GravityZone on RHEL and Ubuntu fleets above 50 servers.

For most SMEs: start with GravityZone Patch Management, instrument it well, and add a dedicated patcher only when you can point to a specific gap that is actually hurting you. Two years of GravityZone audit trails is worth more to a cyber-insurance underwriter than a shiny new dedicated-patcher deployment with a clean dashboard and no history.

For the broader buying decision across GravityZone tiers, see our GravityZone buying guide and the cross-platform deployment walkthrough. For mixed-fleet patching strategy combining Bitdefender with Intune on Windows and scripted approaches on Linux, that is the kind of thing we cover in Professional Services engagements.

Get a free patch posture audit

Book a free patch posture audit. We look at three things and send you a written report.

1. Current patch coverage: what is patched, what is not, and the median age of the longest-overdue critical patch on each tier of endpoints.
2. Third-party app gaps: which apps in your fleet are not in the GravityZone catalogue, their patch status, and how to close the gaps without buying a second tool.
3. Reboot policy review: whether reboot windows fire, whether servers reboot safely, and whether the maintenance-window policy is applied to the groups you think it is.

The audit takes about a week of clock time and a couple of hours of your team’s. The report is yours whether you engage us further or not. Email support@osh.co.za or use the form below.