Claroty xDome

OT Security

Overview

The Claroty xDome connector integrates with the Claroty xDome (formerly Medigate) platform to synchronize OT/IoT/IoMT device inventory, security alerts, and vulnerability data. It retrieves device assets, alert definitions, alert findings (per device-alert pair), vulnerability definitions (CVEs), and vulnerability findings (per device-vulnerability pair) using the xDome REST API.

---

Data retrieved from Claroty xDome

Connector Object	Required	Maps to Data Model
Device	Yes	Host
Alert Definition	Yes	Alert Definition
Alert	Yes	Alert
Vulnerability Definition	Yes	Vulnerability Definition
Vulnerability	Yes	Vulnerability

Model relationships

note

For detailed steps on how to view the data retrieved from Claroty xDome in the Brinqa Platform, see How to view your data.

Setup

Connection settings

When setting up a data integration, select Claroty xDome from the Connector dropdown and provide the following:

Setting	Required	Default	Description
Service URL	Yes	https://api.medigate.io	Claroty xDome API URL
API Key	Yes	—	Claroty xDome API key
Page Size	No	5000	Number of items to return per API request
Parallelism	No	min(4, availableProcessors)	Number of threads to spawn to make API requests

Authentication

The connector authenticates with the Claroty xDome API using an API Key presented as a Bearer token. The key is generated in the Claroty xDome dashboard under Administration → Integrations → API Keys and supplied to the connector through the apiKey configuration property.

All xDome data endpoints are POST calls that accept a JSON request body. There is no separate token-exchange or login endpoint; the API key is sent directly on every request.

Endpoint

The connection is validated against the Devices endpoint with a minimal request:

Method	URL
POST	/api/v1/devices/

Request Headers

Header	Value
Content-Type	application/json
Authorization	Bearer <api-key>
User-Agent	BrinqaXdomeConnector/<version>

Request Body

All endpoints share the same request-body contract. Fields, pagination, and filters are passed in the body:

{
  "fields": ["uid"],
  "offset": 0,
  "limit": 1,
  "include_count": true
}

Additional optional members used during sync:

{
  "fields": ["uid", "device_name", "ip_list"],
  "offset": 0,
  "limit": 5000,
  "include_count": true,
  "filter_by": {
    "field": "retired",
    "operation": "equals",
    "value": false
  },
  "sort_by": [
    { "field": "uid", "order": "asc" }
  ]
}

When more than one filter applies, they are composed with an and compound clause:

{
  "filter_by": {
    "operation": "and",
    "operands": [
      { "field": "device_retired", "operation": "equals", "value": false },
      { "field": "last_seen_list", "operation": "greater_or_equal", "value": "2024-01-01T00:00:00Z" }
    ]
  }
}

Sample Response

Responses are paginated envelopes. The top-level item key varies by endpoint (e.g. devices, alerts, vulnerabilities, devices_alerts, devices_vulnerabilities, sites):

{
  "count": 1342,
  "devices": [
    {
      "uid": "d3b07384-d9a0-4c9e-8b1a-1f2e3d4c5b6a",
      "device_name": "PLC-Line-2",
      "ip_list": ["10.0.4.21"]
    }
  ]
}

Response Fields

Field	Type	Description
count	Integer	Total number of matching records (returned only when include_count is true, used to drive parallel pagination)
devices / alerts / vulnerabilities / devices_alerts / devices_vulnerabilities / sites	Array	The page of items; the key name depends on the endpoint being called

Usage

The same API key is attached as a Bearer token on every request:

Authorization: Bearer <api-key>

Pagination is offset-based: the first page is fetched with include_count = true to obtain the total count, then the remaining pages are fetched in parallel using the offset/limit members.

---

Sync Behavior

The connector supports incremental (delta) syncs. It maintains a sync token between runs and applies it as an incremental timestamp filter, so each run re-processes only the records that changed after the previous sync. The initial run retrieves the complete data set; later runs are incremental. The specific timestamp field applied to each object is documented under that object's Sync Duration Parameter.

