Introduction: Amid a Wave of Cyberattacks on Medical Institutions

In recent years, cyberattacks targeting medical institutions have grown increasingly serious. In 2026 alone, hospitals across Japan have repeatedly seen their electronic medical records and internal systems brought down. In February, Nippon Medical School Musashi Kosugi Hospital was reported to have suffered a ransomware infection that entered through a VPN device used for medical equipment maintenance, leaking personal information on approximately 130,000 patients. In March, the internal systems at Shiraume Toyooka Hospital were infected with ransomware, and patient information ended up published on the dark web.

For today’s healthcare settings, which depend heavily on electronic medical records, a system outage translates directly into a halt in patient care. That is why security measures that monitor hospital networks and automatically block suspicious traffic have become indispensable.

Yet the system outage at Nara City Hospital in April 2026 raises a pointed question about this picture. The outage was initially reported as a “suspected cyberattack,” and the hospital went as far as suspending emergency admissions. Later investigation, however, revealed that the cause was not an attack at all, but the behavior of the very security monitoring device installed to protect the hospital. There was no attacker.

Drawing on the investigation report published by Nara City as a primary source, this article reviews what happened. It then examines the lessons through the lens of ITIL practices: Change Enablement, incident management, and problem management.

Chapter 1: What Happened, from “Suspected Attack” to Recovery

First, let us lay out the facts based on Nara City’s official report.

On the night of April 21, 2026, a security monitoring device that watches network traffic inside Nara City Hospital flagged traffic from a relay terminal used for remote maintenance as “abnormal” and automatically blocked it. Alerts then fired one after another across multiple systems, including the ophthalmology system, the physiological testing system, the production environment of the electronic medical records, and the medical billing server.

The hospital judged that it could not rule out a cyberattack. To prevent the damage from spreading and to keep patients safe, it physically isolated the affected devices and the virtual server cluster hosting the electronic medical records from the network. This decision had the following impact on patient care:

Emergency admissions: suspended for approximately 53 hours
Outpatient appointments: about 500 of roughly 1,500 postponed
Scheduled surgeries: 18 of 56 postponed

On April 22, the Ministry of Health, Labour and Welfare dispatched a support team, which worked with the hospital to analyze logs and confirm system safety. Systems were brought back one by one as their safety was confirmed. The production environment of the electronic medical records was restarted on April 23, and regular patient care resumed on April 24. All major systems, including the online eligibility verification system (the system Japanese medical institutions use to confirm a patient’s health insurance coverage), were fully restored by May 13.

The investigation found no evidence of compromise: no tampering with or leakage of patient information or medical records, no malware infection, and no backdoors.

Chapter 2: The Cause Was an Overreaction by the “Protective System”

Nara City set up the Nara City Medical Information Security Expert Council, made up of external experts, to investigate the cause. The findings, published on August 31, 2026, came as a surprise to many involved.

The conclusion was that this was not an external cyberattack. The report attributed the outage to a change in what the security monitoring device was monitoring. Internal traffic that the device had not sufficiently learned was judged to be a “deviation from normal patterns,” which triggered a chain of automatic blocking.

Tracing the sequence of events makes the structure of the problem clear:

Before the outage, the monitoring state of the security device had changed for some reason. As a result, part of the hospital’s internal traffic appears to have gone insufficiently monitored for a certain period.
On the night of April 21, the device’s software was automatically updated, and the device restarted.
Triggered by this, traffic that had dropped out of monitoring scope came back into scope. The number of monitored devices jumped from 633 to 1,954, roughly a threefold increase.
With insufficiently learned internal traffic suddenly back under monitoring, the device judged it a “deviation from normal patterns” and automatically blocked it.
Alerts and blocking then cascaded across multiple systems, spreading to the entire hospital information system, including the electronic medical records.

In other words, there was no attacker. The security device misidentified normal internal traffic as “abnormal” and blocked it on its own. A system meant to protect the hospital ended up stopping its own patient care.

