Cynerio

Two of the three parts rest on models. Identifying what a device is from passive network traffic alone is a classification problem, since a clinical device announces itself inconsistently or not at all, and detecting an attack by behavioural anomaly means learning what normal looks like for that device type and flagging departures from it.

The third part is engineering rather than inference. Micro segmentation, policy enforcement and inventory reporting are network work that would function with far less intelligence behind it, and much of the buyer's day to day value sits there. That mix holds the grade at B.

The autonomy is real and the design around it is unusually thoughtful, which deserves saying plainly.

The system can quarantine a device that is behaving maliciously, immediately and without waiting for a person. In a hospital that is a consequential act, because the device may be attached to a patient. The company's stated answer is to separate containment from remediation: isolate the device at once so it cannot spread or be driven, then perform full remediation only when the device is not in use. That is clinical safety reasoning applied to a security control, and very little security tooling is built that way.

Held at B because nothing published states what a false positive costs in practice, whether containment can be configured to require human approval for particular device classes, or how a biomedical engineering team is notified when a device is isolated mid shift.

The mechanisms are named at a useful level: passive analysis, deep packet inspection, behavioural anomaly detection, micro segmentation, and a stated ability to operate from the first day of deployment rather than after a long learning period.

What is absent is any measure of how well the detection works. No detection rate, no false positive rate, and no description of how device classification is validated, which matters because misidentifying a device type propagates into the risk score and the segmentation policy built on top of it.

The mechanisms are named at a useful level and the exposure they create is structural, which is the substantive point on this record. Passive analysis, deep packet inspection, behavioural anomaly detection and micro segmentation are each identified, with a stated ability to operate from the first day rather than after a long learning period, so a buyer can reason about what the system does.

Deep packet inspection on a clinical network means the platform sees the traffic on that network, and clinical network traffic carries patient information moving between devices and systems. One module is built explicitly on that capability, mapping where protected health information is exposed and monitoring access patterns.

So the tool that finds the exposure is itself positioned to see everything exposed, which is a legitimate design and an unavoidable one for the function, and it makes the vendor a party with unusually broad visibility rather than a narrow integration. What is absent is what follows from it.

Nothing published states what the platform retains from what it inspects, whether payloads are stored or only metadata and derived signals, how long anything persists, who at the vendor can reach it, or whether any of it leaves the customer environment. No model, hosting arrangement or sub processor list was located either. Ask what is retained from inspected traffic, in what form, and who can access it.

The company's best known research establishes the size of the problem rather than the effect of the product, and the distinction matters.

With the Ponemon Institute it surveyed leaders at 517 United States health systems and reported that 71 percent rated connected device risk as high or very high while only 21 percent considered their protections mature, alongside reported increases in bed days, mortality, affected procedures, transfers and complications among organisations that suffered attacks. That work is now cited in the professional literature, which is a real external marker, and it is survey research commissioned by an interested party measuring the market's condition rather than the vendor's effect on it.

No published deployment outcome, detection performance or before and after comparison at a customer was located. Acquisition by a larger platform for a reported sum above 100 million dollars is a market judgement rather than a clinical one.

Graded on an honest basis, and the exposure here is structural rather than incidental.

A product that performs deep packet inspection on a clinical network sees the traffic on that network, which includes patient information moving between devices and systems. One module is explicitly built on that capability, mapping where protected health information is exposed and monitoring access patterns. So the tool that finds the exposure is itself positioned to see everything exposed.

That is a legitimate design and it raises the obvious question, which is what the platform retains from what it inspects, whether payloads are stored or only metadata, and who at the vendor can reach it. Nothing published answers it.

Graded on an honest basis. No compliance statement or agreement posture was located in this pass.

The acquisition adds a question a buyer should ask directly rather than assume: whether the agreement now sits with the acquiring platform, what changed in it, and whether data collected under the original arrangement is available to the wider business.

Recorded honestly and provisionally: the dedicated trust and security search this index requires was not run in this pass, and no attestation was encountered incidentally.

