Two Hospitals Went Back to Paper Charts. That Is the Story.

On August 31, 2026, systems at Luminis Health started failing. By the next day the health system had confirmed it: a cybersecurity incident had taken down electronic systems at two of its Maryland hospitals, Anne Arundel Medical Center in Annapolis and Doctors Community Medical Center in Lanham.

MyChart and the phone system went offline.

Physicians went back to paper charts.

The Anne Arundel County Fire Department began coordinating directly with hospital staff on where ambulances could take patients, since both facilities had limited availability.

One detail from Becker's Hospital Review's reporting says more than any statistic could. A cancer patient's radiation treatment, scheduled for August 31, was postponed because of the outage. As of the reporting, it had not been rescheduled.

Nine days later, Luminis Health still has not named the group behind the attack, has not said how the attackers got in, and has not given a restoration timeline.

Its most recent update says only that the health system was the victim of an unauthorized criminal actor and that teams are working around the clock with third-party experts to restore affected systems. What it can say clearly is that the investigation into whether patient information was accessed is still ongoing.

We are not going to speculate about who did this or how. Luminis Health has not disclosed either, and guessing would not help anyone.

What we can do is walk through how ransomware actually moves through a hospital network once it has a foothold, using publicly documented incidents as the reference points, and show why the constraint hospitals operate under, the inability to simply go dark, is the single largest factor in why this keeps happening to this sector specifically.

This Is Not a Data Story. It Is an Availability Story.

Most breach coverage centers on a number: how many records, how many patients, what kind of data. Luminis Health does not have that number yet, and it may take weeks to get one. But the absence of a number is not the absence of harm.

A cancer patient's treatment got pushed back with no new date. Ambulances had to reroute around a hospital's front door. Doctors lost access to the records that tell them what a patient is allergic to, what they are already taking, and what happened at their last visit.

None of that requires a single record to have left the building. Ransomware against a hospital does not need to steal data to cause damage.

It only needs to make the systems clinicians depend on unavailable at the moment someone needs them. That is a different threat model than the one most security programs are built around.

The Timeline Ransomware Actually Runs, Stage by Stage

Hospital ransomware is not a smash-and-grab. It is a staged intrusion that spends most of its time being quiet, and the quiet part is where nearly every real detection opportunity exists and gets missed.

A 2026 CybelAngel analysis of healthcare ransomware incidents puts the median time from an attacker's first access to fully encrypted records at four to five days, and the average time for a US healthcare organization to identify and contain a breach at 279 days. Those two numbers together describe the actual problem: the attacker moves in days, and the defender, on average, doesn't notice for months, on a prior incident that eventually surfaces when the ransomware note does.

The stages, as documented across dozens of publicly disclosed healthcare incidents, look like this.

Day 0 to 1: Initial access, usually through one of three doors. An exposed remote-access system with weak or no MFA, an exploited vulnerability in an internet-facing appliance, or a phished credential. The most consequential healthcare breach on record followed exactly this pattern.

In February 2024, BlackCat/ALPHV ransomware operators accessed Change Healthcare's network through a remote access server that lacked multifactor authentication. That single gap led to 6 terabytes of data exfiltrated, a full operational shutdown, a $22 million ransom payment, and 192.7 million people affected, the largest healthcare breach in US history. MFA on one server was the entire difference.

Days 1 to 3: Reconnaissance, while every alert stays green. The attacker maps the network from the inside: domain structure, backup locations, EHR architecture, which systems are clinically critical and which aren't.

This phase generates almost no alarming signal to a SOC watching for malware signatures, because the attacker is largely using legitimate administrative tools already present in the environment, not dropping obviously malicious binaries.

Days 2 to 4: Backup discovery and destruction, before encryption even starts. Modern ransomware operators understand that a hospital with intact backups can recover without paying, so backup infrastructure gets targeted specifically, and often deleted or encrypted before the primary environment is touched.

