MDS2 data turns medical device segmentation into operational policy

At a glance

What this is: This article argues that MDS2 documentation can be operationalised into identity-based microsegmentation policy for connected medical devices, turning static device security disclosures into enforceable controls.

Why it matters: It matters because healthcare teams need a way to contain vulnerable devices, reduce lateral movement, and protect clinical workflows without creating patient-care disruption.

By the numbers:

• Twenty-two percent 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.
• Security teams may need 4-16 weeks to turn MDS2 data into dynamic policies that protect devices without clinical disruption.
• Healthcare organizations are achieving medical device security in weeks rather than the traditional 12-18 month implementation timelines.

Context

MDS2 is a medical device security disclosure standard, but the operational problem is not collecting the forms. The real gap is translating vendor-reported capabilities and limitations into enforceable network policy for devices that cannot all be patched, replaced, or reauthenticated on human identity timelines.

In healthcare environments, segmentation has to protect clinical workflows as much as it protects the network. That makes device identity, communication paths, and compensating controls central governance questions, especially where legacy operating systems, default credentials, or unsupported firmware create persistent exposure.

This is typical for connected medical device programmes: the documentation often exists, but the control plane does not.

Key questions

Q: What fails when medical device segmentation is based on static network trust?

A: Static network trust fails because it treats whole subnets as safe even when individual medical devices have different authentication, encryption, and update capabilities. In healthcare, that creates unnecessary lateral movement paths and makes it harder to protect unsupported or vulnerable devices without affecting clinical communications.

Q: Why does MDS2 data matter for healthcare security governance?

A: MDS2 matters because it gives security teams manufacturer-declared detail on authentication, encryption, logging, and network requirements. That information lets organisations build compensating controls and microsegmentation policies around what a device can actually support, instead of assuming every connected device can meet the same control baseline.

Q: What breaks when medical devices cannot be reauthored through normal IAM controls?

A: When medical devices cannot join standard IAM or MFA processes, teams must govern them through network boundaries, device identity, and compensating controls instead of human identity workflows. If that shift does not happen, unsupported or default-configured devices become persistent exceptions that attackers can exploit.

Q: Should healthcare teams prioritise segmentation or device replacement first?

A: Teams should usually prioritise segmentation first when vulnerable devices cannot be replaced quickly, because containment reduces exposure while replacement plans are funded and scheduled. Where a device is clinically critical and unsupported, segmentation becomes the immediate control that lowers blast radius while longer-term remediation is planned.

Technical breakdown

Why MDS2 data matters for medical device identity and access control

MDS2, or Manufacturer Disclosure Statement for Medical Device Security, is structured disclosure about how a device authenticates, communicates, logs, encrypts, and updates. That matters because medical devices often behave like fixed-function identities on the network, with narrow permitted communications and weak or absent native controls. When teams turn those disclosures into policy, they move from abstract device inventory to explicit access logic. The security value is not in the form itself, but in the constraints it reveals about what the device can and cannot safely do.

Practical implication: treat MDS2 as an input to device access design, not as procurement paperwork.

How identity-based microsegmentation operationalises device policy

Identity-based microsegmentation uses device characteristics and observed behaviour to allow only the communications a device needs. In healthcare, that means policy can be built around device role, manufacturer constraints, clinical function, and actual network paths rather than broad subnet trust. This is materially different from legacy VLAN grouping, which often trusts whole zones and leaves lateral movement open. The key architectural shift is from perimeter thinking to per-device enforcement, with policy simulation used to avoid blocking clinical traffic.

Practical implication: define policies at the device identity level and simulate them before enforcement.

Why manual translation of MDS2 data becomes a governance bottleneck

MDS2 forms can contain hundreds of questions across many control categories, which makes manual conversion into firewall rules or NAC policies slow and inconsistent. The governance problem is not just scale, but variability: two similar devices may support different authentication, encryption, or update options, and compensating controls must reflect those differences. Where teams lack automation, they usually underuse the documentation or oversimplify it into coarse trust zones. That creates policy drift between what the manufacturer disclosed and what the network actually enforces.

Practical implication: automate MDS2 correlation and policy generation where device populations are large or highly mixed.

Threat narrative

Attacker objective: The attacker aims to move laterally across healthcare device networks, disrupt care, and exploit weakly governed medical device access paths.

