"Antivirus is installed on every endpoint." Ask a hospital about its security posture and this is usually the first answer. It is generally true — signature-based antivirus is widely deployed. The problem is that what it does and does not stop is rarely shared knowledge inside the institution.
EDR — Endpoint Detection and Response — now appears in most vendor proposals. But as the name says, detection and response are a pair, and this is not a product that protects you by being installed. It becomes meaningful only when somebody reads what it detected, decides what it means, and acts: isolating a machine, investigating, escalating. Deploy it without settling that, and you accumulate alerts on a console nobody opens.
This article is written for hospital IT leads and administrative directors deciding whether to adopt or replace endpoint protection. It does not compare products. It focuses on the design question: what are you trying to stop, and how much operational capacity will you have behind it?
Disclaimer: This article is general information. The authoritative sources are the MHLW guidelines and related ministry publications. For reimbursement requirements, consult MHLW notices and official clarifications.
What Conventional Antivirus Does Not Stop
Signature-based antivirus compares files against recorded characteristics of known malicious programs. It works against known threats and remains necessary.
It is structurally weak, however, against:
- Things that do not match a known signature — a small modification evades comparison
- Abuse of legitimate tools, where administrative functions built into the OS are used and no file is itself malicious
- Legitimate logins with stolen credentials, where no malicious program runs at all
- Exploitation of network equipment, which an endpoint agent is not watching in the first place
A structure recurring across published hospital incidents: a known vulnerability in an internet-facing network appliance provides entry, movement inside happens with legitimate credentials and administrative tooling, and file encryption comes last. Endpoint antivirus only gets to act in the final phase of that sequence.
Conventional antivirus is therefore one layer, not sufficiency. It becomes a whole only alongside the entry point (Managing VPN Appliance Vulnerabilities), lateral movement (Network Segmentation, Privileged ID Management), and recovery (Backup Design). For the full picture see Ransomware Countermeasures for Hospitals.
How EDR Differs
EDR continuously records endpoint behaviour — process launches, file operations, network activity, configuration changes — and detects suspicious chains of activity so that they can be investigated and acted on.
| Aspect | Conventional antivirus | EDR |
|---|---|---|
| Detection basis | Matching against known malicious characteristics | Judging suspicion from chains of behaviour |
| Strong against | Known malware | Novel techniques, abuse of legitimate tools, post-intrusion activity using stolen credentials |
| Output | Detection and quarantine results | Alerts plus a record that lets you trace what preceded and followed |
| Operations required | Definition updates, confirming removal | Reviewing, triaging, and deciding on alerts — people are required |
| Post-incident investigation | Limited | Entry route and blast radius can be traced |
| Endpoint impact | Relatively light | High data volume; test impact on endpoints and links first |
| Cost | Low per endpoint | Per-endpoint licensing plus the cost of monitoring |
The decisive rows are the last two. EDR keeps recording, which has an operational footprint, and it presumes a human processes the alerts.
Its particular value for hospitals is being able to investigate afterwards. Whether you can state when entry occurred, from which endpoint, and how far it reached affects your explanation to patients, your report to regulators, and your judgement about the scope of recovery. Without records the only honest answer is "we do not know" — which forces you to treat every system as suspect and lengthens recovery considerably. See Reporting Obligations After a Data Breach.
Note that claims that EDR deployment is a condition of a reimbursement addition could not be confirmed against primary sources at the time of writing (confirm independently). What is confirmed about the electronic clinical information coordination structure addition introduced in the 2026 revision is that its common requirements are compliance with the guidelines and appointment of a dedicated medical information system safety management officer, and that the higher tier additionally requires backups by multiple methods, some held offline, and a BCP for cyberattacks together with exercises. Confirm the details against MHLW publications. See The 2026 Fee Revision.
Installation Is Not Operation
This is the core of the article. Whether to adopt EDR is not a product decision but a question of whether you can staff the response.
EDR produces alerts daily. Most are legitimate activity or ambiguous. Someone must:
- Read the alerts — every day, weekends included
- Triage legitimate work from genuine threats
- Isolate an endpoint or take other action when it is a threat
- Investigate the blast radius
- Drive recovery and prevention as needed
Steps 1 and 2 are the hard ones in a hospital. Where the IT function is one or two people who also run the EMR and staff the help desk, reading alerts every day is not realistic. A design that expects round-the-clock monitoring from people with other jobs fails within the first few months.
| Operating model | What it is | Where it fits | Watch for |
|---|---|---|---|
| In-house | Hospital staff review and act on alerts | A staffed IT department able to run an out-of-hours rota | One resignation stops it; training and runbooks are essential |
| Managed detection service | An external provider triages alerts and contacts you when action is needed | Small and mid-sized hospitals without dedicated staff | You still must decide who inside the hospital decides once contacted |
| Delegated to the system vendor | Your EMR maintenance vendor monitors as well | Easy to arrange through an existing relationship | Fix the scope, coverage hours, and notification criteria in the contract (Demarcating Responsibility) |
Whichever you choose, the hospital must decide who decides what after the call comes in. At 2am someone reports suspicious behaviour on a terminal and asks permission to isolate it. Is there a person who can answer? If that terminal is essential to ward operations, isolating it affects care immediately. Building that decision framework in advance is the real preparation work.
Put in writing:
- Who receives the call (in hours and out of hours)
- Who can authorise isolation, and their deputy
- Which endpoints may be isolated freely and which require careful judgement
- The fallback for the work if an endpoint is isolated, including paper process
- The escalation path inside the hospital
This is effectively part of your incident response plan. Design it alongside A Hospital Incident Response Plan and A BCP for Cyberattacks — needed regardless, given the BCP and exercise requirement in the higher addition tier.
When You Cannot Install Anything
Not every endpoint in a hospital can take an agent. Typical reasons:
- The manufacturer does not warrant it. Approved medical devices restrict changes from the approved configuration
- The OS is old and no product supports it
- Performance constraints — real-time imaging or measurement is affected
- No persistent network connection, so updates and monitoring cannot work
Rather than treating these as hopeless, protect them from outside the endpoint. See Securing Network-Connected Medical Devices; the approaches are:
| Measure | What it does | Effect |
|---|---|---|
| Network segmentation | Place the devices on a dedicated segment and limit who they can talk to | Restricts both entry and lateral movement; the largest effect |
| Allow-listed communication | Permit only required destinations, block the rest | Limits the damage if a device is used as a stepping stone |
| Restricting what may connect | Define and register which terminals and media may attach | Design alongside Managing Removable Media |
| Network-side monitoring | Observe device traffic externally for unusual behaviour | Requires nothing installed on the device |
| Physical access control | Room access control, physical port blocking | Deters unauthorised connections |
| Refresh planning | Fold security into the specification at the next replacement | Resolves it over the medium term (Putting Security Into Procurement Requirements) |
The important step is listing what cannot be covered. Recording which devices lack which protection, and what compensates instead, both supports your compliance narrative and feeds the requirements at replacement. Without that list, planning proceeds on the false premise that every endpoint is protected.
What to Settle Before Buying
| Item | What to establish |
|---|---|
| Endpoints in scope | Servers, clients, shared terminals, mobile devices, medical devices — feasibility per device |
| Relationship to existing products | Replacement or coexistence, and conflict testing if both |
| EMR compatibility | Whether the EMR vendor warrants operation and has recommended settings — always confirm in advance |
| Endpoint and network impact | Data and traffic volume; test on your oldest hardware |
| Post-detection operations | In-house, managed service, or vendor; coverage hours and notification criteria |
| Isolation authority | Who may isolate which endpoints, by what procedure |
| Log retention | Long enough for post-incident investigation (Log Management and Audit Trails) |
| Uncoverable endpoints | The list and the compensating measures |
| Cost breakdown | Not licences alone but monitoring, deployment, and tuning |
| Term and termination | Multi-year conditions and early termination handling |
Do not skip confirmation with your EMR vendor. Endpoint software interfering with EMR operation has been reported in many places, and discovering it after go-live hits care directly. For structuring vendor questions see Questions to Ask Your Vendors and Security Check Sheets for Vendors.
Compare costs over three years. A low licence price with separately billed monitoring can invert the ranking. The same lens applies when assessing a supplier's own security posture — see What Is an ISMS (ISO/IEC 27001)?.
Conclusion
- Conventional antivirus is one layer; it only becomes a defence alongside entry-point, lateral-movement, and recovery controls
- EDR records endpoint behaviour and detects suspicious chains; its greatest value is the ability to investigate afterwards
- EDR does not protect you by being installed. Without deciding who reads alerts and who authorises isolation, it does not function
- The operating model is in-house, managed service, or vendor — and each still requires an internal decision-maker and a fallback for the affected work
- Endpoints that cannot take an agent are protected by segmentation, allow-listed traffic, and external monitoring — and the exceptions must be listed
- Before buying, confirm compatibility with the EMR vendor and compare three-year totals including monitoring
- Claims that EDR is a reimbursement requirement are not confirmed against primary sources; check MHLW publications
Whether EDR is right for you depends less on the product than on whether your institution can absorb the operations. If you need help drawing the line between what you keep in-house and what you outsource, 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
- On the FY2026 Medical Fee Revision | MHLW
- Information-technology Promotion Agency (IPA)
- National center of Incident readiness and Strategy for Cybersecurity (NISC)
Note: reimbursement conditions are governed by MHLW notices and official clarifications. Where this article differs, follow the primary sources.