Citrix gateways: the most exposed system in the hospital

The week

On December 17, 2019, Citrix disclosed a critical vulnerability, catalogued as CVE-2019-19781, in its Application Delivery Controller and Gateway products, formerly sold under the NetScaler name. Many organizations, hospitals among them, use these products to give remote users access to internal applications. A gateway works like a secure reception desk at the edge of the network: people outside present their credentials there, and the desk lets them through to the applications they are allowed to use. A vulnerability is a flaw that lets someone get past that desk without the right credentials, or take over the desk itself.

This flaw did the second. A specially crafted web request could reach a part of the device that should have required a login, and use it to make the device run the attacker’s commands. No password was needed. Citrix later found that the same flaw affected some of its SD-WAN appliances as well.

The flaw had been reported to Citrix by a researcher at the security firm Positive Technologies. Shortly after disclosure, the firm estimated that at least 80,000 companies in 158 countries could be at risk, with the largest share in the United States. That figure measured potential exposure, not confirmed attacks. It still gave attackers a long list of targets and defenders a sense of scale.

For hospitals, the product sat at the heart of ordinary work. A cardiologist at home at ten at night who needs to check a patient’s latest test results before a procedure in the morning opens her laptop. She signs in to the hospital’s remote access page and, within a minute, is looking at the electronic health record as if she were at a workstation on the ward. The gateway is what makes that possible, and in January 2020 one of the most widely used kinds became a target for attackers around the world.

At first Citrix published configuration mitigations, settings changes that would block the known route of attack, but no patch, the permanent software fix. In the second week of January 2020, public exploit code appeared. Exploit code is a ready-made tool that takes advantage of a flaw; once it is published, attackers who could never have found the flaw themselves can use it. Attackers began scanning the internet for devices that had not applied the mitigations, and compromising them. The security firm FireEye later said it had tracked extensive exploitation from January 10.

The mitigations turned out to be less dependable than hoped. Citrix acknowledged that on certain builds of one version of the software, the recommended settings did not take effect unless the device was first updated. In mid-January, the Netherlands’ National Cyber Security Centre advised organizations to consider switching off affected devices until a reliable fix was available. For a hospital, switching off the gateway meant switching off remote access for clinicians. The timing was poor. January falls in the usual winter peak of respiratory illness, when beds are tight and on-call staff rely heavily on access from home.

The attackers were a mixed crowd. Some installed software to mine cryptocurrency. FireEye described one group that broke into devices, deleted other attackers’ tools, and blocked further exploitation. That group left its own backdoor behind, reachable with a secret passphrase. The device looked repaired, and was in fact held by someone else. By late January, FireEye also reported attempts to use the flaw to deliver ransomware.

Citrix released its first permanent fixes on January 19 and completed fixes for the remaining supported versions by January 24. On January 22, Citrix and FireEye released a free tool to help organizations check their devices for signs of compromise. Government cyber agencies in several countries urged organizations to apply mitigations or fixes immediately, and to check whether their devices had already been compromised. In the US, CISA published an alert on January 20, that pointed organizations to the vendor’s fixes and mitigation steps and urged them to check for compromise.

That second instruction mattered as much as the first. Patching closes the door, but it does nothing about anyone who walked through it before it was closed. An intruder who had got in first could still be inside after the fix was applied.

Hospitals use Citrix and similar gateways for good reasons. They let clinicians, coders and affiliated physicians reach the electronic health record and other clinical applications from outside the building without installing those applications locally. Physicians on call can review results from home. Coders, the specialists who translate clinical notes into billing codes, can work remotely. Affiliated practices can see the records of shared patients. For a hospital, that is real value, measured in faster decisions, more flexible staffing and better coordinated care.

The January 2020 vulnerability exposed four architectural problems with that arrangement, each calling for a different decision. The gateway is the most exposed system in the building. It is one door to many rooms. Patching it does not prove it is clean. And an estate that funnels remote work through a single gateway needs a plan for what replaces it.

