What are the core benefits of Bitdefender GravityZone Security for Mobile Add-On?
Central console – Managed from GravityZone, not per device.
Add-on product – Requires an existing GravityZone base solution.
Three platforms – Covers Android, iOS and ChromeOS devices.
Phishing blocking – Checks browser and SMS links on device.
App vetting – Flags non-compliant apps against your approved catalogue.
Important note – Not an MDM; wipe and lock need one.
Mobile Security console – Dedicated section in GravityZone for mobile devices and policies.
GravityZone MTD app – Agent for Android, iOS and Chromebook devices.
Application vetting – Assesses app security and privacy using over 180 detection points.
Phishing and web filtering – Blocks harmful links in browsers and SMS messages.
Threat log forensics – Records app, network and system activity with MITRE mapping.
Important – No device wipe, lock or app blocking without MDM.
Bitdefender GravityZone Security for Mobile Add-On is a mobile threat defence product that extends an existing GravityZone deployment to Android, iOS and ChromeOS devices, managed from a central console rather than device by device. It is not the older on-premises Security for Mobile Devices module, which Bitdefender has declared end of life, and it works as a detection layer alongside an MDM rather than replacing one.
One console – Mobile risk appears beside endpoint risk in GravityZone.
Offline detection – On-device machine learning still flags threats without connectivity.
BYOD without MDM enrolment – Protects personal phones without taking device management rights.
Jailbreak and root visibility – Reports tampered devices and missing operating system updates.
SIEM export – Sends device and threat events as JSON syslog.
Fast rollout – Users enrol through an emailed link or QR code.
Exposure here follows sector and customer base rather than headcount. A thirty-person engineering office supplying a listed manufacturer will face harder questions about mobile devices than a two-hundred-person retailer that sells only to consumers. The practical dividing line is whether phones already reach company mail and documents, and whether anyone can currently say how many of those phones are jailbroken, rooted or running an operating system that no longer receives updates.
| Requirement | Small business | Medium-sized company | Large company |
|---|---|---|---|
| Reporting obligation Switzerland | Rarely | By sector | By sector |
| NIS 2 in the European Union | Rarely | By sector | Often |
| Security questionnaire from large customers | Often | ✓ | ✓ |
| MDM or UEM already in place | ✕ | Partial | ✓ |
| This product fits | Limited | ✓ | ✓ |
No product delivers this on its own. The reporting duty in the revised Information Security Act applies to operators of critical infrastructure, such as energy, water, transport, health and public administration, rather than to companies above a certain size, so most Swiss SMEs are affected indirectly through their customers instead of directly. Where the duty does apply, a cyberattack must be reported to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery, which means the organisation has to establish quickly what happened and on which device. Security for Mobile supports the mobile part of that: the Threat Log records the app, network and system activity behind a detection and maps it to MITRE tactics, and events can be exported as JSON syslog so mobile incidents land in the same SIEM timeline as endpoint incidents. It does not cover the rest of the reporting chain, because it detects nothing on servers, workstations or mailboxes, produces no ready-made report for BACS, and cannot isolate or wipe a compromised phone unless an MDM is integrated. This text is not legal advice, and whether your organisation falls under the reporting duty should be clarified with qualified counsel.
No software product creates NIS 2 compliance, because the directive sets organisational duties: risk analysis and information security policies, incident handling, business continuity, supply chain security, security in acquisition and development, assessment of effectiveness, cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication. Security for Mobile contributes to a small number of these categories in a way that can be evidenced: asset management gains a mobile inventory with operating system risk, jailbreak and root status; incident handling gains mobile detections with forensic detail; and cyber hygiene gains visibility into which applications employees actually run on devices that reach corporate data. It contributes nothing to business continuity, cryptography, supplier due diligence, training or access control, and it neither manages device encryption nor enforces passcodes. An assessor will expect measures across the whole organisation, so a mobile layer on its own will not carry a NIS 2 assessment. The realistic value is narrower and more useful than compliance: mobile devices are usually the least documented asset class inside a NIS 2 scope, and this add-on makes them countable.
Partly, and in a section most suppliers leave blank. Questionnaires from enterprise customers and insurers increasingly ask whether mobile devices with access to company data are monitored, whether jailbroken or rooted devices are detected, whether mobile applications are vetted before use, and whether mobile security events reach a central log. Security for Mobile answers all four from console data rather than from a written assurance, and the app vetting catalogue in particular turns a vague answer into a list. It does not answer the items that usually carry more weight in scoring: endpoint detection and response coverage, patch levels, disk encryption on notebooks, backup and restore testing, mailbox protection, access control, and documented incident response procedures. Where those come back as gaps, the cheaper route is normally to stay inside the GravityZone family, since Patch Management and Full Disk Encryption are available as further add-ons on the same console, rather than to introduce a second vendor and a second agent, which creates its own questionnaire problems around agent conflicts and duplicated reporting.
The decisive difference is that the current add-on is a threat detection product, while the older one was a device management product. Security for Mobile Devices was an MDM feature inside the on-premises GravityZone Control Center, used the GravityZone Mobile Client app, and could lock, locate and wipe a phone itself; Bitdefender has declared it end of life. Security for Mobile is a cloud add-on, uses the GravityZone MTD app, and detects phishing, malicious applications, device tampering and network attacks, but performs lock and wipe only through an integrated MDM. If you are replacing the old module, plan for an MDM alongside it, because the enforcement actions did not carry over.
| Capability | Security for Mobile | Security for Mobile Devices |
|---|---|---|
| Product type | Threat defence | Device management |
| Console | Cloud add-on | On-premises |
| Remote lock and wipe | Via MDM only | ✓ |
| Application vetting | ✓ | ✕ |
| Phishing and SMS link protection | ✓ | ✕ |
| Product status | Current | End of life |
The add-on cannot be run on its own, since it attaches to an existing GravityZone endpoint solution or to GravityZone Cloud MSP, and there is no on-premises equivalent because the older on-premises module reached end of life. The most common follow-up purchase is an MDM or UEM, because lock, wipe, forced app removal and blocking installations fall outside what a mobile threat defence product does; without one, the response options on a compromised phone are limited to alerting the user, disconnecting Wi-Fi, disabling Bluetooth, and on Samsung Knox devices isolating the device or disabling apps. Platform coverage is uneven in one specific way that matters at rollout: on Android the application inventory is available as soon as the agent is installed, while on iOS it requires MDM integration because of how the operating system is built, so an iPhone-heavy fleet gets noticeably less out of app vetting until an MDM is connected. Chromebook support depends on the device supporting Android apps and the Google Play Store, which excludes older managed Chromebooks. Bitdefender does not publish country restrictions for individual features of this add-on, but data residency is worth confirming with your reseller, because Security for Mobile uses its own Mobile Security console and account alongside GravityZone.
The administrator creates a Mobile Security account in GravityZone and sends activation emails, or distributes a group invitation link and QR code. Users activate by opening the link or scanning the code with the device camera. Where an MDM is already in place, the GravityZone MTD app can be pushed to devices instead, and most MDM platforms can supply the activation details automatically.
Detection runs on the device using local machine learning, so private content does not need to be sent to the cloud for analysis. Forensic collection covers app behaviour, network connections and system activity, and how much of it is retained is controlled centrally in the Privacy section of the console. This is the setting to agree with your works council or data protection officer before a BYOD rollout, not afterwards.
Bitdefender documents integration with platforms including VMware Workspace ONE UEM, BlackBerry UEM, Citrix, IBM MaaS360, MobileIron Core, SOTI MobiControl and BlackBerry Dynamics. The available actions differ per platform, and Bitdefender publishes an MDM capabilities matrix on its support portal. Check that matrix against your own MDM before purchase, because the response actions you gain depend on it.