Network Segmentation and Asset Management: Knowing What Connects to What

The first obstacle in any hospital security discussion is not technical. It is that nobody can fully explain what is currently connected to what.

EMR, billing, laboratory, imaging, pharmacy, nutrition, rehabilitation — each introduced at a different time by a different supplier, with interfaces added as needed. Then networked medical devices, maintenance links, remote-working equipment, Wi-Fi. A diagram exists, last updated several years ago is a common state.

Paths you have not mapped can neither be defended nor disconnected during an incident. This article sets out segmentation thinking and the asset management it rests on, as a sequence a small team can follow.

Disclaimer: This is general information. Guideline interpretation and reimbursement requirements are governed by MHLW publications and regional health bureau notices.

Not Knowing Is the Biggest Risk

"We separate the EMR network from the internet network" is a common statement. On inspection, paths like these often turn up:

• A PC receiving laboratory instrument data sits on both networks
• A supplier has laid its own circuit to maintain a departmental system
• A Wi-Fi router brought in by staff for convenience is running
• An MFP is attached to both networks so it can accept print jobs from each
• An exception permits EMR terminals to reach one specific external site

None of these arose from malice. They are individual exceptions created out of operational need, each with a reason. The problem is that they were never recorded, and taken together the separation no longer holds.

This is exactly how ransomware spreads. Segmentation decides how far an attacker can reach from the first compromised machine — and one unmapped bridge undoes it.

The same problem appears during response. Deciding what to disconnect to halt the spread requires knowing the topology. Being unable to decide in the first hours is what makes incidents large. Within the layered model in Ransomware Defence for Hospitals, segmentation is the layer that limits blast radius.

Making the Asset Register Usable

Asset management comes before segment design. But most hospitals have already attempted a register once, and it sits built and no longer updated — either because it carried too many fields to maintain, or because nobody used it, so nobody had reason to update it. The design principle follows: keep only what is usable during an incident and on the day a vulnerability is published.

The bold field is the one that matters most here. General IT registers omit it, but verifying separation in a hospital demands it — it is how you explicitly manage the machines with a foot in more than one segment.

A workable stocktaking sequence:

1. Work back from the network equipment. Switch and firewall configurations reveal the skeleton: which segments exist and what attaches to them
2. Ask the vendors, in writing, which paths they use for maintenance. Connections absent from internal records surface here
3. Interview the departments — laboratory, radiology, pharmacy, nutrition. Equipment never registered as an IT asset lives there
4. Trace physically what remains unclear. Slow, but done once it becomes differential maintenance

Run this alongside the perimeter stocktake in Managing VPN Device Vulnerabilities — it is the same register.

Drawing the Segments

Two axes govern: the nature of what is protected, and how much external contact is genuinely needed.

Medical devices are the hardest case. Regulatory approval may fix the configuration, so an outdated OS often cannot be patched. Since the constraint cannot be removed, the design protects from the network side on the assumption that the device cannot be fixed: restrict its peers to the minimum, remove external reachability, and open the maintenance path only during a session. See Security for Networked Medical Devices.

Visitor Wi-Fi is also easily neglected. Where offered, its inability to reach any internal segment must be assured in configuration and re-verified periodically — equipment swaps and configuration changes can unintentionally restore reachability. See Wireless LAN Security.

A realistic path for an existing hospital:

1. Draw the current state — the reality, not the ideal
2. List every bridge between clinical systems and externally connected ones
3. Judge each: operationally necessary, or replaceable?
4. Drop the unnecessary bridges (almost free up to here)
5. For necessary bridges, restrict peers and direction
6. Put what remains into the refresh plan

Most of the benefit arrives by step 4. Simply removing legacy connections and unused exceptions narrows reachability substantially.

Controlling Internet Connectivity

Alongside segmentation sits the question of where you exit to the internet. Hospitals often state that EMR terminals have no internet access, while exceptions exist for drug information lookup, cloud departmental services, electronic prescriptions and online eligibility verification, software updates, and vendor monitoring.

Most are genuinely needed, so "block everything" is not the answer. Manage instead by registering exceptions and reviewing them periodically.

The review date matters most. Exceptions accumulate and are never removed, so holes multiply over time. Once a year, print the list and ask whether each is still needed.

For cloud services, add the responsibility split: see Cloud Security for Medical Institutions and the shared responsibility model. For the guideline context see The Three Ministries' Two Guidelines Explained, and for what suppliers are expected to maintain, ISO/IEC 27001 (ISMS).

Connecting to the Requirements, and What to Record

The Electronic Clinical Information Coordination Structure Development Addition created in the FY2026 revision requires, as common requirements, compliance with the safe management guidelines and a dedicated medical information system safety management officer. Tier 1 (160 points) adds multi-method backup with part held offline, and a cyber-attack BCP with exercises.

Segmentation and asset management underpin all of it:

• Holding part of the backup offline requires knowing the paths that reach the backup area (Backup design)
• Deciding what to disconnect in a BCP requires a current diagram (A BCP for cyber attacks)
• The safety management officer cannot decide without knowing what is where (Appointing a safety management officer)

See also the FY2026 revision overview.

Four records are worth keeping:

1. The network diagram, dated — an undated diagram produces wrong decisions
2. The asset register, meeting the required fields above
3. The list of permitted inter-segment traffic — what, in which direction, and why
4. The exception review log — when, by whom, what was confirmed

These are not audit paperwork. They are the assets that let a successor make decisions. Hospital IT teams are small, and this is where person-dependency bites hardest.

Conclusion

1. The biggest problem is not missing technology but not knowing what connects to what
2. Separation fails if even one unmapped bridge exists — typically individual exceptions built for real operational reasons and never recorded
3. Keep the register small enough to maintain, and always include "connections to other segments"
4. Segment into EMR, billing, departmental, medical devices, administrative, visitor Wi-Fi and management. Protect medical devices from the network side, assuming they cannot be patched
5. Migrate in stages: draw the reality → list the bridges → drop the unnecessary ones — almost free, and highly effective
6. Manage internet access by registering exceptions and reviewing annually, not by blanket blocking
7. Segmentation and asset management underpin backup, BCP and the safety management officer's decisions alike

If updating the diagram or framing questions for your vendors is where you are stuck, contact us.

References and Sources

• Guidelines for the Safe Management of Medical Information Systems | MHLW
• Guidelines for the Safe Management of Medical Information Systems, Edition 6.0 | MHLW
• On the FY2026 Fee Revision | MHLW
• Information-technology Promotion Agency (IPA)

Note: guideline interpretation and reimbursement requirements are governed by MHLW publications and notices, and change with revisions.