What are the core benefits of Bitdefender GravityZone Patch Management Add-On?
Central management – Patching runs from the existing GravityZone console.
Broad coverage – Patches Windows, macOS and Linux endpoints.
Automated scheduling – Maintenance windows scan and install patches unattended.
Patch evidence – Reports show installed, missing and failed patches.
Bandwidth saving – Relay endpoints cache patches for the local network.
Important note – Add-on requires an existing GravityZone base product.
Patch scanning – Finds missing operating system and application patches on endpoints.
Automatic patch deployment – Installs approved patches during scheduled maintenance windows.
Patch inventory – Lists every patch with severity, category and CVE references.
Patch caching server – Relay endpoints store patches locally and reduce internet traffic.
Patch status reporting – Reports installed, missing and failed patches for each endpoint.
Important – This add-on requires an existing GravityZone endpoint security product.
GravityZone Patch Management is an optional add-on module that adds operating system and third-party application patching to an existing Bitdefender GravityZone endpoint security deployment. It is managed centrally from the same GravityZone console, agent and policy as the other modules, in both cloud and on-premises installations.
One agent – Patching uses the same agent, console and policy.
Controlled rollout – Install patches on a test group before wider deployment.
Separate schedules – Security and non-security patches run on independent schedulers.
Patch exclusions – Ignore individual patches that break business-critical applications.
Lower bandwidth use – Cached patches stop every endpoint downloading from vendor sites.
Reboot control – Restarts can be postponed so users are not interrupted.
The decisive question is not headcount but whether GravityZone is already in use and whether anyone has to prove that patching happens. A company with twenty endpoints and no dedicated IT staff benefits from the automation; a company that answers customer audits benefits from the reporting. Server estates shift the calculation, because file, database and application servers are where deferred reboots and untested patches cause the most damage.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | By sector | By sector | By sector |
| NIS 2 in the European Union | Rarely | By sector | By sector |
| Security questionnaire from large customers | Occasional | ✓ | ✓ |
| Auditable patch evidence per device | Useful | ✓ | ✓ |
| This product fits | If GravityZone used | ✓ | ✓ |
The reporting obligation under the revised Information Security Act applies to operators of critical infrastructure, not to every Swiss company, so most buyers of this add-on are affected indirectly, through customers and contracts, rather than directly. Organisations that are covered must report a cyberattack to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery. Patch Management supports that duty in a narrow but concrete way: the Network Patch Status report records which endpoints were missing which CVE-referenced patches and when those patches were installed, which is the dated evidence you need when reconstructing how an attacker got in. What it does not do is detect the incident, write the report or notify BACS, and it produces no security telemetry of its own, so detection requires EDR, XDR or a managed service alongside it. It also does nothing for the organisational half of the duty, such as defining who decides that an event is reportable and who sends the report inside the 24-hour window. This information is a general orientation and does not constitute legal advice.
No product makes an organisation NIS 2 compliant, because the directive addresses management responsibility and documented processes as much as technology. NIS 2 requires risk management measures across categories including risk analysis and security policies, incident handling, business continuity and backup, supply chain security, secure acquisition, development and maintenance including vulnerability handling, cyber hygiene, access control, cryptography and multi-factor authentication. Patch Management maps substantially onto one of those categories, vulnerability handling and basic cyber hygiene, by turning known vulnerable software versions into a scheduled and documented remediation task instead of an occasional manual job. It also contributes to the requirement to assess whether measures are effective, because patch compliance is one of the few security properties that can be reported as a number and tracked over time. It covers none of the remaining categories, so incident handling, backup and recovery, supply chain assessment, access control, encryption and staff training must be answered by other modules and by written procedures.
Yes, for one block of a typical questionnaire, and not for the rest. It answers the vulnerability and patch management items directly: whether patching is centrally managed, how often systems are scanned for missing patches, how quickly security patches are deployed, whether third-party applications are covered alongside the operating system, and whether patch status can be evidenced per device. The Network Patch Status report is usually sufficient to attach as evidence, and the public API returns installed and missing patches if the questionnaire asks for raw data rather than a PDF. It answers nothing about incident detection and response, log retention, backup and recovery, device encryption, access control and multi-factor authentication, or supplier management, because none of those are functions of this module. Where those gaps have to be closed, staying inside the same GravityZone family is normally cheaper than adding a second vendor: full disk encryption, mobile security and EDR or XDR attach to the same console, which keeps one agent, one policy model and one set of reports for the auditor to read.
Rollback is the limitation with the most practical consequences: GravityZone can restore the previous state only on Windows endpoints and only for patches that support rollback, so on macOS and Linux, and for Windows patches without rollback support, a bad update has to be uninstalled or reinstalled by hand. Third-party patching is limited to the vendors and products in Bitdefender's supported catalogue, which means in-house software and niche line-of-business applications still need their own update route. Bitdefender documents disabling Windows automatic updates on managed endpoints so that patch timing is genuinely controlled by your maintenance windows rather than by Microsoft's schedule, and that configuration change is worth planning before rollout rather than after. Patches classed as manually approved, such as Windows feature updates, still require deliberate action and will not install unattended. The module patches software on managed endpoints only, so network appliances, firmware and unmanaged devices stay outside its scope and outside its reports.
Yes. The module is managed from the same GravityZone console customers already use, for both the cloud and the on-premises deployment. It is added to existing endpoints by creating an installation package in the console rather than by rolling out a separate agent.
An endpoint with the Relay role can additionally take the Patch Caching Server role, which stores patches on the local network and serves them to the other endpoints. If the caching server is unavailable, endpoints fall back to downloading from the vendor websites, so patching continues but uses more internet bandwidth.
Yes. The GravityZone public API returns installed and missing patches, and maintenance windows can be created, updated and assigned through the API as well. That is the usual route when patch status has to feed an existing reporting or ticketing system instead of being read in the console.
No. This module identifies and installs available patches for operating systems and applications. Misconfigurations, risky settings and risky user behaviour are handled by GravityZone Risk Management, which is a separate part of the platform and not included in this add-on.
Adds operating system and application patching to GravityZone. Covers Windows, macOS and Linux endpoints. Requires a GravityZone base product.
Bitdefender GravityZone Patch Management Add-On, Bitdefender, GravityZone, patch management, endpoint patching, third-party application patching, patch deployment, patch reporting
By continuing to browse our site you agree to our use of cookies, revised Privacy Policy and Terms of Service.
More information about cookies