Notifications
Clear all
Topic starter
11/07/2026 8:26 pm
TL;DR: MDS2 documentation can be converted into identity-based microsegmentation policies that protect connected medical devices in 4 to 16 weeks, helping healthcare teams reduce lateral movement and preserve clinical workflows, according to Elisity. The governance challenge is not data availability, but operationalising device security intelligence into enforceable policy without creating patient-care disruption.
NHIMG editorial — based on content published by Elisity: How to Use MDS2 Data for Network Segmentation and Medical Device Security
By the numbers:
- 22% of healthcare organizations experienced medical device cyberattacks in the past year, and 75% of those incidents directly affected patient care delivery.
- MDS2 provides standardized cybersecurity documentation covering 23 control categories for medical devices.
- Healthcare organizations are achieving comprehensive medical device security in 4-16 weeks without clinical disruption.
Questions worth separating out
Q: What fails when MDS2 data never reaches enforcement policy?
A: MDS2 becomes a paperwork exercise instead of a security control.
Q: When should healthcare teams prioritise microsegmentation over broad network redesign?
A: Teams should prioritise microsegmentation when devices cannot be easily patched, replaced, or moved into separate physical networks without clinical disruption.
Q: What do security teams get wrong about medical device security documentation?
A: They often treat documentation as proof of security rather than input to control design.
Practitioner guidance
- Map MDS2 fields to enforceable controls Build a mapping between MDS2 categories such as authentication, encryption, logging, patching, and network communication and the specific segmentation rules your tools can enforce.
- Prioritise high-risk device classes first Start with devices that are clinically critical, unpatched, or known to rely on weak authentication and broad network reach.
- Simulate before enforcement Test proposed policies against observed device traffic before turning them on in production.
What's in the full article
Elisity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step workflow for converting MDS2 disclosures into segmentation policies across device classes.
- Implementation detail on using discovery platforms to match live devices to manufacturer documentation.
- Policy simulation and validation methods for avoiding disruption to clinical traffic.
- Practical rollout guidance for healthcare environments trying to move from documentation to enforcement.
👉 Read Elisity's analysis of how MDS2 data drives medical device segmentation →
MDS2 data and medical device segmentation: what changes for teams?
Explore further
11/07/2026 8:56 pm
MDS2 is only useful when it becomes a control input, not a compliance artefact. Healthcare already has enough device disclosure data to make better decisions, but most programmes still leave that intelligence in procurement files and spreadsheets. The problem is not visibility alone, it is policy translation. When manufacturer disclosures do not flow into enforcement, risk remains static and attackers inherit the gap.
A question worth separating out:
Q: Who is accountable when a segmented medical device still exposes patient care risk?
A: Accountability usually sits with both security and clinical engineering because the control spans network policy and operational safety. Governance should define who approves segmentation changes, who validates device behaviour, and who owns exceptions when a device cannot meet the intended control standard.
👉 Read our full editorial: MDS2 data turns medical device segmentation into operational policy