After a short explanation of the technology and of how remote access runs on an ordinary day, the article takes those four problems in turn. It then looks at what a compromised gateway costs a hospital, what control looks like, and the questions leaders should be able to answer.

Gateways, edge devices and zones

What a remote-access gateway does

A hospital’s clinical systems normally live on its internal network, the private set of connections inside its buildings and data centers. Outsiders cannot reach them directly, which is the point. A remote-access gateway is a device that sits at the boundary between that private network and the public internet. It checks who is trying to connect, and if they pass, it shows them the applications they are allowed to use. Often the applications actually keep running inside the hospital, and the gateway simply sends pictures of the screen out to the user and their keystrokes back in. That is why a physician can use the health record on a home laptop without it ever being installed there.

Why “edge devices” are special

Security professionals call gateways, firewalls and similar equipment edge devices, because they sit on the edge of the network. They are different from ordinary servers in three important ways. They must be reachable from the internet, so anyone in the world can try to talk to them. They are often sealed appliances, so the hospital cannot easily install its usual security software on them. And they are trusted by everything behind them, because their job is to let people in.

Segmentation and zero trust

Two more terms come up below. Segmentation means dividing a network into separate zones with controlled crossings between them, so that reaching one zone does not open the others. Zero trust is a newer design philosophy that checks every request, every time, rather than trusting anyone who has made it inside the network.

How the January flaw worked

A web server decides what a visitor may see partly by the path in the address they request. Some folders on the Citrix device were meant to be reachable only after sign-in. The flaw let a crafted request step around that check by using path tricks, so an anonymous visitor could reach a folder that should have been closed.

From there, an attacker could plant a file containing commands, which the device would later process as if they were its own. The result was full control of the device with no password. Once in control, an attacker could read its configuration, which often includes credentials the device uses to check users against the hospital’s directory. The attacker could also watch sign-ins as they arrived, and use the device as a base from which to reach inward.

Mitigation, patch and hunt are different jobs

Three words recur in any edge-device emergency, and they mean different things. A mitigation is a temporary change that blocks the known route of attack, usually a setting. A patch is a permanent fix to the code. A hunt is a search for signs that someone got in before either was applied. Each has its own owner, its own evidence and its own failure mode. In January 2020, mitigations failed on some builds, patches arrived weeks after disclosure, and hunts were often skipped.

How remote access works on an ordinary day

Follow a single sign-in. A coder working from home opens a browser and goes to the hospital’s remote access address. The gateway presents a sign-in page. She types the same username and password she uses at work, and perhaps approves a prompt on her phone. The gateway checks those details against the hospital’s directory, the central list of staff accounts, and then shows her a page of icons: the health record, the billing system, email, a shared drive. She clicks one, and the application opens in a window on her screen while actually running on a server inside the hospital.

Behind that simple experience, several teams are involved, and each sees only part of it. The network team installed and configured the gateway, often years ago. The identity team manages the directory accounts. Application owners decide who should see which icons. The help desk resets passwords when people are locked out. Clinical and business leaders care only that access works when their staff need it, and they notice quickly when it does not.

On an ordinary day, that division of labor works well enough. Its weakness appears when the gateway itself is the problem. A flaw in the device is not clearly the network team’s, the identity team’s or the security team’s alone. Taking the gateway down for an emergency fix affects every one of those groups and every remote user at once. Without a clear owner and an agreed plan, the decision to act tends to wait for a meeting, and in January 2020, attackers were not waiting.

The gateway is also, by design, a single point of trust. Everything behind it assumes that anyone it lets through has been properly checked. If an attacker controls the gateway, that assumption fails silently. The applications behind it see what looks like normal traffic from a trusted source.

Who uses the gateway, and how differently

The users of a hospital gateway are not one population. On-call physicians need quick access to results and images at odd hours. Coders and billing staff need long sessions in the revenue-cycle system during the working day. Affiliated practices need the records of shared patients. Equipment vendors need occasional access to particular devices. IT administrators often use the same gateway to manage servers from home, which gives that path the most powerful accounts of all.

