Bitdefender

OpsMerge pulls data from your existing Bitdefender (BD) tenant to surface threat alerts and device security state inside OpsMerge. We don't resell BD seats — your BD subscription stays with BD.

What you get

• Device list from BD merged with your OpsMerge agent list (matched by hostname). Devices in BD-only show up annotated.
• Threat alerts from BD become OpsMerge alerts with alert_type = bitdefender, routed through your normal alert rules.
• Policy state for each device — what BD policy it's on, last scan results, current health.
• Threat counts rolled up per client and per device for dashboards.

What we don't do:

• Sell or provision BD licences. Your BD admin owns your BD tenant directly.
• Push policy changes back to BD. This integration is read-only. (Write actions are on the roadmap but not shipped.)

Setup

What you need

• An existing Bitdefender GravityZone tenant (Cloud, On-prem also supported via API config).
• An API key from BD with read access to your devices and threats.

Connection

Settings → Integrations → Bitdefender → Connect.

Fields:

• API endpoint: BD's cloud endpoint (default for most) or your on-prem URL.
• API key: from BD GravityZone → My Account → API keys.

Click Test connection. OpsMerge calls BD's getCompaniesList (or equivalent for your endpoint) and reports the number of companies visible to that key.

Per-tenant API keys

We encrypt your API key at rest using a per-tenant key derived from the platform's master key. The credential is never logged or surfaced back to the UI in clear. If you suspect compromise, rotate the BD key in BD and update here.

Mapping companies to clients

BD organises devices under "companies" (their term for tenants). Each BD company maps to one OpsMerge client.

1. Settings → Integrations → Bitdefender → Mappings.
2. For each BD company, pick the matching OpsMerge client from the dropdown.
3. Save.

OpsMerge polls each mapped company for device + threat data.

The match is by hostname between BD devices and OpsMerge agents — not by BD's internal device ID. This is deliberate: hostnames are stable across BD device-renaming events and across OpsMerge agent re-registrations.

Sync cadence

Same pattern as M365 — adaptive polling:

• Hourly when there's no recent activity on this client.
• Every 10 minutes for active clients (open tickets, agent installs, etc.).
• On demand: client → Bitdefender tab → Sync now.

No webhooks. BD's webhook surface (where present) isn't comprehensive enough to rely on.

What threat data flows in

Each detected threat in BD becomes an OpsMerge alert with:

• Type: bitdefender.
• Severity: mapped from BD's severity scale.
• Title: the threat name.
• Device: the affected device, matched to your OpsMerge agent if present.
• Threat detail: file path, signature, action taken by BD (quarantined, deleted, etc.).
• Client: the matched OpsMerge client.

Alert rules apply the same way as any other alert. Common configuration:

• High-severity threats → create ticket immediately, page the on-call.
• Medium/Low → notify, no auto-ticket (review in batches).

Device list integration

In the agent list, BD-managed devices appear with a Bitdefender badge. Hover for the BD-specific state: policy, last scan, threat count today/week/month.

For agents that are only in BD (no OpsMerge agent), they appear as an asset on the client but with limited functionality — you can see them but can't push scripts.

Useful filters

In the threats view (per-client or tenant-wide):

• By severity — defaults to "High and above".
• By status — "Unresolved" by default; switch to "All" for historical.
• By client — narrow to one client.
• By device — find every threat for one machine.

Common patterns

"Tie BD threats to ticket SLAs"

Set up an alert rule:

• Trigger: alert with type = bitdefender AND severity >= High.
• Action: create ticket, priority = Critical, assign to security team.

Then BD threats land in your ticket queue with proper SLA-driven attention.

"Daily threat review across all clients"

Filter the threats view tenant-wide, status = Unresolved, severity >= Medium. Triage in batches.

"Client-side view of their own threats"

Portal users at a client can see a curated subset of their threats via the portal — Settings → Portal → Show BD threats. Useful for clients who want visibility into "what's been blocked this week".

Common issues

No threats appearing despite BD showing active threats. The company-to-client mapping is missing. Settings → Bitdefender → Mappings — every BD company you care about needs a client.

Device hostnames in BD differ from OpsMerge. The match is by hostname (not BD's device ID). If hostnames diverge — e.g. BD captures WIN-ABC123.local but OpsMerge has WIN-ABC123 — the match fails. Either normalise hostnames in BD or contact us; we'll look at the matcher.

Connection test passes but no companies visible. Your BD API key has too-narrow scope. Regenerate with broader access in BD GravityZone.

Threat alerts not creating tickets. Check your alert rules — by default we ship a "Bitdefender high-severity → ticket" rule, but it may have been disabled or scoped narrowly. Settings → RMM → Alert rules → look for BD-related rules.

On-prem BD: connection refused. Network path between OpsMerge and your BD on-prem. We need an outbound HTTPS path from our cell to your BD endpoint — set up via VPN, allow-list, or BD's reverse-tunnel feature.

Disconnect

Settings → Integrations → Bitdefender → Disconnect.

Stops polling. Existing imported data stays in place but is marked as "no longer syncing". Threats that came in via BD stay as historical alerts.

To re-enable: connect again. Existing client mappings are remembered.

Next

• Monitoring & alerts — how BD threats become alerts and tickets
• Tickets — what threats look like as tickets