Forescout Medical Device Security

An asset intelligence and enforcement platform with models in part of the detection layer, and the company describes the split honestly rather than claiming the whole thing is intelligent.

The honest construction is the phrase artificial intelligence and rule based attack detection. That single formulation tells a reader the detection layer is hybrid, and vendors in this category routinely describe the same architecture as artificial intelligence powered without the qualifier. Automatic classification of medical assets into a logical taxonomy and identification of performance anomalies in utilisation data are further model shaped capabilities.

What carries the product is not those. Agentless discovery reaching devices behind firewalls and serial gateways is network engineering. Risk assessment combining known exposures, attack potential and operational criticality is a scoring model in the actuarial sense rather than a learned one, and the inputs are vulnerability databases, device criticality and configuration. FDA class and recall tracking is a data integration. Manufacturer disclosure statement integration is document handling. Segmentation policy enforcement is network control. A hospital could run this platform, get most of its value, and never rely on a learned model.

The instability of the claim reinforces the grade. The same sentence describing the platform appears with artificial intelligence powered intelligence in one version and cloud powered intelligence in another, which suggests the artificial intelligence language is marketing positioning rather than a description of a fixed technical component.

Graded D. Real models in the detection and classification layer, on a product whose value is visibility, enforcement and healthcare specific data integration.

The autonomy here can take clinical equipment off the network, which is a consequence no other record in this session carries.

The capabilities are enforcement rather than advice. Custom built security access and enforcement policy is applied per device, smart isolation restricts a device to authorised nodes only, and segmentation policies are described as dynamically enforced. Detection, investigation and response are described as automated across the clinical network. So the platform can act on a device rather than merely report on it.

That is the right capability and it carries a specific risk. Isolating an infusion pump, a ventilator or an imaging system because it looks anomalous can interrupt care, and the failure mode of an over eager security control in a hospital is not an inconvenience but a clinical event. The company shows awareness of this, describing its approach as delivering control without disrupting critical business processes and without impacting patient care, which is the correct instinct.

What is absent is any description of the controls that make that instinct operational. Nothing published states whether enforcement runs in monitor only mode by default, whether isolation requires human approval, whether clinical criticality gates automated action, or how a device is restored quickly when isolation was wrong. Operational criticality is captured as a risk input, so the data to gate enforcement exists, and nothing describes it being used that way.

The hybrid detection layer is a partial mitigation, since rule based detection is inspectable in a way a learned model is not.

Graded C.

Function and architecture are described concretely, the artificial intelligence claim is unstable across the company's own pages, and that instability is the finding.

What is well described is the mechanism at platform level. Discovery is agentless and reaches devices behind firewalls and serial gateways. Classification produces a logical taxonomy of medical assets. Risk assessment is stated as a multifactor score combining known exposures, attack potential and operational criticality, so the inputs are named. Communication patterns are visualised and used to design segmentation. Detection is characterised as artificial intelligence and rule based, which is a genuine architectural disclosure and a candid one.

The instability sits alongside it. The same descriptive sentence about the platform appears in one version combining discovery techniques with artificial intelligence powered intelligence, and in another combining them with cloud powered intelligence. Those are different claims about what the product does, published by the same company about the same platform, and a reader cannot tell which is current. The product naming compounds it, appearing as Medical Device Security, the CyberMDX Healthcare Security Suite, part of Forescout Continuum, part of the Forescout 4D Platform and as the Forescout Vistaro platform.

Below the architecture nothing is disclosed. No model type, no training data, no detection or classification accuracy, no versioning and no update cadence.

Graded C: good architectural description, an artificial intelligence claim a buyer should ask about directly rather than read off a page.

The product's own lineage is fully traceable, external data dependencies are visible, and the models are undisclosed.

The lineage is documented and unusually clear. The healthcare product was CyberMDX, an independent healthcare security company acquired by Forescout in 2022, and the company's own material still identifies it as formerly the CyberMDX Healthcare Security Suite. A buyer can therefore trace the technology to its origin, which matters because it establishes the product as healthcare native rather than a vertical adaptation of a general platform.

External data dependencies are identifiable by function even where not enumerated. Risk assessment consumes public vulnerability databases, FDA device class and recall data comes from the regulator, and manufacturer disclosure statements come from device makers. So the intelligence in the risk score is substantially assembled from external sources, and a reader can see which ones.

An integration partnership with another security vendor combining device intelligence with access controls names one downstream consumer of the platform's data.