Each group needs different access and carries different risk. A design that gives all of them the same front door, the same sign-in strength and the same menu of applications is convenient for the network team and generous to attackers.

How it differs by type of organization

An academic medical center tends to have the most complex version: many affiliates, research users, residents rotating through, and several gateways acquired over the years. A community hospital or critical access hospital usually has one gateway, a small IT team and sometimes a vendor or managed service provider that configured the device and holds the knowledge. An ambulatory network may host one practice management system and record for dozens of clinic sites, so its gateway carries nearly all daily work.

The risk is the same in each, but the gap differs. Large systems struggle with sprawl and ownership. Small ones struggle with capacity, and often depend on an outside party to know that a patch exists at all. For those, the contract with the managed service provider should state who watches for advisories on edge devices and how quickly they act.

The most exposed system in the building

A remote-access gateway must be reachable from the internet. That makes it the first thing attackers scan for and the first thing they try when a flaw is published. In January 2020, the gap between public exploit code and widespread compromise attempts was a matter of days.

In many hospitals, these devices belonged to a network team, had been configured years earlier and were treated as plumbing rather than as an application with its own patch cycle. Firmware updates, the software built into the device itself, required a maintenance window that clinical leaders were reluctant to grant, because the gateway carried after-hours access for physicians. Nobody wants to explain to the chief of surgery that remote access will be down tonight. The result was devices that ran old code for long periods.

The design response is to treat internet-facing access devices as a distinct asset class, with their own rules.

• An inventory of every such device, including forgotten test units that may have been set up for a project years ago and never removed.
• A named owner with authority to schedule emergency maintenance.
• An emergency patch procedure agreed in advance with clinical leadership, so nobody has to negotiate during a crisis.
• A redundant pair, so one unit can be patched while the other carries traffic and clinicians notice nothing.

Monitoring should not depend on the device itself, since a compromised device can lie about its own state. Logs and alerts should flow to a separate system that the gateway cannot alter.

Why patch windows are hard in a hospital

Most businesses patch at night, when few people work. Hospitals never close, and remote access often peaks in the evening, when on-call physicians review results from home. The usual maintenance window therefore lands on exactly the users who complain loudest when access fails.

A redundant pair resolves most of this. With two units in a high-availability pair, the team updates the standby unit, fails traffic over to it, and then updates the other. Users may see a brief reconnection. Without a pair, every update is an outage, and every outage needs permission. The cost of a second unit is modest next to the cost of running a known-vulnerable device for weeks because nobody would approve the downtime.

Emergency authority, agreed in advance

The most useful document a hospital can have on the night of an edge-device emergency is one page signed months earlier. It says that when the vendor or a government agency reports active exploitation of an internet-facing device, the named owner may apply the fix or take the device offline without waiting for the change board. The owner then informs the chief medical information officer and the nursing leadership on call. It names the fallback for clinicians, such as on-site workstations or a secondary access path. It costs nothing to write, and it removes the meeting that would otherwise stand between a published exploit and a fix.

Knowing your own external footprint

Many organizations discovered in January 2020 that they had more exposed Citrix devices than they thought. Common sources are a test unit from a past project, a gateway inherited through an acquisition, or a device a clinic set up with a vendor’s help. The internet-wide scanning that attackers ran is also available to defenders.

A hospital can scan its own internet address ranges regularly, review public records of the security certificates issued for its domain names to find forgotten hostnames, and compare the results with its inventory. Any internet-facing device that nobody can name an owner for should be treated as an incident until proven otherwise.

One further rule is simple and often broken: the management interface of an edge device should never be reachable from the internet. Administrators should reach it only from a dedicated internal network, with its own strong sign-in. A flaw in a management page is far more dangerous when anyone in the world can load that page.

One door to many rooms

