Introduction
The ORDR integration enables organizations to enrich device discovery and identity information from ORDR's asset intelligence platform into the IdentityGraph. ORDR Collectors are deployed on-premises as physical or virtual appliances that use flow collection and active probing to discover and profile devices across IT, IoT, and OT environments.
The connector polls the ORDR Platform API to retrieve device inventory data collected by ORDR Collectors. Device attributes including manufacturer, model, operating system, vulnerabilities, and risk scores are synchronized into IdentityGraph for policy-based segmentation. The integration operates using a cache-based architecture with automatic refresh cycles to maintain current device information without requiring continuous API polling.
| Benefit | Description |
|---|---|
| Comprehensive Asset Discovery | Discovers and profiles devices across IT, IoT, and OT environments using flow analysis and active probing techniques. |
| Automated Device Profiling | Continuously classifies devices and provides manufacturer, model, OS version, and device type information for accurate asset identification. |
| Vulnerability Intelligence | Integrates device vulnerability data and risk scores from ORDR's threat intelligence, enabling risk-based policy decisions for vulnerable assets. |
| On-Premises Data Collection | ORDR Collectors operate locally at monitored sites, ensuring device data remains on-premises while providing cloud-based management visibility. |
| Reactive Discovery Integration | Automatically enriches devices as they connect to the network, matching ORDR-discovered devices with IdentityGraph entries for immediate policy application. |
| Unified Asset Visibility | Provides consolidated view of IT, IoT, and OT devices across your network, supporting zero-trust segmentation strategies for diverse asset types. |
Prerequisites
- ORDR Platform instance with API access enabled
- ORDR Platform API URL (unique to your ORDR instance, e.g.,
https://[instance].ordr.net) - ORDR API username with appropriate permissions
- ORDR API password for authentication
- Cloud Control Center version 16.14.0 or higher
- Network connectivity from Cloud Control Center to ORDR Platform API endpoints (HTTPS/443)
- At least one ORDR Collector deployed and actively discovering devices
Design Considerations
VLAN Data Filtering: The connector automatically excludes VLAN values of "0" from enrichment data. ORDR uses a VLAN value of 0 to indicate unknown or unassigned VLANs. These invalid values are filtered out during synchronization to prevent inaccurate policy assignments and ensure only legitimate VLAN data appears in IdentityGraph. Devices with VLAN 0 in ORDR will not display a VLAN attribute in their IdentityGraph enrichment tile.
| Requirement | Constraint |
|---|---|
| Refresh Interval | Cache refreshes every 3 minutes. Initial sync retrieves devices last seen in 72 hours. Ongoing sync retrieves devices last seen in 15 minutes. The Refresh interval does not determine the frequency of IdentityGraph enrichment - this is determined by the Global Timer in Advanced Settings. |
| Device Correlation | Devices require MAC addresses for correlation between ORDR and IdentityGraph. |
| Default Enrichment Schedule | Default 24-hour enrichment refresh cycle. Initial delay configurable (default 0). Reactive discovery enabled for new device detection. |
| Single Instance Architecture | One connector instance per ORDR platform. Single endpoint architecture for API connectivity. |
| API Authentication | HTTPS authentication with username and password. Local authentication mode required on ORDR Platform API configuration. |
| Network Requirements | Cloud Control Center must reach ORDR Platform API via HTTPS (port 443). Firewall rules must permit outbound connections to ORDR instance URL. |
Cache-Based Polling Strategy: The connector implements cache-based polling. This approach minimizes API load while maintaining current device information. Initial sync establishes baseline inventory from the last 72 hours. Subsequent 3-minute polls retrieve only recently active devices (last 15 minutes), ensuring efficient API usage and timely updates.
MAC Address Correlation: Device matching between ORDR and IdentityGraph relies on MAC addresses as the primary correlation key. Ensure ORDR Collectors are positioned to observe device MAC addresses via flow collection or active scanning. Devices without discoverable MAC addresses cannot be correlated for enrichment.
ORDR Collector Deployment: At least one ORDR Collector must be actively discovering devices in your environment before configuring the connector. The connector retrieves data from ORDR's centralized platform, which aggregates information from all deployed collectors. Verify collectors are operational and discovering devices before integration setup.
Device Type Support: ORDR specializes in discovering and profiling IoT and OT devices that may not be visible to traditional discovery methods. Organizations deploying ORDR for IoT/OT visibility should leverage ORDR's device classification when designing policy groups. Consider creating dedicated policy groups for device categories identified by ORDR enrichment.
Before You Begin
Understanding ORDR Platform API: The ORDR Platform API provides programmatic access to device inventory collected by ORDR Collectors deployed in your environment. The API uses HTTPS authentication with username and password credentials. Authentication mode must be set to "Local" in the ORDR platform integration settings. API credentials are managed through the ORDR web console under Integrations settings.
Reactive Discovery Behavior: When a new device attaches to the network, the connector automatically enriches the device with ORDR data if a matching MAC address exists in the ORDR inventory. This reactive discovery matches the behavior of other asset intelligence connectors (Nozomi, Armis, Claroty) and ensures immediate policy application based on ORDR-provided attributes.
Known In ORDR Function: The "Known In ORDR" trust attribute enables policy decisions based on whether a device appears in the ORDR inventory. This attribute can be used for allowlist policies, ensuring only ORDR-recognized devices receive network access, or for detecting unknown/rogue devices that bypass ORDR Collectors.
Configuration
Step 1: Configure Platform API in ORDR
Before configuring the connector in Cloud Control Center, you must enable Platform API access in your ORDR instance and create API credentials. The Platform API provides programmatic access to device inventory data collected by ORDR Collectors.
Configure the following in the ORDR web console:
- Enable Platform API integration
- Create an API username and password
- Set Authentication mode to Local
- Save the configuration
Record the API username and password as these credentials will be required in Step 2 when configuring the connector in Cloud Control Center.
Step 2: Configure ORDR Connector in Cloud Control Center
Log into Cloud Control Center and navigate to System > Connectors. Click Add Connector and select ORDR from the connector catalog. The Add ORDR Connector configuration panel opens.
In the Required Configuration tab, enter the ORDR Platform API URL in the URL field. This should be the full HTTPS URL to your ORDR instance (e.g. https://[your-instance].ordr.net).
Enter the API Username configured in Step 1. This must match the username configured in the ORDR Platform API integration settings.
Enter the API Password for the username. This credential is masked in the interface for security.
Click Submit to validate the connection and create the connector instance. Cloud Control Center will attempt to authenticate with the ORDR Platform API and retrieve initial device data. If validation succeeds, the connector status changes to Active and initial sync begins.
Step 3: Configure Advanced Settings (Optional)
Advanced Settings
The Advanced Settings tab exposes connector-level tuning options that control how Cloud Control Center queries the connector, how learned data is retained, and how the connector's data is used by IdentityGraph and Insights.
The following chart provides details about each advanced setting.
| Setting | Description |
|---|---|
| Global Timer | The frequency at which Cloud Control Center queries the connector for updates. From 1 to 168 hours. Default is 24 hours. |
| Initial Delay | The delay in seconds before Cloud Control Center initiates the first query to the connector after initially discovering a new device. Default is 0 seconds. |
| Connector Data Purging | When enabled, Cloud Control Center purges all data learned about a device from this connector if the device is no longer found when querying the connected application. The time period between purge events is configurable from 1 to 90 days. The connector status will change from "Up to Date" to "Stale" if the device is no longer known by the connector but prior to the purge event. |
| Query Exclusion Rules | Limit the scope of Cloud Control Center queries by excluding specific Subnets or Virtual Edge Nodes, and by enabling or disabling the querying of devices with Random MAC addresses. |
| Enrichment Lookback Window | Defines how far back IdentityGraph looks for device activity when determining a device's eligibility for enrichment from this connector. Devices whose last seen timestamp falls within the configured window are eligible for enrichment; devices outside the window are not. Increasing this value may improve enrichment coverage for environments with infrequently connected devices (servers, OT systems, remote assets) but can increase processing load. Available values: 1 hour, 1 day, 3 days (default), 7 days, 30 days, 90 days. |
| Trusted Connector |
Controls whether Insights uses data from this connector when generating recommended Policy Groups. When enabled, device attributes from this connector are eligible to inform Insights' Policy Group recommendations. When disabled, Insights ignores this connector as a source for recommendations. Note: This setting only affects Insights recommendations — it does not change device verification status, trust attributes, or how the connector's data is used elsewhere in the platform. |
Verify the Integration
| Status | Description |
|---|---|
| Connector Status Active | The connector dashboard in System > Connectors shows Active status with a "configured on" timestamp. |
| Device Count Matches ORDR | Navigate to Identity > Devices and filter by the ORDR connector. Verify the device count approximates the number of active devices in your ORDR inventory. |
| Enrichment Layer Present | Select a device known to exist in ORDR and view its details in IdentityGraph. The ORDR enrichment layer should appear in the device details with manufacturer, model, and other ORDR-provided attributes. This assumes the same device has been discovered on your Elisity-secured network. |
| Known In ORDR Attribute | Verify that devices enriched by ORDR display the "Known In ORDR" trust attribute. This attribute should be set to true for devices present in the ORDR inventory. |
| Policy Group Match Criteria | Create a test Policy Group using ORDR-provided attributes (manufacturer, device type, or Known In ORDR). Verify that devices appear in the policy group based on ORDR enrichment data. |
| Reactive Discovery Functional | Connect a new device to the network that ORDR Collectors can discover. Within minutes of ORDR detection, verify the device receives ORDR enrichment in IdentityGraph without manual intervention. |
Verifying Device Enrichment
Once the connector is active and initial sync completes, ORDR enrichment appears on discovered devices in Cloud Control Center. Navigate to Identity > Devices and select a device known to exist in your ORDR inventory.
In the Device Details view, the ORDR enrichment layer displays attributes synchronized from the ORDR Platform API. These attributes include manufacturer, model, device type, operating system, firmware version, risk score, and vulnerability information provided by ORDR's device profiling and threat intelligence.
The Known In ORDR trust attribute indicates whether the device appears in the ORDR inventory. Devices with this attribute set to true have been discovered and profiled by ORDR Collectors. This attribute can be used in policy group definitions to create policies based on ORDR visibility.
Verify that enrichment data matches the device information shown in the ORDR web console. Discrepancies may indicate MAC address correlation issues, incomplete ORDR profiling, or synchronization delays. Allow up to 3 minutes after ORDR discovery for enrichment to appear in IdentityGraph due to the connector's polling interval.
Leveraging Attributes in Policy Groups
ORDR attributes are available as match criteria in Policy Group definitions. To leverage ORDR enrichment for policy-based segmentation, create or modify a Dynamic Policy Group and select ORDR attributes as match criteria.
Navigate to Policy > Policy Groups and create a new Dynamic Policy Group or edit an existing one. In the match criteria configuration, select the ORDR connector from the available sources. ORDR provides attributes including:
- Manufacturer: Device manufacturer identified by ORDR profiling (e.g., Cisco, Siemens, GE Healthcare)
- Model: Specific device model or product family
- Device Type: ORDR's device classification (e.g., IP Camera, PLC, Building Automation)
- Operating System: OS version detected by ORDR through profiling or active scanning
- Risk Score: ORDR-calculated risk score based on vulnerabilities, network behavior, and device criticality
- Known In ORDR: Boolean indicating whether device appears in ORDR inventory (true/false)
Use these attributes to create specialized policy groups for IoT and OT devices. For example, create a policy group matching all devices with Manufacturer = "Siemens" and Device Type = "PLC" to apply specific segmentation policies to industrial control systems. Or create a policy group using Known In ORDR = false to identify devices that bypass ORDR Collector visibility.
After defining match criteria, Cloud Control Center displays the current device count matching the policy group. This allows validation that the policy group captures the intended devices based on ORDR enrichment before applying policies in production.
Troubleshooting
| Issue | Resolution |
|---|---|
| 401 Unauthorized Error | Verify that the API username and password are correctly configured in both ORDR Platform API settings and Cloud Control Center connector configuration. Ensure the credentials match exactly. Check that the ORDR API user account has not been disabled or had permissions revoked. Test credentials by logging into the ORDR web console with the same username and password. |
| Connection Timeout | Verify network connectivity from Cloud Control Center to the ORDR instance URL on port 443. Check firewall rules and proxy configurations to ensure outbound HTTPS connections are permitted. Test connectivity using curl -v https://[your-instance].ordr.net from Cloud Control Center. If timeouts persist, verify the ORDR instance URL is correct and the ORDR platform is accessible from the internet or your Cloud Control Center deployment location. |
| Connector Status Degraded | Review connector logs in Cloud Control Center for specific error messages. Common causes include API authentication failures (verify credentials), network connectivity issues (check firewall rules), or ORDR platform maintenance windows. Check ORDR system status and verify Platform API is enabled in ORDR integration settings. Click the connector sync button to retry after addressing the underlying issue. |
| No Devices Enriched | Verify that ORDR Collectors are deployed and actively discovering devices. Log into the ORDR web console and confirm devices appear in the ORDR inventory. Check that devices have MAC addresses visible to both ORDR Collectors and IdentityGraph. Devices without MAC addresses or with MAC address mismatches will not correlate. Trigger a manual connector sync and wait for the next 3-minute polling cycle to retrieve device data. |
| Incomplete Device Attributes | ORDR attribute availability depends on ORDR Collector profiling success. Some devices may have limited attributes if ORDR profiling is incomplete. Check the ORDR device details in the ORDR web console to verify what attributes are available. If ORDR shows complete data but IdentityGraph does not, review attribute mapping in Cloud Control Center connector logs. Some attributes may require additional ORDR licensing or configuration. |
| Reactive Discovery Not Working | Verify that the device connects to the network and generates traffic visible to ORDR Collectors. Check that ORDR discovers the device (appears in ORDR inventory within expected timeframe). Ensure the device MAC address is consistent between ORDR and IdentityGraph observations. Wait for the next 3-minute connector polling cycle after ORDR discovery completes. If delays persist, verify reactive discovery is enabled in connector advanced settings. |
| Authentication Mode Error | Verify that Authentication mode in ORDR Platform API integration settings is set to Local. Other authentication modes are not supported by the Cloud Control Center connector. Log into ORDR web console, navigate to Integrations > Platform API, and confirm Local authentication is selected. After changing authentication mode, update the connector configuration in Cloud Control Center with credentials and test the connection. |
Maintenance Tasks
Monitoring Connector Health: Regularly review connector status in Cloud Control Center under System > Connectors to ensure continuous synchronization. Check the last sync timestamp and verify it updates according to the 3-minute polling schedule. Monitor connector logs for authentication errors, API connectivity failures, or timeout messages. Set up alerting if your monitoring platform supports it to notify administrators when connector status changes from Active to Degraded or Error state.
Credential Rotation: Periodically rotate API credentials according to your organization's security policies. Before rotating credentials, create new API credentials in ORDR Platform API settings. Update the Cloud Control Center connector configuration with the new username and password. Validate the connection before removing old credentials from ORDR. Best practice is to rotate API credentials every 12-18 months or when personnel with credential access change roles.
Reviewing Enrichment Coverage: Periodically audit which devices receive ORDR enrichment to ensure comprehensive coverage. Navigate to Identity > Devices and filter by devices with ORDR enrichment layer present. Compare this against your expected device inventory. Devices missing ORDR enrichment may indicate ORDR Collector coverage gaps, MAC address correlation issues, or devices not visible to ORDR discovery methods.
ORDR Platform Updates: When ORDR releases platform updates or changes API endpoints, verify connector compatibility with Cloud Control Center. Test connector functionality in a non-production environment after ORDR platform upgrades. Review ORDR release notes for API changes that may impact integration. Contact Elisity support if connector errors occur after ORDR platform updates.
Best Practices
Deploy ORDR Collectors Strategically: Position ORDR Collectors where they can observe maximum device traffic through SPAN/mirror ports or inline deployment. Coverage gaps in ORDR Collector visibility result in incomplete device discovery and limited enrichment data in IdentityGraph. Work with ORDR support to optimize collector placement for your network architecture and device types.
Leverage Device Intelligence for Policy Segmentation: Use ORDR's device profiling to create specialized policy groups for IoT and OT devices. ORDR provides detailed classification for device types that may be difficult to identify through other methods. Design policies that apply appropriate security controls based on device risk profiles identified by ORDR vulnerability intelligence.
Monitor MAC Address Consistency: Device correlation between ORDR and IdentityGraph depends on MAC address matching. Monitor for devices that change MAC addresses (virtualized systems, devices with MAC randomization) as these may cause enrichment failures. Document known MAC address changes in your environment and adjust query exclusion rules if specific device classes should not receive ORDR enrichment.
Use Known In ORDR for Anomaly Detection: Create alert policies or monitoring dashboards that flag devices present in IdentityGraph but not "Known In ORDR". These devices may represent rogue assets, BYOD, or legitimate devices outside ORDR Collector coverage. Investigate unknown devices to determine if ORDR Collector coverage needs expansion or if devices require policy exceptions.
Optimize Enrichment Refresh Intervals: Default 24-hour enrichment refresh is appropriate for most environments. Reduce the interval for environments where device attributes change frequently (vulnerability scores, firmware versions). Increase the interval for stable environments to reduce API load. Monitor ORDR API performance and adjust refresh timing based on environment size and change frequency.