There is one more important point. Why had the monitoring scope shrunk to about a third beforehand? The root cause of that was never identified. The report states that the retention period for the detailed historical logs needed to determine the cause was limited, so a thorough review was not possible. The records of the event that started it all had already been lost.

Chapter 3: The Trigger Was an Automatic Update (An ITIL Change Enablement Perspective)

Change Enablement is the practice of implementing changes to services and configurations while appropriately managing risk. The key fact here is that the outage was triggered by the security device’s “automatic update” and “restart.” A software update is, without question, a “change.” In this case, that change was applied automatically, most likely at night, without any human check.

ITIL’s Change Enablement practice classifies changes into several types, and this classification helps clarify the issue at hand.

Low-risk changes whose risks have been assessed in advance and whose procedures are well established can be treated as “standard changes” and implemented without individual approval. Changes whose impact is harder to predict, on the other hand, should be handled as “normal changes” that go through prior risk assessment and approval. The question is which category the automatic updates of a critical security device running in production fell into.

An update to a device directly connected to a production medical information system should have been a “change” carried out under a framework that assesses its impact and verifies post-update behavior. In practice, however, the automatic update caused the monitoring scope to triple after the restart, and that in turn set off the chain of automatic blocking. The lack of prior impact assessment, combined with no post-update check, became the direct trigger of the outage.

This bears a striking resemblance to the Telstra network outage we covered in a previous article. There too, a restart following maintenance work left equipment in an abnormal state, which cascaded across the entire network. The same pattern, “a change involving a restart triggers an unexpected state change,” keeps repeating across industries.

Indeed, the first recommendation in the expert council’s list of preventive measures was to “disable automatic updates on the security monitoring device and switch to manual updates.” The council also called for procedures to verify and record the device’s state before and after updates, and for procedures to confirm, approve, and roll back updates when anomalies occur. This is exactly the set of basics that Change Enablement asks for: planning the change, assessing its impact, approving it, and preparing a rollback procedure.

The incident also exposes a tension in which “protective systems can undermine availability.” Automatic blocking is an effective way to limit the damage of a cyberattack, but if it mistakenly blocks legitimate traffic, it can stop patient care. Of the three pillars of ITIL’s information security management (confidentiality, integrity, and availability), availability is directly tied to human life in healthcare. The expert council also recommended that, even if automatic blocking is retained, the conditions for applying it should be defined with the impact of false positives on patient care in mind, and that defense should rely on multiple layers rather than on automatic blocking alone. The more protective a system is, the more carefully its operating conditions need to be designed and managed as a change.

Chapter 4: Was the Decision to Shut Down the Right One? (ITIL Incident and Problem Management Perspectives)

Incident management: the initial decision to “stop” was reasonable

ITIL’s incident management aims to minimize the negative impact of service interruptions and to restore normal operations as quickly as possible.

From this perspective, there is much to commend in the hospital’s initial response. Unable to tell immediately whether it was facing a cyberattack or an equipment failure, the hospital prioritized patient safety and containment. It isolated the anomalous devices, protected its backups, shut down the electronic medical records, and temporarily suspended emergency admissions. The expert council concluded that, given the circumstances at the time, these actions were reasonably justified.

This reflects an important principle of incident management: when the cause is still unknown, priority goes to stopping the spread of damage by assuming the worst-case scenario (a real attack). The cause ultimately turned out not to be an attack, but that does not make the isolation “excessive.” The quality of an incident response should be judged not in hindsight, but on whether it was reasonable given the information available at the time.

That said, incident management also left work unfinished. While the expert council found the direction of the preventive measures sound, it pointed out that decision criteria and response procedures need to be made more concrete for them to work reliably in a real emergency. Specifically, this means what to check and how to respond when an alert fires, the criteria for lifting automatic blocking, and procedures for restoring systems such as the electronic medical records in stages. In short, the hospital needs to document in peacetime “who looks at what, how they decide, and how they bring things back.” This is the real-world version of the “decision-making drills” we discussed in a previous article on incident drills.

Problem management: without logs, there is no path to the root cause

