ORDR + Elisity: AI-Powered Asset Intelligence for Dynamic Microsegmentation

A hospital floor runs infusion pumps, patient monitors, ultrasound carts, and nurse call systems. A plant floor runs PLCs, HMIs, and building automation controllers. None of them accept an endpoint agent, and in most inventories none of them resolve to anything richer than a MAC address, a DHCP fingerprint, and a VLAN assignment. Security teams are left with a list that confirms a device exists without saying what it is, who manufactured it, what operating system it runs, or what it normally communicates with. Policy work stalls there. You cannot write a least-privilege rule for an asset you can only describe as an address on VLAN 40, so unmanaged devices land in broad permissive zones by default, which are exactly the zones an attacker uses to move laterally. Manufacturer, model, operating system, and behavioral profile are the minimum context required before identity-based microsegmentation becomes something more than a diagram.

ORDR profiles every connected asset, and Elisity turns that profile into enforceable policy. ORDR Collectors deployed on premises combine passive flow collection with safe active probing to discover and classify IT, IoT, OT, and IoMT devices, tracking more than 2,500 attributes per asset. That intelligence flows into the Elisity IdentityGraph through an API connection configured in the Elisity Cloud Control Center, where manufacturer, model, operating system, FQDN, device type, device profile, and ORDR category arrive as first-class identity attributes rather than entries in a separate console. Your team stops exporting spreadsheets between platforms and stops maintaining a second inventory that drifts out of date the week after it is finished. ORDR establishes what each asset is and how it behaves. Elisity uses that identity to decide what the asset is permitted to reach, north-south and east-west, and enforces the decision through the network infrastructure you already own. No agents on the endpoint, no new appliances in the path.

Knowing that a device is an infusion pump is not the same as knowing it runs an operating system with an unpatched CVE, that it is clinically critical during a code, or that it handles protected health information. Most segmentation projects flatten those distinctions. Every pump lands in the pump group, every controller lands in the controller group, and the resulting policy is only as tight as the weakest member of the set. When a vulnerability advisory arrives on a Friday afternoon, the team has no attribute to pivot on: risk scoring lives in one platform, policy lives in another, and reconciling the two is a manual exercise measured in weeks. Compliance reviewers ask a version of the same question and get the same answer. Which controls apply to the devices that touch PHI, and how do you prove those controls followed a device when it moved to another floor, another building, or another clinic?

Elisity policy groups match on ORDR risk attributes directly, so segmentation reflects device risk rather than device type alone. Risk score, risk state, criticality, ORDR category, PHI indicator, and the “Known in ORDR” trust status are all available as policy group criteria in the Elisity Cloud Control Center. That makes rules like these routine to build and defend: any asset where “Known in ORDR” is false receives a restricted profile until it is identified; any device flagged as handling protected health information is limited to the clinical application servers it actually needs; any asset whose risk state rises moves into a tighter policy group without a change ticket or a maintenance window. Because the Elisity IdentityGraph re-evaluates attributes continuously, a device that gets remediated relaxes back into its normal group on its own. Auditors get a defensible answer: the control is bound to the asset’s identity and risk posture, not to the subnet it happens to occupy today.

Healthcare, manufacturing, and industrial organizations run thousands of device models that a generic classifier has never seen. Heart pump controllers, sterilizers, telemetry gateways, PLCs, and building automation systems all look like ordinary hosts on the wire until someone with domain knowledge labels them by hand. So teams build the inventory manually: a biomedical engineering spreadsheet here, a facilities list there, a network export nobody has refreshed since the last audit. It is accurate the day it is finished and stale a quarter later, because assets are added, replaced, re-imaged, and moved between buildings continuously. The result is a classification layer that cannot support automated policy. Every new device becomes a ticket, every acquired clinic or new production line multiplies the work, and the segmentation program advances at the speed of the people doing data entry instead of the speed of the network.

The integration maps 19 ORDR device attributes into Elisity policy group criteria, so classification happens once and policy follows automatically. The ORDR AI and machine learning classification engine identifies specialized equipment by behavior and communication pattern, then passes device type, device profile, device group, ORDR category, manufacturer, model, operating system, FQDN, risk state, and related fields into the Elisity IdentityGraph. A heart pump controller is classified as a heart pump controller, a PLC as a PLC, a building automation controller as a building automation controller, and each one lands in the policy group its role calls for. New assets inherit policy the moment ORDR profiles them, so a newly deployed imaging system is governed on day one instead of after the next inventory cycle. Enforcement runs through the network infrastructure you already own, which is why modern microsegmentation is measured in weeks where a VLAN redesign is measured in years.