1. Entry begins when a vulnerable or weakly protected medical device is placed on a flat or overly trusted network segment.
2. Credential abuse or security control weakness follows when devices rely on default credentials, unsupported firmware, or unencrypted communications that expand reachable attack paths.
3. Escalation and lateral movement occur when malware or an intruder can move from one device or clinical zone to another without microsegmentation boundaries stopping the spread.
4. Impact is measured in disrupted care delivery, patient safety risk, and broader exposure of protected health information or clinical systems.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MDS2-to-policy translation is the real control gap: healthcare organisations already possess the security data, but too often lack the mechanism to turn that data into enforced access boundaries. That is why the problem persists even when procurement teams collect disclosures correctly. The decisive issue is governance of enforcement, not absence of information. Practitioners should treat the translation layer as the control point, not the form archive.

Medical device segmentation is an identity problem, not just a network problem: connected devices have consistent roles, constrained communications, and known manufacturer limitations, which makes them suitable for identity-based policy. Flat networks fail because they trust the zone rather than the device. Once device identity is used as the policy primitive, teams can contain vulnerable monitors, pumps, and imaging systems without assuming they can all be remediated at the same pace.

Clinical safety changes the segmentation design standard: in healthcare, the question is never only whether a policy blocks attack paths. It is also whether it preserves the communications needed for patient care. That means policy simulation, cross-functional ownership, and compensating controls are not optional process extras. Practitioners should judge segmentation success by whether it reduces blast radius without introducing clinical friction.

Automated policy generation creates a stronger governance model than static review: when MDS2 data, device discovery, and network behaviour are correlated continuously, security teams can update controls as firmware, vendor support, or clinical use changes. This is especially important for legacy or unsupported devices that cannot satisfy modern human identity controls. The practitioner conclusion is clear: device governance must operate as a living policy system, not a one-time segmentation project.

MDS2 operationalisation defines a practical medical device security concept: disclosure-to-enforcement. This is the point at which manufacturer statements, clinical context, and network policy stop being separate artefacts and become one control workflow. That concept should shape how healthcare teams scope segmentation programmes, because without enforcement, disclosure does not reduce risk.

What this signals

Disclosure-to-enforcement is the governance problem healthcare keeps underestimating: having MDS2 forms is not the same as controlling device behaviour. Programme leaders should expect more pressure to demonstrate that manufacturer disclosures are being converted into actual segmentation rules, especially where legacy devices cannot be remediated quickly.

Medical device identity will matter more as clinical networks stay heterogeneous: the more mixed the device estate becomes, the less viable broad trust zones are. Teams should prepare for policy models that combine device identity, observed communications, and compensating controls rather than rely on subnet inheritance.

Healthcare segmentation programmes should be judged on blast-radius reduction, not technical neatness: the right outcome is a smaller attack surface with no disruption to care delivery. That means the operational bar is whether vulnerable devices are isolated well enough to contain abuse while preserving the communications clinical teams depend on.

For practitioners

• Map MDS2 disclosures to enforceable device policy Convert manufacturer-reported capabilities, limitations, and supported protocols into explicit allowlists for each device class, then tie those policies to actual observed traffic.
• Segment by device role and clinical context Group devices by function, location, and criticality rather than by broad subnet trust, so vulnerable monitors, pumps, and imaging systems do not share the same trust zone.
• Simulate policies before enforcement Test proposed microsegmentation rules against live traffic to confirm that required clinical communications continue to work before any restrictions are turned on.
• Prioritise unsupported and weakly authenticated devices Focus compensating controls first on devices with legacy operating systems, default credentials, or unencrypted communications because those conditions create immediate exposure.
• Make segmentation a continuous governance process Reconcile MDS2 data, device inventory, and network behaviour on an ongoing basis so policy changes track firmware updates, replacements, and new vulnerabilities.

Key takeaways

• MDS2 is useful only when organisations convert disclosed device capabilities into enforceable segmentation policy, not when they leave the forms in procurement files.
• Healthcare device security is constrained by unsupported systems, default credentials, and variable communications requirements, which makes device-level governance more important than broad network trust.
• The strongest control outcome is containment that reduces lateral movement while preserving clinical workflows, because in healthcare safety and security are inseparable.

Key terms

• Manufacturer Disclosure Statement for Medical Device Security (MDS2): A standardised security disclosure form used by medical device manufacturers to describe device capabilities, limitations, and operational requirements. It gives healthcare buyers and operators comparable information about authentication, encryption, logging, patching, and network behaviour so they can design controls around real device constraints.
• Identity-based Microsegmentation: A segmentation approach that uses identity, context, and policy to decide whether a connection should be allowed inside a network zone. In OT, it helps reduce lateral movement without relying only on IP addresses or broad subnet rules.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• Clinical workflow integrity: The degree to which identity and access controls support patient care without forcing unsafe workarounds or breaking the sequence of clinical tasks. It is a practical measure of whether access design, auditability, and usability remain aligned under real bedside conditions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to operational risk across modern estates.