That gap is worth flagging without irony rather than with it. A security vendor's own certifications are ordinarily among the easiest things to find, and a buyer evaluating a product that will sit on the clinical network with visibility into everything should insist on seeing them before anything else. Membership of a major platform vendor's security association implies technical review of the integration, which is not the same as an attestation of the company's own controls.

No device authorisation applies to the security platform itself, and there is a boundary here that this index has not previously recorded.

The devices being protected are regulated. A cleared medical device is authorised in a specific configuration, and manufacturers commonly constrain what may be changed on it. A security product that patches, segments or quarantines such a device is acting on a regulated object, and the practical questions are whether patching affects the device's cleared status and who carries responsibility if containment interrupts a clinical function.

The surrounding regime has also tightened: manufacturers now face explicit cybersecurity obligations at submission, which shifts some of this burden upstream over time but does nothing for the installed base of legacy devices that is the whole reason this category exists.

Nothing published on evaluation, monitoring or error handling.

The failure mode specific to this product is a false positive with clinical consequences. If behavioural anomaly detection misreads an unusual but legitimate pattern, the response is to isolate a device, and the devices most likely to behave unusually are the oldest and least standard ones, which are disproportionately found in the hospitals with the least money to replace them. A detection system tuned on modern estates will generate more false alarms in exactly the settings least able to absorb the disruption.

Nothing published addresses detection performance across device age, manufacturer or hospital size, and no monitoring or appeal process for an automated containment is described.

Two passes located no detection rate, no false positive rate, no validation methodology for device classification and no warranty, indemnity or remediation commitment. The classification gap is the one that matters most here because errors do not stay where they are made.

Device identification feeds the risk score, and the risk score feeds the segmentation policy built on top of it, so a device typed wrongly at the first step produces a wrong risk rating and then a wrong network policy, and each stage inherits the error while looking like an independent judgement. The failure directions are both consequential and neither is countable from anything published.

A clinical device wrongly typed as low risk and segmented permissively is an opening nobody is looking at. A device wrongly typed as high risk and segmented tightly can lose the connectivity it needs to function, and in a clinical setting that is a patient safety event arising from a security control.

Nothing describes how classification is validated, what proportion of devices are typed by inference rather than by a definitive identifier, or what a hospital sees about the confidence of a given classification. Ask for classification accuracy by device class, the false positive rate on anomaly detection, and what the vendor commits to when a segmentation policy breaks a clinical device.

The record system is not the integration target and the grade reflects that rather than penalising it. What matters here is the security and biomedical estate: the platform integrates with a major cloud security operations product, belongs to that vendor's security association, and is designed to slot into a managed security provider's stack.

The biomedical engineering connection is the one that would matter most to a hospital and is least described. A device inventory that does not reconcile with the biomedical asset register produces two conflicting sources of truth about the same equipment, and nothing published addresses that reconciliation.

Not described in detail. The product observes network traffic passively, which implies sensors or taps inside the hospital estate rather than an agent on each device, and that is the correct architecture given that agents cannot be installed on most clinical equipment.

What is not published is where analysis happens, what leaves the site, or how long captured data is retained. For a system inspecting clinical network traffic those are the first questions and they are unanswered.

Nothing published: no price, no mechanism, no unit of sale.

The natural unit in this category is the connected device or the bed, and the difference matters because device counts per bed vary enormously between a community hospital and an academic centre. Independent commentary positions this product as a good fit for smaller health systems, under 500 beds, which makes the absence of a published entry price more consequential: those are precisely the buyers least able to run a long procurement to discover it. Ask for the per device or per bed rate, and establish separately what changed commercially after the acquisition, including whether the product can still be bought standalone.

Purpose built for one setting and complete within it. The scope is the hospital estate rather than the enterprise generally, covering information technology, operational technology, general connected devices and connected medical devices in a single inventory, which is the combination that distinguishes healthcare from other environments.

It is specialty agnostic by nature, since the estate spans every department, and independent commentary identifies smaller health systems as a particular fit, which is a useful counterweight in a category whose largest vendors orient to the biggest academic centres. Held at B because coverage is the provider estate only, with nothing addressing manufacturers, payers or the wider supply chain, and the healthcare only focus that is its strength also bounds it.