Deploying Bitdefender GravityZone Across Windows, macOS and Linux

TL;DR. A clean GravityZone deployment is the same job on every OS: build the right package in Control Center, get it onto the endpoint, confirm the agent reported in. The detail is where the difference lives. Windows is easy. macOS needs a system-extension approval, and missing that window is the most common rollout failure we see. Linux needs matching kernel headers and SELinux not actively fighting you. Verification isn’t optional on any of them.

Bitdefender GravityZone is a single-agent platform (Bitdefender Endpoint Security Tools, usually shortened to BEST) that runs on Windows, macOS and Linux from one console. The product is genuinely cross-platform. The deployment has three different shapes, because the operating systems have three different security models. This is the field guide we use on every rollout.

For broader strategy (tier, modules, fleet shape), start with the Bitdefender page. For tier selection, the GravityZone Buying Guide covers the SKU matrix.

What you need before you start

Three things, in order. Skip any one of them and the rollout goes sideways inside the first week.

1. Control Center access with the right role. Deployment work happens in the Bitdefender GravityZone Control Center (cloud tenant: gravityzone.bitdefender.com). You need at least Network Administrator on the target company. The default Reporter role cannot create installation packages, which is a fun way to lose ten minutes.

2. A deployment package built for the target group. Packages live under Network → Packages. Each one binds an installation policy, an endpoint group, the modules you want enabled (Antimalware, ATC, Content Control, Firewall, Patch Management, Full Disk Encryption, EDR) and an agent role. For most fleets, one package per OS family bound to the pilot policy until cutover. The package generates downloadable installers and a one-line install command for Linux.

3. Prerequisites on the endpoints themselves. This is where rollouts fail quietly:

• Connectivity. HTTPS (443) to *.bitdefender.com and the regional cloud endpoint. If outbound traffic goes through a TLS-inspecting proxy, you need the Bitdefender certificate-pinning bypass or the agent refuses to phone home.
• Disk space. 2 GB free on Windows, 1.5 GB on macOS, 1 GB on Linux.
• Existing AV removed or coexisting. The Windows installer ships removal logic for Sophos, ESET, Kaspersky, Trend, Norton, McAfee, Avast and AVG. Defender gets pushed to passive mode automatically. Anything else, remove first.
• Time and timezone correct. TLS handshake fails on machines with a clock more than a few minutes off; the CRL check fails on machines with bogus CRL caches. This trips us up roughly twice a year.

How does the installer actually work?

The GravityZone installer is a small downloader. The full agent is not in the package you download. What’s in the package is a kit that authenticates to Control Center, pulls the policy, then downloads the modules you licensed. This matters for two reasons: the installer needs internet access during install, not just after; and the same downloader handles fresh installs, repairs, and module-add operations.

Once the modules land, the agent registers against the Control Center tenant using a token baked into the package. The endpoint appears in the Network view within minutes. From there it pulls policy on a heartbeat (default five minutes), pushes telemetry on the same cycle, and pulls signature and engine updates in the background.

There is no separate “management agent” and “AV agent”. One process does everything: epag.exe on Windows, epagd on Linux, the EndpointSecurityforMac system extension on macOS.

Deploying on Windows

Easiest of the three, mostly because Windows lets you run a signed MSI as SYSTEM with no further questions. Three deployment paths, in order of how often we use them.

Manual MSI / EXE

For small fleets or pilot machines: download the Windows installer from the package screen in Control Center (either a .exe downloader or an .msi for AD/Group Policy). Run it as Administrator. It detects existing AV, removes it if it’s on the supported list, reboots if it has to, and registers the endpoint.

For a true silent install (the version you’ll bake into a deployment script), the EXE accepts command-line flags:

# Silent install, no UI, no reboot prompt, log to file
.\setupdownloader_[token].exe /bdparams /silent /v"REBOOT=ReallySuppress /qn /l*v C:\Temp\bdinstall.log"

The /bdparams flag is the one people miss. Without it, the Bitdefender-specific arguments don’t propagate to the embedded MSI. The REBOOT=ReallySuppress is mandatory if you’re rolling out from a remote-management tool that can’t tolerate an unscheduled reboot.

Group Policy (GPO)

Standard MSI deployment via Computer Configuration → Policies → Software Settings → Software installation. Point it at the MSI from Control Center, set deployment type to Assigned, gpupdate. The catch: AD’s MSI deployment is fragile if share permissions aren’t right, and it doesn’t handle the agent’s reboot requirement gracefully. On any fleet bigger than 50 endpoints, use Intune or a proper RMM.

Intune

The cleaner path for modern fleets. Wrap the EXE installer with the Microsoft Win32 Content Prep Tool into an .intunewin file, upload it to Intune as a Win32 app, and use the install command:

setupdownloader_[token].exe /bdparams /silent /v"REBOOT=ReallySuppress /qn"

Detection rule: registry key HKLM\SOFTWARE\Bitdefender\Endpoint Security, value ProductVersion exists. Assignment: required, target the Azure AD device group that matches your pilot ring. Intune will run the installer as SYSTEM, which is what you want.