How to obtain Claroty xDome credentials

Obtain a Claroty xDome API key

For the Claroty xDome connector to use the Claroty API, you must create an API user and generate an API key. To do so, follow these steps:

1. Log in to your organization's Claroty xDome portal as an administrator.

2. Navigate to Settings > Admin Settings.

3. In the navigation menu, click User Management, and then click Add User.

   The Create User dialog appears. Complete the following fields:

   • User Type: Select API User.

   • User Info: Enter a user name and title (description) for the API key.

Note: This user name must be different from the Claroty xDome portal login user name.

• Site Permissions: Click the dropdown and choose the necessary sites you want the Claroty xDome connector to have access to.

• Roles: Click the dropdown and select Read-Only User.

• Including future sites: (Optional) Enable this option to automatically grant access to any new sites added to your Claroty xDome environment. This ensures that the connector can retrieve data from all current and future sites without requiring manual updates to the site permissions.

  

4. Click Create User.

5. After creating the new user, click Generate Token.

   

   The Generate API token dialog appears.

6. Click the Token Expiration dropdown and select the desired token expiry date.

7. Click Generate.

   Your new API key displays. You can not view the key again after this. Copy and save it to a secure location.

Note: If you do not have permissions to create an API key, contact your Claroty xDome administrator.

Data & mappings

Attribute mappings

Expand the sections below to view the mappings between the source and the Brinqa data model attributes:

Device

Source Field Name	SDM Attribute
DeviceResource.assetId	ASSET_ID
DeviceResource.combinedOs	OPERATING_SYSTEM
DeviceResource.combinedOs	COMBINED_OS
DeviceResource.criticality	CRITICALITY
DeviceResource.detectorName	DETECTOR_NAME
DeviceResource.deviceCategory	CATEGORIES
DeviceResource.deviceCategory	DEVICE_CATEGORY
DeviceResource.deviceName	NAME
DeviceResource.deviceName	DEVICE_NAME
DeviceResource.deviceSubcategory	DEVICE_SUBCATEGORY
DeviceResource.deviceType	DEVICE_TYPE
DeviceResource.deviceTypeFamily	DEVICE_TYPE_FAMILY
DeviceResource.endpointSecurityNames	ENDPOINT_SECURITY_NAMES
DeviceResource.fdaClass	FDA_CLASS
DeviceResource.firstSeenList[0]	FIRST_SEEN
DeviceResource.internetCommunication	INTERNET_COMMUNICATION
DeviceResource.ipList	IP_ADDRESSES
DeviceResource.labels	TAGS
DeviceResource.lastSeenList[0]	LAST_SEEN
DeviceResource.macList	MAC_ADDRESSES
DeviceResource.manufacturer	MANUFACTURER
DeviceResource.mobility	MOBILITY
DeviceResource.model	MODEL
DeviceResource.networkList	NETWORKS
DeviceResource.note	NOTE
DeviceResource.purdueLevel	PURDUE_LEVEL
DeviceResource.retired	STATUS
DeviceResource.retired	RETIRED
DeviceResource.riskScore	RISK_SCORE
DeviceResource.riskScorePoints	RISK_SCORE_POINTS
DeviceResource.serialNumber	SERIAL_NUMBER
DeviceResource.siteName	SITE_NAME
DeviceResource.uid	UID
DeviceResource.vlanList	VLANS
SiteResource.countryCode	SITE_COUNTRY_CODE
SiteResource.location	SITE_LOCATION
SiteResource.timezone	SITE_TIMEZONE
System-generated	LAST_CAPTURED

Alert Definition

