Tablet-based charting has spread to the wards, home-visit devices come back and sync on site, and patients ask whether there is Wi-Fi. Hospital wireless has quietly become infrastructure carrying both clinical work and patient service.
Whether anyone inside the institution can explain how it is configured is another matter. An access point was added during a building extension. The patient Wi-Fi was installed by a contractor. The password is printed on a sign in the waiting area. Each decision was reasonable at the time, and the accumulation can still leave you with clinical and guest traffic sharing the same equipment without real separation.
What makes wireless fundamentally different from wired networking is that the signal does not stop at the wall. How far it reaches into the car park or the neighbouring building is not a design boundary. Any design has to start from that physical fact and decide where to divide, what to authenticate with, and what to record.
This article sets out what to check when reviewing hospital wireless — emphasising configuration design and operations rather than product selection.
Disclaimer: This article is general information. The authoritative sources are the MHLW guidelines and related ministry publications. Base wireless configuration on your equipment's specifications and your own network architecture.
What Makes Hospital Wireless Different
The population is broad. Not only staff but patients, families, visitors, contractors, and students share the building. Wired access requires physically reaching a port; wireless invites a connection attempt from anyone within range.
The device mix is wide. Staff tablets, EMR viewing terminals, diagnostic equipment, nurse-call integrations, monitoring devices — differing in refresh cycle and in who owns them. See Securing Network-Connected Medical Devices.
It cannot be taken down. Stopping the clinical wireless stops ward charting. Configuration changes are hard to test against production, which sustains a "it works, don't touch it" equilibrium.
The MHLW's cybersecurity checklist for healthcare institutions and its accompanying manual, published on 14 May 2025, are more concrete than earlier material and added coverage of cloud, BCP, IoT, and BYOD — all of which bear directly on wireless design. See How to Use the MHLW Checklist and What the Three-Ministry Guidelines Are.
Separating Clinical From Guest
The first decision is network segmentation. Separate SSIDs are not separation; what matters is whether the networks behind them are separate.
| Segment | Purpose | Permitted devices | Permitted reach |
|---|---|---|---|
| Clinical | EMR and departmental systems | Hospital-managed devices only | Clinical servers; internet limited to what is required |
| Staff general | Reference lookups, business cloud services | Hospital-managed devices | Internet; no reach into clinical servers |
| Patient and visitor (guest) | Patient and family internet use | Unrestricted | Internet only; no reach into the hospital network at all |
| Devices and IoT | Diagnostic and monitoring equipment | Registered devices only | Only the destinations required |
The question is whether you have actually tested that guest cannot reach clinical. Separate SSIDs that converge onto the same network behind the same access point are not separated. Even a correct configuration can be defeated by cabling added during an extension or by equipment attached later.
The test is simple: from a guest-connected device, confirm you cannot reach clinical servers or management interfaces. Keep the result — it is also evidence for your compliance narrative. See Network Segmentation and Asset Management.
For the guest network itself, decide:
- Whether to block client-to-client traffic
- Whether connection requires accepting terms of use
- Whether to cap bandwidth, so guest use cannot affect clinical traffic
- What connection records you keep, and for how long
- Whether the password is posted publicly or rotated
As a baseline, only hospital-managed devices should be able to join the clinical wireless. A configuration where staff can attach a personal phone to the clinical SSID undermines the BYOD discussion below.
Choosing Encryption and Authentication
Treat encryption and authentication as two separate questions.
| Method | How identity works | Position in a hospital |
|---|---|---|
| No encryption / legacy ciphers | — | Do not use. If retained for old equipment, put it on the replacement plan |
| WPA2-Personal (PSK) | Everyone shares one pre-shared key | Workable for guest use. Not recommended for clinical — the key spreads and leavers still know it |
| WPA3-Personal (SAE) | Still a pre-shared key, with improved key exchange | Prefer this for guest use where equipment supports it |
| WPA2/WPA3-Enterprise (IEEE 802.1X) | Individual credentials per user or device | The target for clinical. Connections are attributable and can be revoked individually |
Aim for Enterprise (802.1X) on the clinical network, for operational reasons more than cryptographic ones:
- Connections are attributable to a device or person, which makes records meaningful
- On departure or loss you can revoke one device without changing everybody's password
- With certificates distributed to devices, users need not type a password at all
Staying on a pre-shared key for clinical wireless reaches the same dead end as a shared password: the set of people who know it only grows, until nobody can change it (Designing a Password Policy).
Migration needs an authentication backend, so sequence it:
- Make the guest/clinical separation solid — achievable now through configuration and testing
- Get the clinical PSK into a state where it can be rotated, with a process for departures
- Move to Enterprise alongside device and access point refreshes
- Combine certificate distribution with asset management (Managing Endpoints)
Do not forget the access points' own management interfaces. Default credentials still in place, or a management page reachable from anywhere on the clinical network, are common findings. Restrict where management access may originate and strengthen its authentication (Privileged ID Management).
Devices People Bring In
Whether staff may use personal phones for work is a question often left unanswered. Declaring a ban while the devices are in fact used for coordination is the usual state.
| Policy | What it means | What it requires |
|---|---|---|
| Prohibit | No personal devices for work or on hospital wireless | Alternatives supplied by the hospital; only declare what you can enforce |
| Permit narrowly | Specific uses only, on the staff general network | Stated permitted uses, technical limits preventing patient data handling, training |
| Permit under management (BYOD) | Work use allowed with device management in place | A management platform, loss procedures, and agreement on how far the hospital may reach into a personal device |
The middle option is the most common, and it needs real limits on storing patient information on personal devices. Photographing a wound or a monitor, or sharing patient details over a consumer chat app, usually happens out of good intentions. A prohibition works only when a workable alternative exists. See Designing Staff Security Training.
Devices brought in by contractors and students need a policy too: whether a maintenance laptop may join hospital wireless, which network if so, and what is checked beforehand. See Securing Remote Maintenance.
Radio Does Not Respect the Building Line
- An access point by a ground-floor window can reach the car park or the pavement
- Signal wraps between floors, allowing connections from places nobody planned for
- After an extension or a partition change, actual coverage diverges from the original design
| Measure | What it involves |
|---|---|
| Placement and transmit power | Adjust position and power for units near windows and external walls |
| Measuring actual coverage | Walk the perimeter and record where signal reaches; repeat after building works |
| Stronger authentication | Assume coverage cannot be fully controlled and defend by not letting anyone connect (Enterprise) |
| Detecting unauthorised access points | Periodically check for wireless equipment installed without approval |
| Retaining connection records | Record which device connected when, and review it (Log Management and Audit Trails) |
Do not make "no signal leakage" the goal. It is not achievable. The goal is that signal in range still cannot connect, and a connection still cannot reach clinical systems. The physical constraint is absorbed by authentication and segmentation.
Unauthorised access points deserve attention. A department with poor coverage may have installed a consumer device in good faith. Rather than reprimanding, ask why it was needed — dead spots, slow links — and solve it properly; that is what stops recurrence. At the same time, publish the rule for requesting equipment.
Making It Operational
| Activity | Suggested frequency | Owner |
|---|---|---|
| Inventory of SSIDs and network structure | Annually and after building works | IT lead |
| Verifying guest cannot reach clinical | Annually and after configuration changes | IT lead |
| Checking wireless firmware currency | Quarterly | IT lead / maintenance vendor |
| Reviewing management interface credentials | Annually | IT lead |
| Reviewing connection records | Monthly | IT lead |
| Perimeter coverage check | After building works | IT lead |
| Checking for unauthorised equipment | Annually | IT lead |
Firmware updates are the item most often skipped. Network equipment left unpatched against known vulnerabilities is a pattern that recurs across published incidents (Managing VPN Appliance Vulnerabilities). Because updates mean an outage, the practical answer is to book planned downtime into the annual calendar in advance.
The electronic clinical information coordination structure addition introduced in the 2026 revision requires, as a common condition, compliance with the guidelines and a dedicated medical information system safety management officer. Who performs the checks above should be settled as part of designing that role (The 2026 Fee Revision).
Conclusion
- Divide hospital wireless into clinical, staff general, guest, and device segments — and verify that the networks behind the SSIDs are actually separate
- Target Enterprise (802.1X) for clinical; a pre-shared key ends in the same dead end as a shared password
- Migrate in stages: guest/clinical separation first, then PSK manageability, then Enterprise at refresh
- Choose among prohibit, permit narrowly, or manage — and write it down. Pair prohibition with a usable alternative
- Radio does not stop at the wall. Do not chase coverage suppression; make in-range connections useless through authentication and segmentation
- Put inventory, coverage checks, firmware updates, and record review into the annual plan
Reviewing wireless touches building structure, refresh timing, and departmental workflow, so it cannot be settled on paper alone. If you need help starting from a picture of your current configuration, get in touch.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines for the Safe Management of Medical Information Systems, Version 6.0 (PDF) | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
- On the FY2026 Medical Fee Revision | MHLW
Note: recommendations on wireless encryption and authentication change as vulnerabilities are found and standards are revised. Check current guidance alongside what your equipment supports.