What is absent is the models. No architecture, no training data, no framework, no third party component and no bill of materials for the artificial intelligence half of the detection layer. That omission is more pointed for a security vendor than for others in this index, because software supply chain transparency is something this company's own research effectively advocates, and it publishes nothing equivalent about itself.

Graded C.

Original security research at real scale, independent analyst assessment, and no published performance figures for the product itself.

The research is the strongest element and it is unusual for a vendor in any category. Vedere Labs, the company's research group, analysed more than two million devices across 45 healthcare delivery organisations over a defined period and published 162 vulnerabilities affecting connected medical devices, building on an earlier riskiest devices report. That is primary research on a large real world dataset, published rather than held, and it demonstrates both the scale of the deployed estate and a willingness to disclose findings that make the vendor's own customers' environments look exposed.

Independent assessment exists from two analyst firms. The company participated in the KLAS Healthcare IoT Security 2026 report with its healthcare clients interviewed directly, which is customer sourced evaluation rather than vendor submission, and it appears in the 2025 Gartner market guide for medical device risk management platforms. A third party comparison of the category places it among the established vendors while noting that healthcare specialised competitors generally provide deeper medical device classification and clinical context risk scoring than general platforms.

What is absent is any measured performance for the product. No detection accuracy, no false positive rate for the hybrid detection layer, no classification accuracy for the automatic device taxonomy, and no outcome study on risk reduction. The research proves the company can find vulnerabilities; it does not establish how well the deployed platform detects or classifies.

Graded B on the strength and scale of the published research and the independent analyst coverage.

The data this platform collects is unusual for this index and the governance around it is undescribed.

What it holds is not patient records but something a hospital may guard just as closely: a complete, continuously updated map of every connected device on the clinical network, its configuration, its vulnerabilities, its communication patterns and its utilisation. That is a blueprint of an organisation's attack surface, and in the wrong hands it is more immediately dangerous than a set of patient records. Nothing published describes retention, segregation between customers, or what the vendor may do with it.

The research programme raises the question concretely rather than hypothetically. Vedere Labs analysed more than two million devices across 45 healthcare delivery organisations and published the findings, which is valuable work and necessarily drew on data from deployed customer environments. Whether customers consented, whether the analysis used aggregated or identifiable environment data, and whether participation was opt in are unstated. Publishing vulnerability research derived from customer networks is a legitimate practice with an established convention of consent, and the convention is not described here.

The cloud architecture adds a further path, with healthcare capabilities described as built into the company's cloud platform over three years, so environment telemetry leaves the hospital.

On patient data specifically the exposure is likely limited, since asset intelligence works on metadata rather than payload, and nothing states that either way.

Graded C rather than lower because the research is published openly rather than conducted quietly, and lower than it might be because the terms are absent.

The product is built around a healthcare compliance artefact, which is more than most records here manage, and the vendor's own contractual posture is unpublished.

The substantive element is manufacturer disclosure statement integration. That form is the standardised document describing how a medical device handles electronic protected health information, and integrating it into the platform means a hospital sees a device's declared data handling alongside its live risk posture. Building the compliance artefact into the product is a meaningful design decision rather than a marketing claim, and it addresses the exact workflow a hospital technology management team performs.

The company also publishes material on meeting health privacy statute requirements by protecting electronic protected health information, medical devices and networked assets, so the regulatory framing is present.

What is not published is the vendor's own position as a processor. This platform observes network traffic across a clinical network, which means it sees communications between devices that carry patient data, and it builds a persistent inventory of a hospital's entire connected estate. Whether it captures payload or only metadata is not stated anywhere located, and that distinction determines whether the vendor handles protected information at all. No business associate agreement is offered or described, no data handling summary exists and no retention position is stated for the asset intelligence a customer's environment generates.

The cloud element sharpens it, since the platform is described as cloud powered with capabilities built into a cloud platform, so environment data leaves the hospital.

Graded C.

A security vendor with a genuine research programme and no published assurance about itself, which is the notable asymmetry on this record.

What exists is substantial and is directed outward. Vedere Labs conducts and publishes original vulnerability research at scale, including analysis of more than two million devices across 45 healthcare delivery organisations yielding 162 disclosed medical device vulnerabilities, alongside recurring reports on riskiest connected devices and operational technology flaws. A company running a named research group that publishes findings, including findings about its own customers' environments, is demonstrating security competence in the most direct way available.