Gateways are valuable because they aggregate. A single sign-in presents a menu of clinical and business applications. For an attacker, the same aggregation means one compromised device can open a path to the EHR, file shares and administrative systems, depending on how the network behind it is built. Many hospital networks were flat, on the assumption that anyone inside was trusted. In a flat network, getting past reception means you can wander into any room.

The alternative is to separate what the gateway can reach. Clinical applications, administrative systems and medical device networks should sit in different zones, with the gateway allowed to talk only to the published application servers it fronts. Segmentation in hospitals is slow, because clinical workflows cross boundaries constantly and medical devices often cannot be readdressed easily. An infusion pump or imaging system may have been installed and certified with particular network settings, and changing them can require the manufacturer’s involvement. It is also the control that limits how bad a bad day gets.

The same logic applies to the accounts the gateway trusts. Remote access usually rests on directory credentials, the single username and password an employee uses for most systems, which also unlock email, file shares and sometimes administrative tools. Multi-factor authentication at the gateway helps. That is the familiar second step, such as a code sent to a phone, that proves the person signing in is who they claim to be. But it helps only if those credentials cannot be reused elsewhere without it.

Third-party users, such as billing vendors, affiliated practices and device manufacturers’ support staff, need particular care, because their accounts are often provisioned generously and reviewed rarely. Take a health system that, over a decade, has granted remote access to a transcription company, three physician groups, two imaging equipment vendors and a revenue-cycle contractor. Each was set up by a different project team. Nobody has a single list, and some of the people using those accounts left their employers years ago. Each account is a key to the gateway, and the gateway is a key to much of the hospital.

What lies behind the gateway

Follow the path an intruder would take. The gateway connects to the servers that run published applications and virtual desktops. It also checks users against the hospital’s directory, often using a service account with standing permissions. Behind those are the EHR, imaging viewers, file shares and the directory servers themselves.

An attacker who controls the gateway can harvest the service account’s credentials and the passwords of users signing in. With those, the attacker can move to the application servers and then to the directory. Control of the directory is what lets ransomware spread to thousands of machines at once. Each step is a place where segmentation, tight service-account permissions and monitoring could stop the chain.

Sign-in strength that holds up

Multi-factor authentication at the gateway should cover every account that can reach it, including vendors, administrators and test accounts. Exceptions granted for a single physician group or an old integration tend to become permanent. Attackers look for exactly those accounts.

The form of the second factor matters too. Codes sent by text message and push prompts are better than nothing, but they can be phished or approved by a tired user. Phishing-resistant methods, such as hardware security keys or passkeys bound to a managed device, are stronger. They are also harder to roll out to clinicians who move between shared workstations. Many hospitals end up with a tiered approach: the strongest methods for administrators and vendors, and practical methods for clinical staff, backed by device checks.

Vendor access and HIPAA

Many outside firms with remote access are business associates under HIPAA, because they handle protected health information on the hospital’s behalf. A business associate agreement is then required. That agreement sets duties for safeguarding the data and reporting breaches. It does not decide how the vendor’s staff reach the hospital’s systems, how often their accounts are reviewed, or what happens when a vendor employee leaves.

Those decisions belong in the access design. Workable controls include named accounts rather than shared ones, access limited to specific systems, and time-limited access for equipment vendors that is switched on for a support session and off afterward. A quarterly review in which each sponsoring department confirms its vendors’ accounts are still needed completes the picture. Each control is modest. Together they shrink one of the largest and least visible groups of gateway users.

Patching it does not prove it is clean

Citrix’s fixes closed the hole. They did not remove anything an attacker had already installed. Security agencies and researchers urged organizations to look for signs of prior compromise, and Citrix and others published tools to help. Many organizations patched and moved on, because compromise assessment needs skills and time that hospital IT teams rarely have in a normal week.

