Whenever a hospital ransomware incident is disclosed, the entrance named is an internet-facing device: a VPN appliance, a remote access gateway, a maintenance link. The structure is consistent — either a fix had already been published but not applied, or an out-of-support device remained in service.
This is less a problem of not knowing than of operations that are not running. The information is public. The vendor sent a notice. But a hospital runs around the clock, reboots are hard to schedule, and "we can't take it down right now" accumulates into months and years.
This article is about rebuilding those operations — not configuration steps, but a routine that limited staff can sustain. It avoids attack methodology and is written from the defender's side.
Disclaimer: This is general information. Guideline interpretation and reimbursement requirements are governed by the relevant ministries' publications; device-specific remediation by the vendor's official information.
Why Perimeter Devices Become the Entrance
Three properties set them apart.
1. By definition they are reachable from outside
A VPN appliance exists to be connected to from outside. Internal servers can be protected by segmentation; for a perimeter device, external reachability is the specification. Once a vulnerability is public, the search for exposed instances begins worldwide.
2. Some flaws are exploitable before authentication
Where that is the case, strong passwords and multi-factor authentication do not help, because the attacker arrives before authentication does. That is precisely why patching cannot be substituted for.
3. "It's working, don't touch it" is strongest here
Taking the perimeter down stops remote maintenance and home working at once. The breadth of impact makes agreement hard, which paradoxically leaves perimeter devices further behind than internal servers.
Hospitals add a further problem: ownership is ambiguous. A maintenance link installed by the EMR vendor, a circuit laid by a departmental system supplier, a device rushed in for remote working. Different origins mean scattered responsibility.
Start by Inventorying Assets
The first step is not product selection but enumerating what faces the internet.
| Category | Examples | Why it gets missed |
|---|---|---|
| Remote access | VPN appliances, RDP gateways | Usually managed, but legacy configurations linger |
| Maintenance links | Vendor circuits, remote maintenance devices | Installed by the vendor, so absent from the internal register |
| Public servers | Website, booking systems, file exchange | Operated by a supplier, invisible internally |
| Network equipment | Routers, firewalls, UTM | Management interfaces sometimes exposed |
| Office equipment | MFPs, UPS, cameras, door access systems | Not recognised as information systems |
| Medical devices | Equipment with remote maintenance | Managed as medical devices, absent from the IT register |
The last two rows are the most commonly missing. An MFP or a camera "isn't IT's remit" — but once networked with a management interface, it carries perimeter risk.
What the register must hold
| Field | Why |
|---|---|
| Model and firmware version | To judge applicability the day a vulnerability is published |
| Purpose and owning department | To assess the impact of taking it down |
| Internal responsible person | So someone can decide |
| Maintenance provider and contact | So remediation is not delayed by hunting for a phone number |
| Support contract and expiry | To settle cost arguments in advance |
| End-of-life date | To get replacement into the budget cycle |
| External reachability path | To decide on emergency disconnection |
Firmware version and EOL date are never consulted on a quiet day, yet they decide whether you can answer "does this affect us?" on the day it matters. Judge your register on that alone.
This work is inseparable from segment design — see Segmentation and Asset Management — and its place in the wider ordering is set out in Ransomware Defence for Hospitals.
Patch Operations That Do Not Stall
"Respond immediately to critical vulnerabilities" is a correct policy and not yet an operation. Without deciding who receives the information, who judges impact, and who sets the work date, decisions stall.
- Consolidate the intake. One address or desk for vendor notices and public advisories. Notices landing in an individual's mailbox break on transfers and leave
- Write the severity criteria in advance. For example, "externally reachable and potentially exploitable before authentication" is top priority
- Book maintenance windows in the calendar. Monthly or quarterly, reserved ahead. Arranging one ad hoc costs weeks in scheduling alone
- Name who can order disconnection. When a fix will not arrive in time, someone must be able to pull the external link. Decide that authority while things are calm
| Severity | Condition | Target response |
|---|---|---|
| Critical | Externally reachable / exploitable pre-authentication / exploitation observed | Act without waiting for the window; consider disconnection |
| High | Externally reachable but post-authentication / workaround exists | Apply at the next window, workaround in the meantime |
| Medium | Reachable only internally | Apply at the regular window |
| Low | Limited reachability or minor impact | Bundle into the next refresh |
Adjust the bands to your situation. What matters is that they were written down beforehand — debating criteria on the day is already too late.
Note that figures circulating in secondary commentary for assessment frequency ("at least annually" and similar) cannot be confirmed from primary sources. When writing internal requirements, verify against MHLW publications and regional bureau notices (primary confirmation required).
Handling End-of-Life Devices
This is the hardest topic. Out-of-support devices receive no fix when a vulnerability is found — patching as a control simply does not exist for them.
They persist for clear reasons: replacement needs budget on an annual cycle; replacement may force changes to business systems; "it still works" keeps the priority low; and often nobody knows it is out of support.
| Option | What it means | When it fits |
|---|---|---|
| Replace | Move to a successor model | The default, where budget can be secured |
| Extended support | Buy extended maintenance | A bridge to replacement, where offered |
| Cut reachability | Stop external exposure, use internally only | Where external exposure is not essential |
| Remove | Stop using it | Where an alternative exists and it is no longer needed |
The fourth is more useful than expected. Links installed for historical reasons and barely used today are common; confirming actual usage and removing them eliminates risk at zero cost. Asset stocktaking surfaces these regularly.
For the budget case, the FY2026 revision helps. The Electronic Clinical Information Coordination Structure Development Addition sets guideline compliance and a dedicated medical information system safety management officer as common requirements, with tier 1 (160 points) adding multi-method backup and a cyber BCP with exercises. With security tied to reimbursement, it can now be presented as a requirement rather than a cost. See the FY2026 revision overview and Appointing a Safety Management Officer.
Why MFA Belongs Alongside Patching
| Control | Prevents | Does not prevent |
|---|---|---|
| Patching | Exploitation of device flaws | Use of leaked legitimate credentials |
| MFA | Entry with leaked credentials | Flaws exploitable before authentication |
Either alone leaves a hole. Credentials leak through phishing, reuse across services, and supplier paths; a connection carrying a valid ID and password is indistinguishable from legitimate use no matter how well patched the device is. Conversely, MFA does nothing against pre-authentication flaws — "we added MFA, so the VPN is safe" does not follow.
Start with remote access and privileged IDs. Rolling MFA out to all staff at once is operationally heavy, and shared terminals and emergency access raise difficulties specific to clinical settings — see Multi-Factor Authentication. The connecting device is covered in Endpoint Management, and narrowing what a session can reach in Access Control and Privileged IDs.
For vendor maintenance links, the contract and SLA should fix source addresses, permitted hours, and work records. Knowing what ISO/IEC 27001 (ISMS) requires of a supplier makes it easier to frame the questions.
Turning It Into an Annual Cycle
| When | Work | Output |
|---|---|---|
| Annually | Full stocktake of externally reachable devices | Updated asset register |
| Annually | EOL list and replacement budget | Medium-term refresh plan |
| Quarterly | Scheduled patching in the maintenance window | Application records |
| Quarterly | Review of outstanding vulnerabilities and deadlines | Status list |
| As needed | Handling "critical" items | Action and decision records |
| Annually | Rehearse the disconnection decision flow | Exercise record |
Keeping records matters less for audits than for surviving staff turnover. An estate where nobody knows what the previous administrator decided, and why, carries operational risk on a par with the vulnerabilities themselves.
Conclusion
- Disclosed incidents share known vulnerabilities in internet-facing devices and continued use of out-of-support equipment
- Perimeter devices are reachable by design, and some flaws are exploitable before authentication, so patching cannot be substituted
- Start by enumerating assets — vendor-installed maintenance circuits, MFPs, cameras, and medical devices with remote maintenance are the most commonly missed
- The register must carry firmware version and EOL date; its value is decided by whether you can answer "does this affect us?" on publication day
- Build operations from four decisions: single intake, pre-written severity criteria, pre-booked windows, and a named disconnection authority
- For EOL devices: replace, extend support, cut reachability, or remove. Removing links nobody actually uses is free risk reduction
- Patching and MFA protect against different things; either alone leaves a gap
If you need help mapping what sits at your perimeter, its end-of-life dates, and who is responsible for each, 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
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
- On the FY2026 Fee Revision | MHLW
Note: device-specific remediation is governed by vendor information; requirements on assessment frequency by MHLW publications and regional bureau notices.