Electronic medical records, departmental systems, diagnostic equipment, reception terminals. Almost everything running inside a hospital is operated on the assumption that a vendor will maintain it. When something breaks, waiting for an engineer to travel to site stops care, so having a path for remote investigation and recovery is entirely reasonable.
The question is whether that path has become usable by anyone, at any time, from anywhere. An opening created at installation "because maintenance needs it" stays open for years. Nobody can confirm afterwards whether the person who connected really was the vendor's engineer, or what they did. The contract describes the scope of maintenance but says nothing about how connections are made or how records are handled. None of this is unusual.
One structure common to published incidents at Japanese hospitals is that network equipment or connection paths provisioned for maintenance became the point of entry. This article does not cover attack techniques; the defensive conclusion is clear enough. The maintenance path is part of the hospital network and must be designed and managed as such. It is not an area that can be delegated entirely to the vendor.
This article sets out what a hospital's IT lead or administrative director should check when reviewing maintenance access — with the emphasis less on configuration detail than on who decides what, what gets recorded, and what goes into the contract.
Disclaimer: This article is general information. The authoritative sources for safe management of medical information systems are the MHLW "Guidelines for the Safe Management of Medical Information Systems" and related ministry publications. Base specific configuration and operational decisions on those, on your own system architecture, and on your vendors' specifications.
Why Maintenance Paths Are Your Responsibility
Maintenance access can look like the vendor's own business, but that is not how the guidelines treat it.
Version 6.0 of the MHLW guidelines applies to everyone involved in the introduction, operation, use, maintenance, and disposal of any medical information system. Maintenance is explicitly in scope, regardless of the size or type of institution. The path a vendor uses to connect is therefore something the hospital must know about and manage.
The 2026 fee revision reinforced this. A new electronic clinical information coordination structure addition consolidates the former medical information acquisition addition and medical DX promotion structure addition, and folds an assessment of cybersecurity measures into them. Its common requirements include compliance with the guidelines and the appointment of a dedicated medical information system safety management officer. Security has moved from "worth doing if you have capacity" to a condition of reimbursement. For the revision as a whole see The 2026 Fee Revision; for the guidelines themselves, What the Three-Ministry Guidelines Are.
Seen as an object of management, maintenance paths have particular properties.
- The privileges are high. Engineers often connect as administrators to investigate faults, so the reachable scope is broad
- They fall outside normal monitoring. Treated as a vendor-specific path, they slip past routine log review
- Every vendor has one. EMR, imaging, laboratory, billing — each system tends to come with its own separate path
- The people change. The contracted company stays the same while the individuals connecting turn over
Left alone, this ends in a state where nobody holds a list of how many maintenance paths exist. The first thing to produce is not a countermeasure but an inventory.
Start With an Inventory
| Item | What to establish | Common reality |
|---|---|---|
| System | Which system the maintenance covers | Not listed anywhere; depends on one person's memory |
| Connection method | VPN / leased line / remote desktop / dedicated appliance | Varies by system, with unclear ownership |
| Always-on or not | Permanently open, or opened per request | Still permanently open, as installed |
| Origin | Which organisation and site connections come from | Known only as "from the vendor's office" |
| Authentication | ID and password only, or multi-factor | Operated on a shared account |
| Privileges | Administrator, or least privilege | Administrator rights across all systems |
| Records | Whether connection logs and work records exist | Held by the vendor, not visible to the hospital |
| Contract terms | Whether the contract specifies how connections are made | Says only "performs maintenance" |
| Subcontracting | Whether the vendor subcontracts the work | Never checked |
Filling in this table alone surfaces which paths need attention first. You do not have to fix everything at once. Start with paths that combine high privilege, always-on connectivity, and no records.
A useful side effect is that the inventory finds paths that should not exist at all — a contract that ended while the connection remained, or an opening created for acceptance testing and never closed. Closing an unused path costs nothing and works reliably. For the wider network picture, see Network Segmentation and Asset Management.
End Always-On Access
The single change with the largest effect is moving to per-request connectivity.
Always-on access has a genuine operational benefit: when a fault occurs at night or at the weekend, the vendor can begin work without anyone at the hospital doing anything. The flip side is that connections can occur without the hospital knowing.
| Approach | What it means | Burden on the hospital | Where it fits |
|---|---|---|---|
| Always on (status quo) | The path is permanently open | None | Not recommended; if unavoidable, compensate with monitoring and records |
| Opened on request | Opened when work is requested, closed when finished | Requires an open/close process | Planned daytime work; the easiest place to start |
| Time-windowed | Connections possible only within defined hours | Initial configuration only | Where night coverage is needed but always-on is not acceptable |
| Physically disconnected | Maintenance equipment kept powered down or unplugged | Requires someone on site | Medical devices and similar cases |
"Per-request access will slow down night-time incident response" is a real objection. The way through is to combine a time window with a pre-agreed emergency procedure: who requests it, through which channel, who approves, and who opens the path. The important part is that the emergency procedure is written down and rehearsed. A procedure that exists only in someone's head leads straight back to "it is safer to leave it open."
Where VPN equipment carries the maintenance path, that equipment needs its own vulnerability management. Published incidents repeatedly involve devices left unpatched against known vulnerabilities. See Managing VPN Appliance Vulnerabilities.
Restrict Origin, Identity, and Privilege
Restricting the origin. Permit connections only from the vendor's specified sites. Even if credentials leak, connections from unexpected locations fail. Because this requires the vendor to actually work from those locations, agree it in the contract or a memorandum rather than assuming it.
Strengthening authentication. Shared maintenance accounts are still common. With a shared account you cannot establish who connected, and credentials survive an engineer's departure. At minimum:
- Issue accounts per individual
- Apply multi-factor authentication (see Introducing Multi-Factor Authentication)
- Require the vendor to notify the hospital of departures and transfers, with a defined process for disabling accounts
- Align password requirements with your own policy (Designing a Password Policy)
Restricting privilege. Maintenance does not require permanent administrator rights across every system. Grant what the work needs, and issue privileged access temporarily on request and approval. See Access Design and Privileged ID Management.
Restricting reachable systems. Confirm that a path opened for EMR maintenance cannot be used to move laterally into imaging systems or administrative file servers.
Keep Records — and Review Them
Records held only by the vendor are not enough. The hospital needs a view of its own.
| Layer | Content | Held by | When reviewed |
|---|---|---|---|
| Connection logs | When, which account, from where | The hospital (network and authentication infrastructure) | Periodic review; on detection of anomalies |
| Work records | Purpose and actions taken | Submitted by the vendor | On completion of work |
| Change records | What was changed in configuration or software | Submitted by the vendor | Per change |
The layer most often missing is the hospital's own connection log. If vendor connections terminate on hospital authentication or network equipment, the fact of the connection is recorded on your side. Whether that record exists decides whether an incident can be investigated at all. See Log Management and Audit Trails.
Collecting records and reviewing them are two different things. Once a month, reconcile the number of maintenance connections against the work records submitted. Doing only that reveals connections nobody declared. Assign the task and fix the frequency so that anyone can perform the same check.
Write It Into the Contract
Technical configuration is not sufficient. Maintenance rests on a commercial relationship, so what has been agreed must be documented.
| Item | What to agree |
|---|---|
| Connection method | The path and method; always-on or per-request |
| Origin | Which sites work may be performed from |
| Permitted hours | Normal working windows, and how emergencies are handled |
| Account management | Per-individual issuance, authentication method, duty to notify on departure |
| Privileges | The scope granted, and the process where privileged access is needed |
| Work records | Content, format, and deadline for submission |
| Subcontracting | Whether permitted; prior approval and management responsibility if so |
| Demarcation | The boundary of responsibility (Demarcating Responsibility) |
| Incident notification | Time from detection to notification, contact points, information provided |
| End of contract | Disabling accounts, closing paths, returning loaned equipment |
Subcontracting is easily overlooked. The company you contract with may have another company perform the work. The problem is not subcontracting itself but not knowing the subcontractor's standard of control. At minimum, establish whether subcontracting occurs and whether equivalent obligations flow down.
End-of-contract handling also belongs in writing. Inventories regularly turn up accounts and paths belonging to a replaced vendor. See Security Requirements When Replacing an EMR.
None of this is limited to new contracts. Existing maintenance agreements can be supplemented by a memorandum at renewal. For structuring what to ask vendors, see Security Check Sheets for Vendors.
Conclusion
- Maintenance paths fall within the guidelines' scope and are the hospital's to know and manage. They cannot be left to the vendor
- Build an inventory before choosing countermeasures: method, always-on status, privileges, and records, per system — and close what is unused
- End always-on access, moving to per-request or time-windowed connectivity, with a written and rehearsed emergency procedure
- Restrict origin, account, privilege, and reachable systems. Replace shared accounts with per-individual accounts plus multi-factor authentication
- Hold connection logs on the hospital side and reconcile them against work records on a fixed cycle. Design the reviewing, not just the collecting
- Put method, origin, records, subcontracting, and end-of-contract handling into the contract or a memorandum
Once the inventory begins, you will need to draw a line between what the hospital decides and what it requires of vendors. That line differs by institution, according to system architecture and contract structure. If it is difficult to work through alone, get in touch — we can help with how to prioritise, starting from your system configuration.
If you are on the vendor side, considering how to demonstrate a manageable posture to the hospitals you serve, see What Is an ISMS (ISO/IEC 27001)? and ISMS Certification Support.
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
- On the FY2026 Medical Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: guideline requirements and reimbursement conditions change with revisions and official clarifications. Confirm the details against MHLW publications and regional bureau notices.