Command-line flags worth knowing

• GZ_PACKAGE_NAME="..." overrides the package name baked into the installer.
• INSTALL_PATH="D:\Bitdefender" puts the agent on a non-default drive.
• MODULES="atc,fw,cc,edr" overrides the module selection from the package (only honoured if your role allows).
• /uninstall plus the company-level uninstall password removes the agent. Worth scripting before a re-image.

Deploying on macOS

Harder. Apple’s security model has tightened steadily since Big Sur and the GravityZone agent now runs as a system extension rather than the old kernel extension. System extensions need explicit user or MDM approval, and an installer that doesn’t get that approval will sit on the device with reduced functionality and no telemetry.

Manual PKG

Download the macOS installer from Control Center; it’s a signed .pkg. Run it on the Mac. The installer copies the agent to /Library/Bitdefender/AVP and prompts the user to allow the system extension under System Settings → Privacy & Security, to grant Full Disk Access to the Bitdefender helper, and on Apple Silicon, to enter an admin password to load the extension.

If the user is technical and present, this works. If they click “Don’t Allow” on the security dialog because they’ve been trained to be suspicious, the agent runs in a degraded mode and you have to drive out there to fix it. Which is why we don’t do unmanaged Mac rollouts.

MDM push (Hexnode, Intune, Jamf, Kandji)

The right answer for any Mac fleet of meaningful size. The MDM ships three things ahead of the installer:

1. A System Extension policy that pre-approves Bitdefender’s team identifier.
2. A PPPC (Privacy Preferences Policy Control) profile granting Full Disk Access to the Bitdefender daemon binaries.
3. A Web Content Filter payload so the network filter loads.

With those profiles installed first, the PKG pushes silently and the agent comes up clean. No user prompts, no dialogs, no degraded mode. The PKG push itself is straightforward: VPP / direct upload in Hexnode, LOB app in Intune, policy in Jamf.

Hexnode-specific deployment notes live on the Hexnode page; Intune ones on the Intune page.

The system-extension approval window

This is the single most common macOS deployment failure. If the three profiles above are pushed after the PKG, or pushed too close together so the PKG installs before the System Extension profile applies, the agent loads its extension and macOS blocks it. Once blocked, only a manual approval clears it. On 200 Macs that means 200 user touches.

The fix is order. Push the profiles, wait for the MDM to confirm they’ve applied (Hexnode and Intune both report this), then push the PKG. We stage the deployment in two phases with a 30-minute gap on first rollout. No stuck endpoints since we started doing that.

Deploying on Linux

The most varied of the three, because “Linux” isn’t one operating system. Bitdefender supports a specific list and the install path differs slightly per family.

Supported distributions

Current as of 2026 (always check the Bitdefender support matrix for the latest):

• Ubuntu 20.04 LTS, 22.04 LTS, 24.04 LTS
• Debian 11 (Bullseye), 12 (Bookworm)
• RHEL / Rocky / AlmaLinux 8.x, 9.x
• CentOS Stream 8, 9
• SUSE Linux Enterprise Server 12 SP5, 15 SP4+
• openSUSE Leap 15.x
• Amazon Linux 2, 2023
• Oracle Linux 7, 8, 9 (UEK or RHEL kernel)

Other distros (Alpine, Arch, Gentoo, FreeBSD, Slackware) are not supported. If you have a one-off Alpine container host, you have a gap and it needs a different conversation.

Package format and install command

Control Center generates a single shell script per Linux package, typically installer.sh. Copy it to the host, mark it executable, run it as root:

sudo chmod +x installer.sh
sudo ./installer.sh

The script auto-detects the distribution, downloads the correct .deb or .rpm, installs the kernel-module dependencies, and starts the bdsec services. On Debian/Ubuntu you’ll see it pull in dkms, linux-headers-$(uname -r), and a few support libraries. On RHEL-family it pulls kernel-devel-$(uname -r) and dkms from EPEL.

If you prefer to handle package installation yourself (we do, on managed Linux fleets), Control Center will also let you download the raw .deb / .rpm plus a small registration script. The manual sequence is roughly:

# Debian / Ubuntu
sudo apt-get update
sudo apt-get install -y dkms linux-headers-$(uname -r)
sudo dpkg -i bitdefender-security-tools_*.deb
sudo /opt/bitdefender-security-tools/bin/bduitool register --token <package-token>

# RHEL / Rocky / Alma
sudo dnf install -y dkms kernel-devel-$(uname -r)
sudo rpm -ivh bitdefender-security-tools-*.rpm
sudo /opt/bitdefender-security-tools/bin/bduitool register --token <package-token>

Verify the daemon is up:

sudo systemctl status bdsec
sudo /opt/bitdefender-security-tools/bin/bduitool info

SELinux interaction

The most common Linux deployment failure on RHEL-family hosts is SELinux blocking the agent’s kernel module from loading. Symptom: bdsec is running, the agent reports to Control Center, but on-access scanning is silently disabled and the EDR telemetry is empty. dmesg shows AVC denials.