Source Field Name	SDM Attribute
AlertResource.alertClass	ALERT_CLASS
AlertResource.alertTypeName	UID
AlertResource.alertTypeName	NAME
AlertResource.category, AlertResource.alertClass	CATEGORIES
AlertResource.description	DESCRIPTION
AlertResource.detectedTime	DETECTED_AT
AlertResource.devicesCount	DEVICES_COUNT
AlertResource.mitreTechniqueEnterpriseIds	MITRE_ENTERPRISE_IDS
AlertResource.mitreTechniqueEnterpriseNames	MITRE_ENTERPRISE_NAMES
AlertResource.mitreTechniqueIcsIds	MITRE_ICS_IDS
AlertResource.mitreTechniqueIcsNames	MITRE_ICS_NAMES
AlertResource.status	ALERT_STATUS
AlertResource.unresolvedDevicesCount	UNRESOLVED_DEVICES_COUNT
AlertResource.updatedTime	UPDATED_AT
MITRE technique names (ICS + Enterprise)	TAGS
System-generated	LAST_CAPTURED

Alert

Source Field Name	SDM Attribute
alertId:deviceUid	UID
DeviceAlertRelationResource.alertCategory	ALERT_CATEGORY
DeviceAlertRelationResource.alertClass	ALERT_CLASS
DeviceAlertRelationResource.alertLabels	TAGS
DeviceAlertRelationResource.alertTypeName	TYPE
DeviceAlertRelationResource.deviceAlertDetectedTime	DETECTED_AT
DeviceAlertRelationResource.deviceAlertStatus	PROVIDER_STATUS
DeviceAlertRelationResource.deviceAlertUpdatedTime	UPDATED_AT
DeviceAlertRelationResource.deviceUid	TARGETS
Normalized from PROVIDER_STATUS	SOURCE_STATUS
System-generated	LAST_CAPTURED

Vulnerability Definition

Source Field Name	SDM Attribute
Derived from normalized severity	SEVERITY_SCORE
System-generated	LAST_CAPTURED
VulnerabilityResource.adjustedVulnerabilityScore	ADJUSTED_SCORE
VulnerabilityResource.adjustedVulnerabilityScoreLevel	SEVERITY
VulnerabilityResource.adjustedVulnerabilityScoreLevel	SOURCE_SEVERITY
VulnerabilityResource.adjustedVulnerabilityScoreLevel	ADJUSTED_SCORE_LEVEL
VulnerabilityResource.affectedDevicesCount	AFFECTED_DEVICES_COUNT
VulnerabilityResource.cveIds	CVE_IDS
VulnerabilityResource.cveIds	CVE_RECORDS
VulnerabilityResource.cvssV2VectorString, cvssV3VectorString	CVSS v2/v3 metrics
VulnerabilityResource.description	DESCRIPTION
VulnerabilityResource.epssScore	EPSS_SCORE
VulnerabilityResource.exploitsCount	EXPLOITS_COUNT
VulnerabilityResource.isKnownExploited	IS_KNOWN_EXPLOITED
VulnerabilityResource.name	UID
VulnerabilityResource.name	NAME
VulnerabilityResource.publishedDate	PUBLISHED_DATE
VulnerabilityResource.sourceName	SOURCE_NAME
VulnerabilityResource.sourceUrl	SOURCE_URL
VulnerabilityResource.vulnerabilityLabels	TAGS
VulnerabilityResource.vulnerabilityPriorityGroup	PRIORITY_GROUP
VulnerabilityResource.vulnerabilityType	CATEGORIES
VulnerabilityResource.vulnerabilityType	VULNERABILITY_TYPE

Vulnerability