By the time a hospital notices something is wrong, its recovery path is frequently already gone.

Days 4 to 5: Encryption, and the point where the incident becomes public. This is also, notably, the point where hospitals increasingly are not the primary target of the encryption itself.

Sophos-cited data shows extortion-only attacks, data theft with a ransom demand but no encryption event, tripling in healthcare in 2025, because patient data alone is sensitive enough to generate leverage without the operational noise of a full encryption event that draws law enforcement and press attention immediately.

Whether Luminis Health experienced encryption, extortion-only data theft, or something else has not been disclosed.

The single most important fact in that timeline: everything up through the reconnaissance and backup-destruction phases happens while every dashboard says green. The moment a hospital finds out something is wrong is, on average, the moment the attacker has already won most of the fight.

Why Hospitals Are Harder to Defend Than Almost Anything Else

Most organizations facing a live intrusion have a blunt option available: pull the plug, take the affected systems offline, contain the damage, sort it out later. Hospitals do not have that option in the same way. Taking a clinical system fully offline while patients are mid-treatment is not a containment step, it is a patient safety event of its own.

That constraint is exactly what attackers count on, whether or not any individual attacker consciously reasons about it. A ransomware operator does not need to out-engineer a hospital's defenses. They need one foothold, and the hospital's own inability to shut everything down buys the attacker time that a company in almost any other sector would take away from them by simply going dark.

That asymmetry runs through the entire narrative of what security has become. Attacks are happening at machine speed. Defense is still running at a human speed. Attackers need one way in.

Defenders need to secure everything, every remote-access box, every vendor account, every unpatched internal app, all day, every day, with zero exceptions. Your company has to win every day. An attacker has to win once.

Nowhere is that asymmetry more consequential than in a building where the thing being defended is a person's treatment schedule, not just a database.

The technical picture underneath that asymmetry is stark. Industry research from ORDR's 2026 healthcare cybersecurity report found that 99% of US hospitals manage devices containing known, exploited vulnerabilities. Q1 2026 saw 120 disclosed ransomware attacks against healthcare organizations, with average ransom demands surging to $16.9 million, up from $577,800 the prior quarter.

Double extortion, encrypting data while simultaneously stealing it for leverage, is now standard practice in 96% of cases. This is not a sector under occasional attack. It is a sector under sustained, escalating, financially rational siege, because the operational leverage a hospital cannot avoid giving up is worth more to an attacker than almost any other kind of target.

Where the Entry Point Usually Is

Luminis Health has not disclosed how the attackers got in, and speculating about this specific incident would not be responsible. But across publicly documented healthcare ransomware cases and the hospital pentests we run, the entry point is almost always one of three things.

An exposed remote-access system. RDP, a VPN gateway, or a remote-access box reachable from the public internet, frequently missing MFA or running an unpatched version. Change Healthcare's breach traces to exactly this category.

So does a large share of the sector's 2024-2025 incident volume tied to Citrix and Ivanti appliance vulnerabilities, both of which CISA has repeatedly flagged as actively exploited in healthcare environments. We've written previously about the Ivanti Connect Secure zero-day (CVE-2025-0282) exploited by UNC5337, which follows the identical pattern: an internet-facing remote-access appliance, unpatched, becomes the initial foothold for an actor who then moves laterally into whatever network trusts that appliance.

This is the exact class of exposure our remote penetration testing work is built to catch, because black box testing maps external attack surface, including exactly this kind of remote-access exposure, before an attacker finds it.

A vendor or third-party account. Hospitals run on vendor software, imaging systems, scheduling platforms, billing tools, lab integrations, and each one is a login an attacker can try to compromise instead of attacking the hospital directly.

A compromised vendor account inherits whatever trust the hospital extended to that vendor, often broader than anyone remembers granting.

An unpatched internal application. Something running an old version of a framework or plugin, sitting inside the network, not internet-facing on its own, but reachable the moment an attacker gets a foothold anywhere else through lateral movement.