What is absent is assurance about the platform itself. No trust centre, no service organisation control report, no information security management certification, no penetration testing statement for its own product, no vulnerability disclosure policy governing reports against Forescout, and no subprocessor list were located in what was examined.

That gap is sharper here than on a clinical record. A security platform holds a map of its customer's entire attack surface and can enforce isolation on clinical equipment, so compromising it would be more valuable to an attacker than compromising most of what it protects. The question a hospital security team should ask a security vendor is what assurance the vendor offers about itself, and this record does not answer it publicly.

Graded C rather than lower because the research programme is real, published and verifiable, and it is evidence of capability even though it is not assurance about controls.

No clearance is required and the product is unusually well oriented to the regulatory environment its customers live in.

On its own account the platform is enterprise security software observing and controlling network traffic. It makes no clinical claim, produces no diagnostic output and does not modify device function, so device regulation does not apply to it. That is straightforward and correctly unclaimed.

What lifts this above a bare pass is that the product is built around regulatory data rather than merely coexisting with it. FDA device class and recall status are tracked alongside cyber exposure, so a biomedical team sees a device's regulatory standing and its security posture in one view, and recall tracking in particular is a compliance obligation hospitals struggle to operationalise. Manufacturer disclosure statement integration brings the standardised device security form into the workflow. Together those mean the platform speaks the regulatory language of the department that owns the equipment.

The company also publishes guidance on meeting health privacy statute obligations through device and network protection, and appears in analyst coverage of medical device risk management platforms, a category defined by regulatory pressure on hospitals.

The wider regulatory context is the reason this market exists at all. Premarket cybersecurity requirements now apply to connected medical devices, and hospitals carry corresponding obligations for the estate they operate, so the product sits inside a live and tightening regime.

What is not addressed is any position on the emerging expectations for artificial intelligence in security tooling, or on how automated enforcement interacts with a hospital's own device management obligations.

Graded B.

Nothing was located. No model card, no training data description, no detection accuracy or false positive rate, no classification accuracy and no bias statement.

The bias framing in this lane is not demographic and is worth stating precisely, because a reader could otherwise assume the axis does not apply. It applies through the device estate. Automatic classification into a taxonomy and risk scoring will perform best on common, modern, well documented equipment from major manufacturers, and worst on old, rare, regionally specific or heavily customised devices. Hospitals with older estates are disproportionately rural, safety net and under resourced, so a platform that classifies their equipment poorly, scores it inaccurately or misidentifies its behaviour as anomalous delivers less protection and more false alarms to the organisations with the least capacity to absorb either.

The same mechanism runs through enforcement. If anomaly detection is calibrated on typical device behaviour, unusual but legitimate equipment is more likely to be isolated, and the clinical consequence of isolating a device falls on the patients being treated with it.

Nothing published examines classification or detection performance across device age, manufacturer, modality or estate composition, and no coverage figure is given for how much of a typical estate the taxonomy recognises.

The company clearly has the data to answer this, having analysed more than two million devices across 45 organisations for its published research.

Graded D on the absence, with the mechanism named because it is not the one this axis usually catches.

Nothing published addresses responsibility for an automated outcome, and this platform can act on clinical equipment.

The exposure runs in both directions and both are consequential. A false negative means a compromised device stays on the network, which is the harm the product exists to prevent. A false positive that triggers smart isolation removes a medical device from the network, and if that device is delivering care the consequence is clinical rather than operational. Automated detection, investigation and response across a clinical network is exactly the capability that makes both possible at speed and at scale.

The company acknowledges the risk in its positioning, describing control delivered without disrupting critical business processes and without impacting patient care. That is the right recognition and it is a design intention rather than a commitment. Nothing published states accuracy commitments for detection or classification, indemnity, limitation of liability, or what recourse a hospital has if an automated action interrupts care.

The hybrid detection architecture creates a further unaddressed division. When detection is artificial intelligence and rule based, a hospital investigating why a device was isolated needs to know which component fired, and nothing describes whether that is exposed.

A third party comparison notes that healthcare specialised competitors generally provide deeper clinical context risk scoring than general platforms, which if accurate bears directly on how well the criticality of a device is weighed before enforcement acts on it.

No indemnity, warranty, service level or recourse route was located. Graded D.

Interoperability here runs toward security and biomedical systems rather than toward the clinical record, and within that scope it is well specified.