Source Field Name	SDM Attribute
Derived from vulnerabilityRelevance	PROVIDER_STATUS
DeviceVulnerabilityRelationResource.deviceUid	TARGETS
DeviceVulnerabilityRelationResource.deviceVulnerabilityDetectionDate	DETECTION_DATE
DeviceVulnerabilityRelationResource.deviceVulnerabilityResolutionDate	RESOLUTION_DATE
DeviceVulnerabilityRelationResource.vulnerabilityAdjustedVulnerabilityScoreLevel	ADJUSTED_SCORE_LEVEL
DeviceVulnerabilityRelationResource.vulnerabilityLabels	TAGS
DeviceVulnerabilityRelationResource.vulnerabilityName	TYPE
DeviceVulnerabilityRelationResource.vulnerabilityRelevance	VULNERABILITY_RELEVANCE
Normalized from PROVIDER_STATUS	SOURCE_STATUS
System-generated	LAST_CAPTURED
vulnerabilityId:deviceUid	UID

Operations & API

Operations & API

Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).

Device

Operation options

Option	Type	Default	Description
excludeRetired	Boolean	true	Exclude retired devices from sync
enrichSites	Boolean	false	Enable site enrichment (adds location, timezone, country code from /api/v1/sites/get)

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on last_seen_list.

API

• Type: REST POST endpoint · Endpoint: POST /api/v1/devices/
• Default filters: retired = false (excludes retired devices)

Alert Definition

Operation options

Option	Type	Default	Description
excludeResolved	Boolean	true	Exclude resolved alert definitions from sync

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on updated_time.

API

• Type: REST POST endpoint · Endpoint: POST /api/v1/alerts/
• Default filters: status != "Resolved" (excludes resolved alerts)

Alert

Operation options

Option	Type	Default	Description
excludeRetired	Boolean	true	Exclude alerts on retired devices

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on device_alert_updated_time.

API

• Type: REST POST endpoint · Endpoint: POST /api/v1/device_alert_relations/
• Default filters: device_retired = false (excludes alerts on retired devices)

Vulnerability Definition

Operation options

This object does not support any operation options.

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on published_date.

API

• Type: REST POST endpoint · Endpoint: POST /api/v1/vulnerabilities/
• Default filters: None (must sync all CVEs for TYPE linkage)

Vulnerability

Operation options

Option	Type	Default	Description
excludeRetired	Boolean	true	Exclude vulnerabilities on retired devices
excludeIrrelevant	Boolean	false	Exclude vulnerabilities with relevance "irrelevant"

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on device_vulnerability_detection_date.

API

• Type: REST POST endpoint · Endpoint: POST /api/v1/device_vulnerability_relations/
• Default filters: device_retired = false (excludes vulnerabilities on retired devices)

Changelog

Changelog

The Claroty xDome connector has undergone the following changes:

Version	Description	Migration Steps
3.0.4	Improvements - Devices discovered in Claroty xDome are now synchronized to the standard Host model, aligning the connector with Brinqa's host-centric Unified Data Model. The associated asset category is also updated from Device to Host. - Expanded the set of Host identifiers used for record matching to include serial number, MAC addresses, and IP addresses, improving deduplication when correlating xDome devices with Host records from other sources.	• Device: The target model has changed from Device to Host. Action: purge previously synced Device records from this connector and re-sync to repopulate them as Host assets.
3.0.3	New Features - Added synchronization of vulnerabilities and vulnerability definitions from Claroty xDome, surfacing CVE-level exposure for each device along with shared definition details such as severity and description. - Added synchronization of alerts and alert definitions, bringing xDome security alerts and their reusable alert types into Brinqa as findings. Improvements - Device records are now enriched with site information, providing additional location and grouping context for each synchronized device.	N/A
3.0.2	Improvements - Devices now use the device name reported by Claroty xDome as their display name when available, falling back to asset ID or serial number. This produces clearer, more recognizable device names in Brinqa.	N/A
3.0.1	Improvements Dependency Upgrades Upgraded internal framework and model libraries to the latest stable versions for improved reliability, security patches, and alignment with the rest of the connector platform.	N/A
3.0.0	Overview The Claroty xDome connector integrates with Claroty xDome to synchronize discovered devices as assets in Brinqa. Category: OT Security Models	N/A