Next, the problem management perspective. ITIL’s problem management aims to identify the root causes of incidents and prevent their recurrence. Logs and other records are the lifeline of that root cause analysis.

In this case, however, the most crucial starting point, “why had the monitoring scope dropped to a third in the first place,” could not be traced to a root cause because the retention period for the necessary detailed historical logs was too short. The direct trigger (the surge in monitoring scope and over-detection caused by the automatic update) was identified, but the true starting point before it, the “change in monitoring state,” could not be traced because the records were gone.

This is a lesson that applies to everyone involved in IT operations and maintenance. Wishing after an outage that “we still had those logs” comes too late. Just as an “undocumented design change” blocked the investigation in the Telstra case covered in our previous article, here “logs that were not retained” deprived the organization of a chance to learn.

From a problem management standpoint, failing to identify the root cause means the risk of the same outage happening again cannot be fully eliminated. That is why the expert council recommended defining in advance the types, scope, and retention periods of the logs and configuration change histories needed when a major event occurs. Deciding in peacetime what to keep, and for how long, determines whether you can reach the root cause when it matters.

Conclusion: Manage Protective Systems as “Changes” and Keep Records

Let us summarize the lessons from the Nara City Hospital case.

First, security systems also undergo “changes” when they are updated (change management). Even for a device meant to protect you, automatic updates and restarts are nothing other than changes to the production environment. Assess the impact, verify post-update behavior, and be able to roll back if something goes wrong. The basics of Change Enablement need to apply to security products too.

Second, when the cause is unknown, the decision to stop and protect takes priority (incident management). Nara City Hospital’s isolation measures were reasonable at the time, even though the cause turned out not to be an attack. Incident response should not be judged in hindsight but evaluated against the information available when decisions were made. Making those decision and recovery procedures concrete in peacetime is how you prepare for next time.

Third, if you do not keep logs, your organization cannot learn. If you cannot reach the root cause, you cannot prevent recurrence. Deciding in peacetime what to keep and for how long is the foundation of problem management.

As noted at the outset, cyberattacks on medical institutions are a real threat, and stronger monitoring and defense are essential. But this case shows that the defense mechanisms themselves can become the cause of an outage if they are not properly managed. “We thought it was a cyberattack, but it was our own defenses overreacting.” This paradox makes clear that we need both: preparing for attacks, and correctly operating the systems we rely on to prepare.

Under what conditions are the security products you have deployed configured to block traffic? Are their updates managed as changes? And do you have logs that would let you trace the cause when it matters? Before you break into a cold sweat, why not take a moment to check?

References

Nara City (2026). “Report on the System Outage at Nara City Hospital” (Summary of the investigation report by the Nara City Medical Information Security Expert Council) [in Japanese]. https://www.city.nara.lg.jp/soshiki/93/273750.html

Nara Shimbun Digital (2026). “Nara City Hospital system outage investigation results released: cyberattack ruled out, over-detection by monitoring device” [in Japanese]. https://www.nara-np.co.jp/news/20260901210926.html

ITmedia NEWS (2026). “Nara City Hospital, suspected of cyberattack, reports ‘no infection or leakage’ after successful initial response; regular care resumes” [in Japanese]. https://www.itmedia.co.jp/news/articles/2604/24/news069.html

Nikkei Medical (2026). “Nara City Hospital, suspected of cyberattack, suspends emergency admissions and outpatient care” [in Japanese]. https://medical.nikkeibp.co.jp/leaf/mem/pub/hotnews/int/202604/592992.html

“Cyberattack Cases at Hospitals and Medical Institutions [2026 Edition]” (Musashi Kosugi Hospital, Shiraume Toyooka Hospital, and others) [in Japanese]. https://aevus.jp/blog/hospital-cyber-attack-cases-2026.html

piyolog (2026). “A summary of the Nara City Hospital system outage caused by an automatic update of monitoring equipment” [in Japanese]. https://piyolog.hatenadiary.jp/entry/2026/09/04/104347