● For information security leaders in U.S. healthcare.
CybrIQ for healthcareMedical-device visibility
The work · medical devices

You can't put antivirus on an infusion pump. The vendor contract probably forbids you to try. So how do you know what's on the network?

An Alaris infusion pump cannot run endpoint security software. A GE CARESCAPE telemetry monitor cannot run endpoint security software. A Philips PACS imaging workstation has a vendor support contract that voids the moment you change the operating-system image. This is the operating reality of every hospital information-security program in the country, and it is the reason the medical-device tail keeps disappearing off the asset list. The Health Sector Coordinating Council — the public-private group that publishes practical cybersecurity guidance for the healthcare field — has been blunt about it for years: legacy medical devices will stay in clinical use long past the manufacturer's support end-of-life, and the responsibility for protecting them falls on the hospital, not the manufacturer. The first step in protecting them is just knowing they are there. That is the step we automate.

In one paragraph We connect to your network switches using read-only protocols your network team already uses, and we ask each switch what is plugged into every port. From the information the switch gives us — manufacturer code, how the device introduces itself, low-level behavior — we recognize the device family. We never touch the medical device. We never look at clinical traffic. The clinical workflow does not pause. The vendor support contract is not voided. The output is a continuously refreshed inventory in a format your existing tools can ingest.

A short tour of what we identify, by device family.

Our reference library has roughly 750 million device fingerprints. The families below are the ones we get asked about most often in healthcare. We identify the family with high confidence. We identify the specific model variant where the device introduces itself clearly enough on the network.

Infusion pumps and patient-controlled analgesia.

Alaris (BD), Baxter Sigma Spectrum, B. Braun Outlook, Hospira/ICU Medical Plum, Smiths Medical Medfusion, CADD-Solis pain-management pumps. We see the pump by its manufacturer code and the way it announces itself on the wire. The pump never sees us back.

Patient monitoring and telemetry.

GE CARESCAPE central stations and bedside monitors, Philips IntelliVue, Mindray BeneVision, Spacelabs. The cardiac telemetry units that ride a dedicated VLAN. The fetal monitors. The capnography devices. All identifiable from the way they live on the network, not from anything we install on them.

Imaging modalities and PACS.

Siemens, GE, Philips, Canon Medical, Hologic, Konica Minolta. CT, MR, ultrasound, mammography, fluoroscopy, mobile C-arms, DR plates. Modality workstations. PACS clients. The vendor field service engineer's laptop the rep brings on-site for the modality install — that one gets identified separately, which is exactly the point.

Pharmacy automation and lab analyzers.

Omnicell and BD Pyxis cabinets and carousels, Swisslog tube systems, McKesson PROmanager-Rx. Roche cobas, Abbott Architect, Beckman Coulter, Sysmex, Ortho Vitros. These are vendor-managed devices, often with a remote-support tunnel back to the manufacturer. The tunnel is real whether or not it appears in your documentation. We identify the device whether the documentation does.

Operating room, ICU, and procedural infrastructure.

Stryker integration platforms. Olympus and Karl Storz endoscopy towers. Medtronic Hugo and Intuitive Surgical infrastructure. Anesthesia workstations from GE Aisys and Dräger Perseus. Ventilators from Hamilton, Maquet, and Dräger Evita. Surgical lighting and integration platforms.

Building systems with quiet network access.

Pneumatic-tube controllers (Swisslog, Pevco). HVAC and building-management systems (Johnson Controls, Siemens, Honeywell). Access control (Lenel, S2, Genetec). Nurse-call systems (Rauland, Hill-Rom). These devices share the same physical network. Many of them are running operating systems whose vendor support ended years ago. The Joint Commission has been asking about them in surveys since 2023. We identify them.

How we deploy, in clinical-environment terms.

The deployment is meant to be invisible to clinical staff and to the devices themselves. There is no agent on the medical device. There is no traffic mirroring. There is no active scanning. There is no in-line equipment to install on the patient floor.

We read from your network switches, the same way your monitoring tools already do.

CybrIQ talks to your existing managed switches using read-only SNMP — the standard read-only network management protocol every enterprise switch supports. The switch provides what it already knows: which manufacturer code is on each port, how the connected device announces itself, neighbor discovery information, and a handful of other low-level signals. From that information, we recognize the device. We do not copy traffic. We do not look at packet contents. We do not put any equipment between the network switch and the medical device.

Read-only by default. Optional read-write only if you authorize it.

The default deployment is purely read-only. CybrIQ asks the switch questions; it does not push changes to the switch. If — and only if — Clinical Engineering and IT jointly authorize it, CybrIQ can be configured to use read-write SNMP against the switch to move a port to a quarantine VLAN, disable an interface, or apply an access list. The action would happen on the switch, not on the medical device. The default ships off. We require written authorization before enabling it.

No PHI observed. Ever.

We do not look at packet contents. The information we work from is metadata the switch already collects to do its own job — port stats, neighbor announcements, manufacturer codes. Electronic protected health information does not flow through CybrIQ at any point. A Business Associate Agreement is available on request for procurement symmetry, even though our processing posture does not require us to receive PHI.

What we will not promise.

We will not promise that we make your devices safer. We don't touch them. We will not promise we replace your network access control or your endpoint security tools. We don't. What we will promise is that we will tell you, accurately and continuously, which medical devices are actually on your network this morning — and that the methodology will hold up when an auditor asks how you know.

A live walk-through with your Clinical Engineering counterpart on the call.

Medical-device security is the one place IT and Clinical Engineering have to agree before anything happens. We do the demo with both sides in the room.

Book a demo

30-day pilot, no fee. BAA available.