What should healthcare organisations do when a vendor can see devices but cannot enforce policy?

Why Discovery Without Enforcement Is Only Half the Job

Seeing devices, agents, or endpoints is useful for inventory, exposure analysis, and change detection. It is not enough to claim policy control. In healthcare environments, the practical test is whether the control can actually shape traffic, isolate risky pathways, and show that segmentation is being enforced consistently, not just observed after the fact.

A visibility-only control can help teams find unmanaged assets, unexpected east-west paths, and misaligned trust assumptions. It cannot by itself prevent a compromised system from reaching protected workloads or constrain movement once a device is already on the network.

What the Missing Enforcement Layer Has To Do

The missing piece is an enforcement mechanism that sits on the decision path and can block, allow, or constrain communication in real time. That layer should be able to turn discovery data into policy decisions, then prove those decisions are being applied at the network, workload, or application boundary rather than relying on manual review.

This matters because segmentation is not a report, it is a runtime condition. If the vendor can only detect that a device exists, but cannot restrict traffic flows or validate policy outcomes, the organisation still has a blind spot between knowledge and control. For NIST Cybersecurity Framework 2.0, that gap sits squarely between identifying assets and protecting them.

Healthcare teams should expect an enforceable design to answer three questions: what is being allowed, where the control is enforced, and how the result is verified. If those answers are unclear, the architecture is still incomplete.

What Good Looks Like in Practice

Good practice is to use vendor visibility as input to an independently enforced segmentation control. That may be network-based, host-based, or policy-based, but it must be able to deny unwanted flows without relying on the vendor to make the final decision.

When the environment includes cloud, hybrid, or multi-system dependencies, a useful benchmark is whether the organisation can map device discovery to a control domain and then validate that policy survives change, drift, and exception handling. The CSA Cloud Controls Matrix is one way to anchor that mapping for IAM, infrastructure, and vendor risk.

For vendor assurance, teams should also check whether the supplier’s claims are limited to observability or extend to enforcement evidence. A third-party product that only reports posture may still be useful, but it should not be mistaken for a segmentation control. The same distinction appears in SOC 2 Trust Services Criteria when organisations evaluate whether a service provider can support security commitments in practice.

Risk and Threat Considerations

In healthcare, visibility without enforcement creates a false sense of control. A vendor may know what is present on the network, but if it cannot stop lateral movement, constrain access paths, or verify isolation, a compromised device can still reach clinical or administrative systems.

Failure mechanism: Discovery tools often operate out of band, while effective segmentation requires inline or otherwise enforceable control over live traffic. When those two functions are separated, the organisation can detect risk without being able to reduce it.

Impact: That gap increases exposure to unauthorized access, propagation after compromise, and policy exceptions that persist longer than intended. In regulated environments, it can also undermine assurance claims made to auditors, partners, and internal governance teams.

Practitioner Guidance

What to verify: Confirm that the vendor can show a live enforcement path, not just a discovered device list. Ask for evidence that a policy change produces a measurable traffic decision, and that denied flows remain denied after routine operational change.

Decision rule: If the product can only identify endpoints or recommend segmentation, treat it as a visibility or risk-intelligence control. If it can also constrain permitted flows and prove the result, it may qualify as part of the enforcement architecture.

What practitioners underestimate: Many organisations overvalue discovery because it is easier to demonstrate than enforcement. The real question is not whether the vendor can see the environment, but whether the control can still hold when a device is compromised, relocated, or reclassified.

Practitioner takeaway: In healthcare, visibility is a prerequisite, not the control objective; do not accept any segmentation design unless it can enforce policy at runtime and produce evidence that the enforcement actually works.

Related resources from NHI Mgmt Group

• What breaks when organisations can see AI tools on endpoints but cannot enforce policy at runtime?
• What breaks when organisations cannot see AI agents across devices and browsers?
• What should organisations do when their AI monitoring stack cannot enforce policy?
• What happens when healthcare organisations cannot audit shared mobile devices properly?