Elisity + Claroty xDome: Identity-Based Microsegmentation for OT and IoMT

Your network scanner sees an IP address at 10.4.12.87. It doesn’t tell you that’s a Siemens S7-1500 PLC running firmware v2.8, sitting at Purdue Level 1, communicating with an HMI it has no business talking to. That gap between “connected” and “classified” is where your OT risk lives. Without knowing what a device is, what firmware it runs, and where it sits in your Purdue model, your security team is writing segmentation policies based on guesswork.

Claroty xDome (formerly Medigate for healthcare environments) uses deep protocol inspection to classify every OT, IoMT, and XIoT device on your network. It doesn’t just find devices. It profiles them: device type, model, manufacturer, serial number, operating system, firmware version, Purdue level, and custom Claroty tags. That’s 8 attributes per device flowing into Elisity IdentityGraph through a native API connection. Elisity uses those attributes as match criteria to assign devices into Policy Groups automatically. And because the integration is bidirectional, Elisity returns your Policy Group classifications, enforcement status, and device labels back to xDome, so your operations team can verify segmentation coverage without switching consoles.

A GE CT scanner in your radiology department runs an embedded OS that hasn’t been patched in four years. A Rockwell Allen-Bradley PLC on your production floor can’t accept an endpoint agent without voiding the warranty. Both devices will be on your network for another decade. You can’t patch them. You can’t install agents on them. And you can’t take them offline because they’re running patient care and production lines right now.

Elisity enforces least-privilege access policies at your existing switch ports, with nothing installed on the device itself. That CT scanner gets a policy based on its xDome classification (device type, Purdue level, manufacturer) that restricts it to communicating only with PACS servers and authorized diagnostic workstations. The PLC gets a policy that limits traffic to its designated HMI and historian. If a device’s Claroty classification changes (new firmware, new behavior pattern), Elisity updates the policy automatically. The device doesn’t know it’s been segmented, which is exactly what you need when downtime isn’t an option.

You’ve seen the pattern. A segmentation project kicks off with a 12-month timeline. Six months in, the team is still manually inventorying devices because nobody can agree on the VLAN architecture. Twelve months in, the project stalls because the policy matrix has 4,000 rules and the team that built it can’t maintain it. Meanwhile, your IEC 62443 compliance deadline hasn’t moved. The problem isn’t willpower. It’s that traditional segmentation forces you to redesign your network before you can protect it.

Connect Claroty xDome to Elisity through the API integration in the Elisity Cloud Control Center. Once connected, xDome’s device classifications flow into IdentityGraph, and Elisity maps them into Policy Groups using attributes like Purdue level, device type, and custom Claroty tags. Those Policy Groups align directly with IEC 62443 zones and conduits, so your compliance mapping is built into your segmentation architecture from day one. No VLAN redesign. No new hardware. Your existing switches become the enforcement point. Organizations that have done this move from integration to enforced policies in weeks, not the 12-to-18-month timelines traditional projects require.