The distinctive integration is the manufacturer disclosure statement, the standardised medical device security form. Ingesting it means the platform reconciles a manufacturer's declared security characteristics against the device's observed behaviour on the network, which is a genuine data integration serving a real workflow rather than a checkbox. FDA class and recall status ingestion is a second external data integration on the regulatory side.

The enforcement side integrates outward into network infrastructure, since segmentation, access policy and isolation require the platform to act through switches, firewalls and network access control, and the company's wider platform is built on that capability. A partnership integrating device intelligence with another vendor's access controls indicates the asset data is designed to be consumed by other security tools rather than held.

The utilisation dashboards imply integration with biomedical asset management, addressing inventory and maintenance workflows.

What is absent is the clinical record entirely, and here that is correct scope rather than a gap. A device security platform has no reason to write to a chart. It does mean the interoperability assessed on this axis is with a different set of systems from every other record in this session, and a reader comparing grades should read it that way.

No interoperability standard is named and no application programming interface is published, which is the specification gap holding this at B.

The deployment shape is the best documented of any record in this session, and the residency specifics are absent.

What is clear is the architecture. The platform is agentless, which is the defining deployment property for medical device security because regulated devices cannot accept installed software and hospitals may not modify their configurations. Discovery operates from the network rather than from the endpoint, reaching devices behind firewalls and serial gateways. Deployment involves appliances, available in virtual and physical form, so a hospital knows it is placing infrastructure on its own network. Enforcement acts through existing network controls rather than through anything installed on the device.

That combination tells a buyer more about what implementation actually involves than most records here disclose.

The cloud element is where the specifics stop. The company describes investing in healthcare capabilities within its cloud platform over three years and characterises intelligence as cloud powered, so environment data leaves the hospital for processing. Nothing states which cloud, which region, what residency options exist, what subprocessors are involved, what is retained or what happens at contract end.

That matters more than usual because of what the data is. A continuously updated inventory of a hospital's connected estate, its vulnerabilities and its communication patterns is a sensitive asset in its own right, and where it lives is a fair question.

No availability commitment was located for a platform capable of enforcing isolation on clinical equipment.

Graded C.

A third party pricing floor exists, the structure is described, and nothing comes from the vendor.

What is available is an outside characterisation of the model: enterprise pricing based on appliances and software licences, with virtual appliances starting around $3,701 and physical appliances around $4,995. Those figures come from a third party software directory rather than from Forescout, and they describe the general platform rather than the healthcare product specifically, so they establish an order of magnitude for a component rather than a price for what a hospital would buy.

The structure disclosure is more useful than the numbers. Appliance plus licence tells a buyer this is infrastructure with capital and recurring elements, and that scale is driven by network size rather than by device or patient counts. For a hospital estimating cost across a multi site network that is the shape of the answer even without the rate.

What is missing is everything from the vendor. No pricing page, no licensing basis for the healthcare product, no statement of whether medical device security is a separate purchase from the wider platform or a module within it, and no indication of how the utilisation and biomedical capabilities are licensed. That last question matters because those features serve a different department with its own budget.

The naming instability compounds it. With the product presented variously as Medical Device Security, part of Continuum, part of the 4D Platform and as Vistaro, a buyer cannot be confident which licence covers which capability.

Graded C.

Coverage of the connected estate is the product, and it extends further than any competitor claim in this lane.

The asset range spans the full hospital network rather than medical devices alone: information technology, operational technology, general internet connected equipment and internet of medical things devices, with named examples running from infusion pumps and heart monitors to imaging systems. Building management systems fall in scope for the wider platform. That breadth matters because attacks reach clinical devices through the building and enterprise networks, and a platform seeing only medical devices sees only part of the path.

Discovery depth is the distinguishing claim. Devices behind firewalls and serial gateways are explicitly included, and serial connected equipment is exactly the legacy population that ordinary network discovery misses and that hospitals cannot replace.

The agentless approach is what makes the coverage real rather than aspirational. Medical devices cannot accept security agents, they are regulated configurations that a hospital may not modify, so any approach requiring installation covers nothing. Agentless is the only architecture that works here and the company built for it.

User coverage extends past the security team to biomedical engineering and clinical engineering, with utilisation dashboards, inventory management and maintenance cost reduction aimed at a department that does not usually get served by a security product.

Organisational reach is documented through research across 45 healthcare delivery organisations and analyst coverage describing a track record among hundreds of healthcare providers.

Graded A.