Two fixes. The polite one: install the SELinux policy module Bitdefender ships in /opt/bitdefender-security-tools/share/selinux/ with semodule -i bitdefender.pp, which adds the labels and rules the agent needs. The blunt one: set SELinux to permissive while you confirm coverage, then move it back to enforcing once the policy module is in. Don’t leave it permissive. That defeats the point of running RHEL-family in the first place.

On hardened Debian/Ubuntu hosts running AppArmor, the equivalent issue is rare but possible. Check dmesg | grep apparmor if the agent is misbehaving and add a profile exception under /etc/apparmor.d/local/.

Servers vs containers

The Bitdefender Linux agent is for hosts. Don’t try to install it inside a container; the kernel-module model doesn’t work there. For container workloads, run the agent on the host (Docker host, Kubernetes node) and let it see the container processes through the host’s process tree.

How do you verify the agent reported in?

This is the step rollouts skip, which is why “we deployed Bitdefender to all 300 endpoints last quarter” so often turns out to mean “we deployed to 280 and never noticed the other 20.”

Three checks on every endpoint:

1. Control Center sees the endpoint. Network → Computers and Virtual Machines, find the host, confirm the Last Seen timestamp is within the last 15 minutes and the OS, agent version and group are right.
2. The endpoint sees Control Center. On Windows: "C:\Program Files\Bitdefender\Endpoint Security\product.console.exe" /c GetCommunicationStatus. On macOS: the menu-bar icon shows green; or run /Library/Bitdefender/AVP/product/bin/BDLDaemon --info. On Linux: bduitool info shows Communication: Connected.
3. The modules you paid for are actually running. The agent will happily report in with half its modules missing if a download failed. Check the Modules tab on the endpoint’s detail page in Control Center: Antimalware, ATC, EDR (if licensed) all show Active. If anything shows Pending for more than an hour, something’s wrong.

For fleets bigger than 50 endpoints, automate this via the Control Center API. Pull the endpoint list, filter for Last Seen older than 24 hours and Module Status not Active, email the result. Once a week without fail.

What goes wrong, and how to fix it

The repeat offenders, in the order we see them.

Proxy and CRL issues

The agent tries to verify its own code-signing certificate by reaching Bitdefender’s CRL server. Behind a TLS-inspecting proxy without the right bypass, the check fails and the install rolls back with a generic error. Fix: bypass TLS inspection on *.bitdefender.com, *.bdrescue.com and the Microsoft / Apple CRL endpoints. Document the bypass, because the next firewall admin will remove it otherwise.

Timezone and clock drift

We mentioned this earlier; it deserves its own bullet. A laptop with a CMOS battery dying or a server that lost NTP three weeks ago will fail TLS handshake against Control Center. Symptom: install succeeds, agent never reports in. Fix: confirm w32tm /query /status (Windows), systemsetup -getusingnetworktime (macOS) or timedatectl (Linux) shows correct time and active sync.

Kernel-module loading on hardened Linux

Covered under SELinux above, with two extra notes. First, on RHEL hosts with FIPS mode enabled, dkms builds may fail because the kernel rejects unsigned modules. Solution: enrol the Bitdefender signing key into MOK (Machine Owner Key) at first boot. Second, on Ubuntu hosts running HWE kernels (Hardware Enablement, the newer kernels backported to LTS), you sometimes have to install linux-headers-generic-hwe-22.04 rather than the plain linux-headers-$(uname -r) for dkms to find headers.

MDM-pushed agents that miss the system-extension approval window on macOS

Already covered. Symptom: agent installed, Control Center shows it as connected, but EDR telemetry is empty and on-access scanning isn’t catching test files. Cause: the System Extension and PPPC profiles arrived after the PKG. Fix: remove the agent, push the profiles, wait, push the agent again. Apple does not give us a “retroactively approve” path. Once the user dialog is dismissed, only a clean re-install resets the state.

Existing AV not removed

The remover handles the brand-name AVs listed earlier. It does not handle SentinelOne, CrowdStrike, Cylance, Cortex, or other EDR products. Those need to come off via their own removal tool before the GravityZone agent goes on. Two EDRs on one host is not defence in depth. It’s a bluescreen waiting to happen.

Endpoint never appears in Control Center

Walk the list backwards: connectivity (can the host reach gravityzone.bitdefender.com on 443?), then DNS, then time, then proxy, then the install log. Windows: %PROGRAMFILES%\Bitdefender\Endpoint Security\Logs\install.log. macOS: /Library/Logs/Bitdefender/. Linux: /var/log/bitdefender/. Real errors are in there.

Want us to do the rollout for you?

Cross-platform deployments go well when they’re planned and badly when they aren’t. OSH does GravityZone rollouts end-to-end: scoping, package design, pilot, phased rollout, MDM integration on Mac, SELinux work on Linux, post-deploy verification, and the policy tuning that makes the agent quiet instead of noisy. Fleets from 20 endpoints to 2,000.

If you’d rather hand the job to someone who has done it 100 times, that’s what our professional services engagement is for. Email support@osh.co.za and we’ll come back with a written rollout plan, a price, and a target go-live date the same business day.