What are the core benefits of the Bitdefender Integrity Monitoring Add-On?
Central console – Managed centrally from the GravityZone cloud console.
Entity monitoring – Tracks files, registries, services, installed software and users.
Automatic remediation – Reverses unwanted file and registry changes automatically.
Audit evidence – Exports change reports as CSV or PDF.
Base requirement – Needs an existing GravityZone endpoint security product.
Important note – No macOS coverage; Windows and Linux only.
Real-time change monitoring – Detects changes to monitored entities as they occur on endpoints.
Default and custom rules – Bitdefender supplies default rules; you add file and registry rules.
Automatic corrective actions –Restores permissions, owners and registry values after unauthorised changes.
Three performance modes – Fast, Normal and Slow buffering to control endpoint load.
Event reports and export – Filter by severity, user or entity; export CSV and PDF.
Important – No macOS agent support; the module runs on Windows and Linux.
Bitdefender lists this module as GravityZone Integrity Monitoring, and it extends an existing GravityZone endpoint deployment with system-wide change monitoring across files, directories, registry keys, installed software, services and user accounts. Rules, events and reports are managed centrally from the GravityZone cloud console, so no separate integrity tool has to be operated alongside the endpoint agent.
Detects silent changes – Catches configuration edits that antivirus and EDR rules ignore.
One agent – Reuses the installed Bitdefender agent instead of a second sensor.
Audit-ready change records – Each event names the entity, the change and the user.
Alert noise control – Restrictors block over-broad rules that would flood the event list.
Tunable endpoint impact – Buffering profiles let busy servers trade alert speed for load.
Selectable event retention – Seven days by default, longer through a retention add-on.
The deciding factor is not headcount but whether you operate Windows or Linux servers holding regulated or business-critical data, and whether anyone outside your IT team ever asks you to prove that those systems were not altered. A three-person company running a payment-adjacent Linux server has a stronger case for this module than a fifty-person company whose data lives entirely in a hosted service.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | ✕ | By sector | By sector |
| NIS 2 in the European Union | ✕ | By sector | By sector |
| Security questionnaire from large customers | Sometimes | ✓ | ✓ |
| Windows or Linux servers in scope | Limited | ✓ | ✓ |
| This product fits | Rarely | Often | ✓ |
The reporting obligation under the revised Swiss Information Security Act applies to operators of critical infrastructure, not to every company, so a regional retailer or agency is normally outside its scope while an energy supplier, hospital or larger public-sector IT operator is inside it. Affected operators must report a cyberattack to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery. The Integrity Monitoring Add-On supports that deadline in one specific way: each event records the affected entity, the type of change and the user account that made it, which is the material you need to describe what happened rather than only that something happened. It does not detect the attack itself, does not decide whether an event is reportable, and sends nothing to BACS, so the discovery and the report remain a human process and the module contributes evidence rather than compliance. This information is a general explanation and not legal advice; whether your organisation falls under the reporting obligation should be clarified with qualified legal counsel.
No software product makes an organisation NIS 2 compliant, because the directive addresses governance, processes and accountability alongside technical measures. The NIS 2 Directive requires risk-management measures from essential and important entities in areas such as incident handling, business continuity, supply chain security, security in system acquisition, development and maintenance, and policies for assessing whether those measures actually work. The Integrity Monitoring Add-On contributes to two of these categories: it supplies detection material for incident handling, and it produces the change records that let you test whether a hardening measure stayed in place after it was applied. It contributes nothing to business continuity, supplier assessment, access governance or staff training, and it raises no incident notification of its own. Treat it as one technical control inside a wider measure catalogue, not as the answer to a NIS 2 gap analysis.
Yes, for a narrow and clearly defined set of questions. It answers items on change detection for critical systems, on whether unauthorised modifications are recorded with attribution to a user account, on whether unauthorised changes can be reversed automatically, and on how long change records are kept. Questions about central policy management and role-based administrator access are answered by the underlying GravityZone console rather than by the add-on itself. It answers nothing on encryption at rest, backup and restore, patch levels, mailbox protection, mobile device management, penetration testing, staff awareness or supplier due diligence, and it is not a substitute for a security information and event management system. Where those gaps matter, the cheaper route is usually to stay inside the GravityZone family and add the Patch Management or Full Disk Encryption modules, or move to a higher Business Security tier that already includes endpoint detection and response, because a second vendor means a second console and a second evidence trail to maintain at audit time.
The single decisive difference is how far back you can look. Integrity Monitoring stores its events for seven days by default, which is enough to investigate something you noticed this week but not enough to answer a question about a change that happened last quarter. Bitdefender offers a separate Data Retention add-on that extends event storage to 90 days, 180 days or one year. If your reason for buying is an audit, a customer questionnaire or a regulated framework that expects historical change records, the seven-day default will not carry that use case on its own.
| Capability | Standard | With Data Retention add-on |
|---|---|---|
| Event storage period | 7 days | 90, 180 or 365 days |
| Investigating a recent change | ✓ | ✓ |
| Retrospective audit evidence | Limited | ✓ |
| Requires the Integrity Monitoring module | ✓ | ✓ |
This is an add-on, not a standalone product: it needs an existing GravityZone endpoint security product underneath it and is administered from the GravityZone cloud console, so it is not a fit if you were planning to run it next to a different vendor's endpoint agent. Agent support covers Windows and Linux only, which means Macs in your fleet stay outside the monitoring scope entirely, and on Linux only endpoints using the kprobes system sensor are supported, so older or unusual kernels can fall out of coverage. Custom rules can target files, directories, registry keys and registry values, while services, installed software and user accounts are watched through Bitdefender's default rules rather than rules you write yourself, which matters if your audit expects a specific named service to be monitored. The most common follow-up purchase is the Data Retention add-on, because the seven-day default storage is discovered to be too short at the moment someone asks for historical evidence. Finally, this module detects and reverses changes but does not restore lost data, so it does not reduce your need for a working backup.
No. Endpoint detection and response looks for attacker behaviour and known patterns, while Integrity Monitoring compares monitored entities against a known-good baseline and flags any deviation regardless of cause. That is why it catches things an EDR can miss, such as an administrator weakening a security setting on a server, but it also means it has no threat hunting, no incident timeline and no response playbooks of its own.
Two mechanisms work against that. Restrictors refuse to accept rules that are too broad to be useful, such as monitoring every log file on an endpoint, and the Normal and Slow processing profiles buffer events for three or six seconds so duplicate changes are collapsed before an alert is raised. Events also carry a severity of low, medium, high or critical, so you can filter the event list down to what actually needs a human.
Yes, and you decide per rule whether the action is automatic or manual. For files and directories it can delete files that should not have been created and correct changes to attributes, permissions, owner, group, file name and hash. For the Windows registry it can delete unwanted keys and sub-keys and correct deleted or modified keys and values.
Monitors changes to files, registries, services and user accounts on Windows and Linux. Requires a GravityZone base product and cloud console.
Bitdefender Integrity Monitoring Add-On, Bitdefender, GravityZone, file integrity monitoring, change detection, registry monitoring, server monitoring, Windows and Linux
By continuing to browse our site you agree to our use of cookies, revised Privacy Policy and Terms of Service.
More information about cookies