This is why the reconnaissance phase matters so much: an attacker with any internal foothold spends days finding these before touching anything an EDR agent would flag.

All three are findable before an attacker finds them. None require exotic tooling. They require someone testing that surface on a schedule that matches how fast it changes, not once a year on a fixed engagement, because a remote-access box stood up in March and forgotten by June sits exposed for the rest of the year unless something is watching continuously.

Why Segmentation, the Textbook Answer, Is Harder in a Hospital Than Anywhere Else

The standard defensive answer to lateral movement is network segmentation: isolate clinical systems from administrative systems from guest networks, so a foothold in one segment can't reach the others. Hospitals struggle to implement this as thoroughly as other industries for reasons specific to the environment.

Medical devices, infusion pumps, imaging equipment, monitoring systems, frequently run on legacy operating systems that cannot be patched without vendor re-certification, sometimes for years after a vulnerability is disclosed.

Many were never designed with modern network security in mind and cannot run endpoint detection agents at all. They still need to talk to the EHR and to each other in real time, for patient safety reasons that override a security team's preference to isolate them.

The result is an internet of medical things layer that is simultaneously clinically essential and extremely difficult to defend with the same rigor as a standard IT endpoint, and lateral movement from an administrative foothold into that layer is a documented pattern across the sector, not a hypothetical.

None of this is a reason to give up on segmentation. It is a reason the testing has to be continuous and specific to this environment rather than a generic annual network scan that treats a hospital like any other enterprise.

What This Means If You Run Security for a Hospital or Health System

A few practical takeaways, regardless of how the Luminis Health investigation concludes.

• Test availability, not just confidentiality. Most compliance-driven testing programs are built to answer "can PHI be exposed." That is necessary but incomplete. The harder question is "can this system be taken offline," because that is the question that actually determines whether a cancer patient gets treated on schedule.

• Assume the reconnaissance phase is already happening somewhere. With a median four-to-five-day window from first access to encryption and a 279-day average time to detection on prior incidents industry-wide, the statistically likely state for any hospital network at any given moment is "something is already inside and hasn't been found yet." Detection tooling needs to be tuned for that assumption, not for the assumption that the perimeter is currently clean.

• Protect backups like they are the target, because they are. Ransomware operators specifically hunt and destroy backup infrastructure before encrypting the primary environment. Backups need isolation, immutability, and their own access controls separate from the production identity plane an attacker who gets in would otherwise use to reach them.

• Map your remote-access and vendor surface on a real cadence. An annual pentest catches what existed on the day of the test. Continuous testing catches what changed since.

• Treat clinical downtime planning as a security control, not just an operations plan. Paper charts and fire department coordination worked at Luminis Health because someone had a plan for it. That plan is part of your security posture and deserves the same rigor as your technical controls.

• Compliance evidence and exploitability evidence are different things. A HIPAA risk assessment tells you a system holding ePHI is a risk on paper; it does not tell you whether that risk is one phished credential or one unpatched remote-access box away from taking a clinical system offline. Only an actual test answers that question.

The Fix

Nobody has confirmed that data was stolen at Luminis Health. What the attackers took, at minimum, was the hospital's ability to run normally, and that is harder to recover from in the moment than a database is.

The systems that let a doctor pull up a chart, let an ambulance know where to go, and let a cancer patient keep a treatment date are the systems worth testing hardest, and the four-to-five-day window between first foothold and full impact is exactly why a once-a-year pentest is the wrong cadence for catching it in time.

If an attacker got a foothold in your network tonight, would you find out inside the four-to-five-day window, or find out when your doctors are back on paper charts?

CodeAnt AI tests the remote-access gaps, vendor accounts, and unpatched internal apps that hospitals actually get breached through, continuously, and proves exploitability with runtime evidence instead of a checklist. Start a free pentest and find your foothold before someone else does.