A sound playbook for edge devices has two steps: fix, then hunt. The hunt looks for unexpected files on the device, new accounts, unusual outbound connections and sign-ins that do not match known users. A common attacker tactic is to leave behind a backdoor, a hidden way back in that survives the fix. Finding one requires looking, not assuming.

The hunt depends on logs that were shipped off the device before the incident and kept long enough to cover the exposure window, so log retention for edge devices belongs in the design. In this case the window ran from the December disclosure through the date each hospital applied its mitigation or fix, and for some that was weeks. If the logs from that period were never kept, the hunt is guesswork.

The hunt can be outsourced, but the contract should be signed in advance, so the hospital is not negotiating terms while an intruder may still be inside. Specialist incident response firms are busiest exactly when a widely exploited flaw is in the news, and those with a retainer in place are served first.

Leaders should also decide in advance what happens if the hunt finds something. Rebuilding a gateway from scratch, resetting the passwords of every remote user and reviewing what the intruder could have reached are all disruptive, and each needs someone with authority to approve it quickly. A hunt is of limited use if nobody is empowered to act on what it finds.

What January’s attackers actually did

The public research from January 2020 shows why a hunt matters. Different groups exploited the flaw for different ends. Some planted cryptocurrency miners, which are noisy and comparatively harmless. One group, as described earlier, cleaned out rivals and kept its own backdoor. That behavior is consistent with someone gathering access to use or sell later. By the end of the month, ransomware operators had joined in.

A device compromised by the second kind of group can look healthier than an untouched one. The rival malware is gone and the obvious exploit path is blocked. Only a deliberate search for the backdoor reveals that the device still belongs to someone else.

Rebuild rather than clean

When a hunt finds signs of compromise on a sealed appliance, rebuilding is usually safer than cleaning. Cleaning assumes the team has found everything the attacker changed. A rebuild from a known-good image, with a fresh configuration, does not rest on that assumption.

The rebuild is only part of the job. Any secret stored on or passing through the device should be treated as exposed. That includes the directory service account, administrator passwords, the passwords of users who signed in during the exposure window, and the private keys behind the device’s security certificates. Rotating all of them is disruptive. It is also the only way to be sure an attacker cannot simply walk back in with what they took.

Findings and the HIPAA breach question

A positive finding also starts a legal clock. Under the HIPAA breach notification rule, an unauthorized access to protected health information is presumed to be a reportable breach. That presumption holds unless the covered entity can show a low probability that the information was compromised, based on a risk assessment of set factors. Notifications to affected individuals are due without unreasonable delay and no later than 60 days after discovery.

Logs decide which way that assessment goes. A hospital that can show what the intruder reached, and what it did not reach, may be able to support a finding of low probability. A hospital without logs may have to assume the worst and notify. Hospitals should work through these questions with counsel, but the evidence they will need has to be collected long before the lawyers are called.

What should replace a single gateway

The longer-term question is whether one gateway should carry so much weight. Approaches that check the user, the device and the request for each application, rather than admitting a user to a network, reduce the value of any single device to an attacker. These are the zero trust approaches described earlier. They are not a quick swap. They need a mature identity platform, management of the laptops and tablets clinicians actually use, and application owners willing to change how access is granted.

A realistic sequence for a health system has three stages.

1. Harden and monitor the gateway it has.
2. Segment what sits behind it.
3. Move applications to identity-centric access one at a time, starting with those that hold the most sensitive data or are most often used by third parties.

Each stage reduces risk on its own, so the program delivers value even if later stages slip.

Inside the third stage, the order of users matters as much as the order of applications. Vendors are often the best place to start, because their access is narrow, their numbers are known and their sessions can be recorded. Administrators come next, moved to a separate, tightly controlled path so that the gateway used by everyone else no longer carries the most powerful accounts. Clinicians come last, because their workflows are the most varied and their tolerance for friction the lowest. By the time the program reaches them, the identity platform and device management have been tested on smaller groups.

Funding is the usual obstacle. Gateways sit in infrastructure budgets, while identity and segmentation work competes with clinical system projects for the same small teams. Framing the program as shrinking what the hospital’s most exposed device can reach gives finance and clinical leaders something concrete to weigh. A measurable target helps, such as the number of applications reachable through any single access path.

Funding routes differ by organization. A large health system can usually fold segmentation into a multi-year infrastructure plan. A critical access hospital may depend on grants, shared services from a larger partner, or a managed service provider’s offering. An ambulatory network often finds the money in the platform contracts it renews anyway. In every case, the request is easier to approve when it is tied to a specific exposure that the board has already heard about.

The case for keeping one gateway

There is a serious argument for consolidation. A single gateway is one place to enforce strong sign-in, one place to collect logs and one device to patch. Spreading access across many applications and services multiplies the places where a setting can be wrong. Newer identity-centric access products also run at a vendor’s cloud or edge, which creates a different single point of dependence. A small hospital with two network engineers may manage one well-run gateway far better than a dozen modern connectors.

The argument is right about manageability and wrong about consequence. The problem in January 2020 was what the gateway could reach once it was compromised. A consolidated front door is defensible if what lies behind it is divided, and if the door itself is redundant, monitored and patched quickly. The goal is a smaller blast radius, whatever product delivers it.

What a compromised gateway costs a hospital

The stakes of a compromised gateway go far beyond IT. If attackers use it to deploy ransomware, clinical systems may go dark, forcing staff onto paper, delaying procedures and in some cases diverting ambulances to other hospitals. The cost runs from lost revenue and recovery work to the far harder-to-measure harm of delayed care.

There is also the question of patient data. A health record contains some of the most sensitive information a person has. An intruder with access to it creates obligations under health privacy law, possible notifications to patients and regulators, and lasting damage to trust. And there is the workforce. Clinicians who rely on remote access to do their jobs are the first to feel any disruption, and the first to lose patience with security measures that seem to get in their way. A good program protects access rather than simply restricting it.

Who bears the cost

The cost of a compromised gateway does not stay inside the hospital that owns it. When a hospital diverts ambulances, neighboring hospitals absorb the patients, often without warning or extra staff. When affiliated practices lose access to shared records, their patients wait longer for care. Patients themselves bear the cost of delayed procedures and of worry about their data. Those external costs rarely appear in the business case for a redundant gateway or a segmentation project. They are part of why regulators and boards have treated hospital cyber risk as a patient safety issue.

Insurance adds a further cost. Cyber insurers now commonly ask whether remote access is protected by multi-factor authentication and how quickly internet-facing devices are patched. A hospital that cannot answer well may face higher premiums, lower limits or exclusions. That makes the gateway one of the few security controls whose condition shows up directly in an annual renewal.

A hospital with remote access under control

A hospital with remote access under control can name every internet-facing access device it owns and who is responsible for each. It runs those devices in redundant pairs and has an emergency patch window that clinical leaders agreed to in advance. It sends gateway logs to a separate system and keeps them for months, not days. It has a compromise assessment retainer in place. Its gateway can reach only the application servers it is meant to front. Third-party accounts are reviewed on a fixed schedule, and it is moving its most sensitive applications to per-application access.

A few numbers make that state visible to a board. They include the count of internet-facing access devices, each with an owner, and the days from a critical advisory to a patched device. They also include the share of remote accounts protected by multi-factor authentication, with every exception listed, and how many days of gateway logs are held off the device. Finally, the number of outside companies with remote access, and the share reviewed in the last quarter. These figures change slowly, which is a reason to report them regularly rather than only after an incident.

The usual failures are the reverse.

• The gateway is treated as plumbing that nobody owns.
• The team patches and declares victory without looking for intruders.
• Logs stay only on the device, where an attacker can erase them.
• A flat network lies behind the gateway.
• Vendors get broad, permanent access that nobody revisits.
• The hospital waits for a perfect zero trust program before doing the simpler steps that reduce risk today.

Most of these failures share a cause. The gateway was bought as a network project, so its ongoing care was never assigned to anyone with the authority, budget and time to give it. Naming that owner is the cheapest fix on this list, and the one that makes the others possible.

Ownership, logs and vendor access at the hospital’s remote-access gateways

1. How many internet-facing remote-access devices do we have, including any test or legacy units, and who owns each one?
2. If a critical flaw were announced in one of them tonight, who has the authority to take it offline for patching, and have clinical leaders agreed to that in advance?
3. Where are the gateway’s logs stored, and how far back could we look if we needed to hunt for an intruder?
4. The last time we patched an exploited edge device, did we also check whether anyone had already got in, and who did that work?
5. How many outside companies have remote access to our systems, when were their accounts last reviewed, and are they all using multi-factor authentication?

With hindsight

Within two months, for many hospitals, the gateway went from one remote-access path among several to the main route into clinical systems, as non-clinical work moved home during the pandemic. Devices patched in a hurry in January suddenly carried most of the load. Coders, schedulers, finance staff and many administrators all depended on a piece of equipment that, weeks earlier, had been one of the most actively attacked systems on the internet.

In September 2020, after a ransomware attack disrupted Düsseldorf University Hospital, Germany’s federal cyber agency, the BSI, pointed to this same Citrix flaw in connection with the attack. It warned that systems patched in January could have been compromised before the fix was applied, leaving attackers with access afterward. That warning captured the central point of the January episode: closing the door does not tell you whether someone is already in the building.

Edge devices remained a leading way in for attackers. In late 2023 another Citrix vulnerability, known as Citrix Bleed, was exploited by ransomware affiliates, according to CISA. Affiliates are criminal groups that rent ransomware tools from their developers and carry out the attacks themselves. In mid-2025 a further flaw in the same product line, nicknamed CitrixBleed 2, was patched in June. When CISA added it to its catalog of exploited vulnerabilities in July, it gave federal agencies a single day to fix it. The window between disclosure and mass exploitation that was days in January 2020 had, for this class of device, shrunk further.

The January 2020 flaw itself had a long tail. In July 2021, CISA, the FBI and partner agencies in Australia and the UK published a list of the vulnerabilities most exploited in 2020. CVE-2019-19781 headed it. The agencies said attackers favored it because it was easy to exploit, the devices were widespread, and control of them opened the way to further attacks. Devices that were never patched, or patched without a hunt, kept paying for that first month.

The 2024 attack on Change Healthcare showed the other half of the problem. In congressional testimony, UnitedHealth Group’s chief executive said the attackers used compromised credentials to log in to a Change Healthcare Citrix remote access portal that did not have multi-factor authentication. Citrix noted that no flaw in its product was involved. Ransomware followed days later. The breach was eventually reported to affect about 190 million people, the largest health data breach reported to federal regulators. It was a reminder that the gateway’s strength depends on the sign-in in front of it as well as the code inside it.

Both cases follow the January 2020 pattern: a device built to let trusted people in became the easiest way for untrusted people to get in.

Guidance caught up in stages. In January 2024 the Department of Health and Human Services published voluntary cybersecurity performance goals for health care. The essential goals included multi-factor authentication and managing the risks of outside vendors. The enhanced goals added asset inventories, network segmentation and centralized collection of logs. In January 2025, HHS proposed changes to the HIPAA Security Rule that would make several such controls explicit. The proposal had not been finalized as of this writing.

In February 2025, cyber agencies from the Five Eyes countries published a set of guidance documents on edge devices. One of them, from the UK’s National Cyber Security Centre, asked manufacturers to build in logging and forensic features by default. It applies the argument about logs made above, but addresses it to the people who build the devices rather than those who run them.

The sequence from January 2020 held up: patch fast, assume compromise until a hunt says otherwise, and reduce how much any single gateway can open. Remote access is now core clinical infrastructure. It deserves an owner, a budget and the same seriousness as the health record it protects, because for an attacker, it is the way to reach that record.