No patch yet: Follina and Confluence tested who may switch things off
Two security holes were being exploited before any fix existed, leaving health systems with workarounds only. What decided the outcome was organizational: who could authorize switching something off, who could actually do it everywhere, and who checked that it worked.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
Two-minute summaryThe dek and the first sentence of each section, quoted from the article
Two security holes were being exploited before any fix existed, leaving health systems with workarounds only. What decided the outcome was organizational: who could authorize switching something off, who could actually do it everywhere, and who checked that it worked.
- The week Around May 27, 2022, security researchers spotted something unpleasant: a malicious Word document that, once opened, could run code on a Windows computer.
- What a zero-day is, and why it changes the rules Software security mostly works like a car recall.
- Who authorizes Most hospital change management processes are designed to prevent surprises.
- Who executes at the edges The Follina workaround was a registry change.
- Who confirms A change pushed is not a change applied.
- Safety, money and partners A delay in any of the three roles can leave a forgotten wiki server open to intruders over a weekend, and the consequences follow in five areas.
- Paperwork agreed in calm conditions Good preparation for a week like this is not expensive.
- Testing authority before the next unpatched flaw A leader does not need to understand registry settings to test whether the organization is ready.
- With hindsight Both flaws were patched, and the immediate waves of exploitation faded.
The week
Around May 27, 2022, security researchers spotted something unpleasant: a malicious Word document that, once opened, could run code on a Windows computer. It did this by abusing a built-in helper called the Microsoft Support Diagnostic Tool, the small program Windows uses to gather information when something goes wrong and you contact support. The sample had been uploaded to a public malware scanning service. A researcher nicknamed the technique Follina, after an Italian town whose telephone area code matched a number in the file.
The technique alarmed defenders because it sidestepped the usual defense. For years, malicious Office documents had relied on macros, small embedded programs that many organizations had learned to block. Follina did not need macros. The document fetched a web page from a remote server, and that page called the diagnostic tool with instructions to run the attacker’s code. Researchers also showed that a version saved in rich text format could fire when a user merely previewed the file in File Explorer.
The weakness was not entirely new to Microsoft. According to reports at the time, a researcher had sent the company a similar sample in April, and that report was initially closed as not a security issue. By late May, the same idea was circulating openly.
On May 30, Microsoft gave the flaw an official tracking number, CVE-2022-30190. (A CVE is simply a public ID for a known security weakness. It lets everyone be sure they are talking about the same problem.) Microsoft also published a workaround: a setting change that disabled the tool’s URL protocol, meaning web links could no longer call the diagnostic tool into action. Its guidance told administrators to back up the setting first, so the change could be reversed.
The same guidance noted that Office opens documents from the internet in Protected View by default, a read-only mode that blocked this attack, and listed detections in Microsoft’s own security products. That was a stopgap, not a cure. The real security update did not arrive until the June 14 Patch Tuesday release, Microsoft’s regular monthly batch of fixes. A related variant was fixed in July.
Within days of the disclosure, security firms reported phishing campaigns using the technique, including some aimed at government organizations. Attackers had a working method, a large population of Windows computers, and a window before any patch existed.
Meanwhile, a second problem was surfacing. Over the Memorial Day weekend, the security firm Volexity was investigating suspicious activity on two internet-facing Confluence servers belonging to a customer. It traced the intrusion to a flaw nobody had known about and reported it to Atlassian on May 31.
On June 2, Atlassian disclosed the flaw, CVE-2022-26134, in Confluence Server and Data Center. Confluence is a wiki: an internal website where teams write and share documents, procedures and notes. The flaw was rated critical and allowed unauthenticated remote code execution. That meant a stranger on the internet, without any password, could make the server run commands of their choosing. Atlassian said all supported versions were affected and that the flaw was already being exploited. Its cloud-hosted Confluence service was not affected.
Volexity’s account showed why patching would not be the end of the story. The attackers had loaded an implant into the server’s memory, leaving no file on disk, then written web shells, small backdoor pages, as a fallback. They read password files, copied Confluence’s user tables and edited web access logs to hide what they had done.
Fixed versions of Confluence arrived on June 3, along with a temporary workaround that involved replacing specific files on the server. Organizations running clustered deployments faced extra steps to upgrade without downtime. Public exploit code appeared soon after the fixes, and scanning for exposed servers rose sharply.
On the day of disclosure, the Cybersecurity and Infrastructure Security Agency (CISA), the federal government’s lead cyber defense agency, acted. It added the flaw to its Known Exploited Vulnerabilities catalog, a public list of weaknesses that attackers are confirmed to be using. Under its directive on that catalog, CISA told federal civilian agencies to immediately block all internet traffic to and from Confluence Server and Data Center until a fix was applied.
Federal agencies were used to such orders. A week earlier, on May 18, CISA had issued an emergency directive requiring agencies to patch or remove several VMware identity and automation products within five days. Attackers had reverse engineered an April patch for those products and begun exploiting unpatched systems within 48 hours. For internet-facing instances, agencies had to assume compromise, disconnect them and hunt for intruders before reconnecting.
What made the week unusual was the order of events. Both flaws were exploited before fixes existed. These are often called zero-days, because defenders had zero days of warning. For several days, the only defenses available were configuration changes and cutting access: turning features off, or disconnecting servers from the internet.
For a hospital, that is not a simple choice. Turning things off can disrupt clinical work. Leaving them on can invite an intruder. Somebody has to decide, quickly, and somebody else has to carry it out in every corner of a sprawling organization. Unlike a federal agency, a private health system had no outside authority ordering the disconnection. That week showed which health systems had settled those questions in advance, and which had not.
Take a hospital IT director on a Thursday evening in early June 2022. The news feeds are full of a Word document trick that can take over a Windows computer, and a wiki flaw that lets strangers run commands on a server. There is no patch for either. There are only two unappealing options. One is to change a setting on every Windows device in the building, with no certainty about what it might break. The other is to pull collaboration servers off the internet that some departments use every day.
Health systems are practiced at the monthly patch cycle. They test, schedule, deploy and report. That rhythm assumes a patch exists. In the days after these two disclosures, it did not.
The decisions were less technical than organizational: who may disrupt a working system to prevent a possible compromise, at short notice, often outside business hours. The week tested three distinct roles. The first is the person who can authorize the change. The second is the people who can carry it out across every corner of the estate. The third is the people who confirm it worked and that nothing slipped in first.
Health systems face these roles under conditions most other sectors do not. Hospitals run around the clock, so there is never a slack weekend in which to make disruptive changes. Clinical leaders must weigh in on anything that touches patient care. Estates are federated, with affiliated practices, research groups and clinical engineering each running parts of the network.
Federal civilian agencies faced the same flaws with an outside authority behind them. When CISA tells agencies to block traffic to a product, the decision about whether to act has largely been made. A private health system has no equivalent instruction. Its leaders have to make that decision themselves, often with less information, and own the consequences either way.
This article deals with the days before a patch exists. Once a fix arrives, the normal cycle resumes, though on a compressed timetable. The organizational design that carries a health system through the gap is what the three roles describe.
What a zero-day is, and why it changes the rules
Software security mostly works like a car recall. The manufacturer finds a defect, builds a fix, and tells owners to bring the car in. In software, the fix is a patch: a small update that closes the hole. Large organizations install patches on a schedule, typically monthly, after testing them to make sure nothing important breaks.
A zero-day turns that order upside down. Attackers find and use the weakness before the manufacturer has a fix. Defenders learn about the problem at the same moment they learn it is being used against people. There is nothing to install yet, so the only options are to reduce exposure: switch off the feature being abused, block the route attackers are using, or disconnect the system altogether.
Follina abused a legitimate Windows component, the Microsoft Support Diagnostic Tool. A booby-trapped Word document could call that tool through a special kind of web link, a URL protocol, and trick it into running the attacker’s code. Microsoft’s workaround disabled that URL protocol through a registry change. The registry is Windows’ central settings file. Changing it on one machine is easy. Changing it on tens of thousands of machines, safely, is a project.
The Confluence flaw was a different animal. It was in a server, not a desktop, and it required no victim to open anything. Anyone who could reach an exposed Confluence server over the internet could, without logging in, make it execute commands. The fastest defense, before fixed versions arrived on June 3, was to stop people reaching the server at all by blocking internet traffic to it.
CISA’s Known Exploited Vulnerabilities catalog, usually shortened to KEV, played a role here too. Thousands of software flaws are published every year, and most are never used in real attacks. The KEV list narrows that flood to the ones attackers are confirmed to be using. CISA added the Confluence flaw to the catalog on the day of disclosure, a clear signal that this was not theoretical.
For federal civilian agencies, the catalog is binding. Under CISA’s Binding Operational Directive 22-01, issued in November 2021, agencies must fix listed flaws by set deadlines, typically two weeks for recently disclosed ones. Health systems are not bound by the directive, but many adopted the list as an objective way to decide what deserves emergency handling.
Two flaws, two kinds of exposure
The two flaws called for different defenses, owned by different teams. Follina was a client-side problem. It needed a person to open or preview a file, so the defenses sat with the endpoint and email teams. They could filter attachments at the mail gateway, keep Protected View enforced for documents from outside, and apply the registry workaround.
Some organizations had another layer already in place. Microsoft’s endpoint protection includes attack surface reduction rules, among them one that blocks Office applications from launching other programs. Where such controls were enforced, the Follina technique was harder to use, which gave those organizations more time to roll out the workaround carefully.
Confluence was a server-side problem. No user had to do anything. The defenses sat with the network team and the application owner: blocking internet traffic to the server at the firewall, adding filtering rules in front of it, or shutting it down. A health system had to coordinate two different responses, through different people, in the same few days.
Even after fixes shipped, the Confluence choices involved trade-offs. Upgrading to a fixed version was the durable answer, but clustered installations needed careful steps to avoid downtime. Atlassian’s temporary workaround, replacing specific library files, was faster but less tested, especially on older versions. A department running an out-of-date wiki might have no supported upgrade path at all. Each option needed someone with the skill to carry it out and the authority to accept its risk, which brings the question back to people rather than software.
Who authorizes
Most hospital change management processes are designed to prevent surprises. A change advisory board meets weekly, clinical stakeholders review anything that touches patient-facing systems, and emergency changes need senior sign-off. That design is sensible for upgrades. It is slow for an exploited zero-day on a Thursday evening.
The organizations that moved fastest had pre-delegated authority. A written rule, approved in advance by the CIO and a senior clinical leader, set out what the CISO could do alone. During active exploitation of a critical flaw, the CISO could restrict internet access to a non-clinical system or push a defensive configuration change. The system owner received notice rather than a request for permission. For systems that touch patient care, the rule named a clinical leader on call who could approve within an hour, and a fallback if that person could not be reached.
Pre-delegation has a cost. Occasionally a defensive change will break something, and someone will be unhappy. The rule should say how that is handled: a quick rollback path, a post-event review that judges the decision on what was known at the time, and no penalty for a reasonable call. Without that protection, people delay.
The same rule should cover the reverse decision. If the CISO decides not to act, because the exposure is internal or the workaround is riskier than the flaw, that choice and its reasoning should be recorded too. Regulators, auditors and insurers reviewing an incident later will ask what was known and when. A short decision log, kept as events unfold, answers that question better than memory.
The log needs only a few fields: the time, what was known, the options considered, the decision, who made it and when it will be reviewed. Kept in a shared document or the incident ticket, it takes minutes to maintain. Reconstructing the same record weeks later from email and chat is slow and less convincing.
A practical trigger helps. Many teams used CISA’s Known Exploited Vulnerabilities catalog as one objective signal: a critical flaw on that list, affecting an internet-facing or widely deployed product, activates the emergency authority. A shared trigger cuts the time spent debating whether this event is serious enough.
Consider a health system with four hospitals and a few dozen clinics. Its policy says that when a critical flaw appears on the KEV list and affects an internet-facing system, the CISO may cut that system’s internet access immediately if it is non-clinical. On the Thursday evening, the CISO learns that the quality department runs a Confluence wiki reachable from the internet. The wiki is non-clinical. She blocks external access within the hour, emails the department head to explain, and writes three lines in the decision log. Nobody convenes a meeting. The next morning, the department grumbles that remote staff cannot reach their procedures. That is the price, and it was agreed in advance.
Now compare a peer system without such a rule. The same CISO must find the system owner, who is on vacation, then the owner’s manager, who wants to consult the vice president, who asks for a risk assessment. By the time approval arrives, two days have passed. The technology was identical; the two-day delay came from the organizational design.
What the delegation rule should contain
A useful rule fits on a page and answers six questions in advance. The first is scope: which classes of system it covers, typically non-clinical, clinical-adjacent and clinical, with different authority for each. The second is the actions allowed, from blocking internet access to disabling a feature, isolating a host or shutting a system down.
The third is the trigger. A listing in the KEV catalog for an exposed product is one. A vendor advisory confirming active exploitation is another. So is credible threat intelligence from a sector source such as Health-ISAC, the health sector’s information sharing and analysis center. The fourth is notification: who must be told, and how fast, after an action is taken.
The fifth is duration. An emergency change should expire after a set period unless the normal change process ratifies it, which prevents temporary blocks from becoming permanent without review. The sixth is rollback: how the change will be reversed if it causes harm, and who decides to reverse it.
Many hospitals already have a structure for emergencies that clinicians understand, the Hospital Incident Command System. Tying the cyber delegation rule into that structure gives clinical leaders a familiar route for decisions that affect care. It also places cyber events alongside the power failures and mass-casualty drills hospitals already plan for.
How the setting changes the answer
The right design differs by type of organization. An academic medical center usually has the hardest authorization problem. Research groups, schools and clinical departments run their own systems, and many of the Confluence instances at risk in 2022 would have lived there. The delegation rule has to reach research IT explicitly, or it stops at the edge of the hospital proper.
A community hospital may have a small IT team and rely on a managed service provider for after-hours operations. Its delegation rule is only as good as the provider’s contract. That contract should say the provider may act on the CISO’s emergency instruction without waiting for a ticket to work through normal queues.
A rural or critical access hospital may have one or two IT staff and depend heavily on vendors. The authority may effectively rest with the chief executive, who should know that in advance. An ambulatory network spread across many clinics often uses a vendor-hosted record system, so its own exposure lies mostly in endpoints and email, while server-side risk sits with the vendor.
Health systems that extend their record system to independent practices face a hybrid. They host the application but do not own the practices’ computers, which brings the execution problem described next.
Who executes at the edges
The Follina workaround was a registry change. On a well-managed central fleet, pushing it was a matter of hours. Health system estates are not one fleet. They include shared clinical workstations, devices running embedded Windows inside clinical equipment, computers owned by affiliated physician practices, research labs with their own administrators, and contractors’ machines on the network. Documents from outside senders, such as referrals, records requests and payer letters, reach all of them.
The word “estate” here means everything with a network connection that the organization depends on, owned or not. The central fleet may be well run, but an emergency instruction is only as good as the organization’s ability to reach every device.
Confluence exposed a different edge. Research groups, quality departments and informatics teams sometimes ran their own wiki servers, occasionally exposed to the internet and absent from the central configuration database. That database is the master list of systems the IT department knows about and manages. A server missing from it is, for practical purposes, invisible. Early guidance, including a CISA requirement for federal agencies, was to block internet traffic to and from these servers until they were patched. That required knowing they existed and having someone with administrative access who would answer the phone.
The execution question is a roster question. For each segment of the estate, the roster should name who has both the technical ability and the authority to make a change within hours. Affiliated practices may need a clause in their network access agreement that obliges them to apply emergency security changes within a set time. Clinical engineering needs a defined role for devices that security staff cannot touch. Research IT needs an on-call contact.
Pushing a change at scale
Mature endpoint teams deploy changes in rings: first to IT staff, then to a pilot group of clinical units, then to everyone. In a zero-day, the rings compress from weeks to hours, but they still matter. A change that breaks something in the pilot ring can be stopped before it reaches every nursing station. Microsoft’s Follina guidance included a backup step for the registry key, which made rollback straightforward for teams that followed it.
Virtual desktops add a twist. Many hospitals give clinicians non-persistent virtual desktops that reset to a master image at each logoff. A setting pushed to running sessions disappears at the next reset unless the master image is updated too. Teams that missed this saw their coverage figures fall back overnight.
Medical devices running embedded Windows need a different approach. Changing settings on a device cleared in a specific configuration may require the manufacturer’s agreement. Where that is not available quickly, compensating controls do the work: preventing those devices from receiving email or browsing the web, and keeping them on segmented networks. Clinical engineering should hold that list and the contacts for each manufacturer.
For a server like Confluence, the network team holds a powerful fallback. Even when nobody can reach the server’s administrator, a firewall rule can stop internet traffic to it. That action preserves the server, and the evidence on it, while cutting off the attacker’s route in. The roster should name who can make that change at any hour.
External attack surface scanning, which shows internet-facing services the way an attacker sees them, finds the servers no one listed.
The scan should cover cloud accounts as well as the data center. Departments sometimes set up their own servers on public cloud services with a corporate card, outside the central configuration database. Those servers are as reachable from the internet as any other, and often less carefully maintained.
Reaching affiliates and contractors
Affiliated practices are the hardest edge, because the health system does not own their computers. A network access agreement can still set terms. It can require the practice to apply emergency security changes within a set number of hours of notice and to run endpoint protection the health system can see. It can also allow the health system to suspend the practice’s network connection if neither happens.
Those terms have a cost. Independent practices value their autonomy, and heavy obligations can push them toward other partners. Some health systems answer that by offering managed endpoints as a service, so that the same team that pushes changes to hospital devices also maintains the practices’ machines. The practice gets support; the health system gets reach.
Contractors and vendors with remote access pose a similar problem on a smaller scale. Requiring their devices to meet basic checks before connecting, or giving them access only through a managed virtual desktop, means an emergency change applied to the desktop image reaches them too.
Why the edges are where trouble lives
The edges are not careless by nature. A research lab running its own wiki usually does so because the central service was too slow to provide one, or did not fit how the team worked. An affiliated physician practice has its own budget and its own IT contractor. Medical devices running embedded Windows are often certified in a specific configuration, and changing settings on them may need the manufacturer’s blessing. Each of these is a reasonable local choice. Together they mean that a single instruction from the center does not reach everywhere by default. Leaders who understand that reality design for it, instead of discovering it during a crisis.
Who confirms
A change pushed is not a change applied. Endpoint management consoles, the dashboards IT uses to send updates and settings to computers, report devices that were offline, failed to update, or reverted. Someone has to own the gap report and chase it to zero, segment by segment, and report the residual risk to the person who authorized the change.
Confirmation also has a forensic side. Because both flaws were exploited before disclosure, a server patched under pressure might already have been compromised. Patched is not the same as clean. For the Confluence flaw in particular, the right follow-up was to review server logs for signs of exploitation and look for unfamiliar files or accounts. It also meant rotating credentials stored on the wiki, which often included service account passwords and configuration notes. Service accounts are the non-human logins that systems use to talk to each other, and they frequently have broad access. That work needs an incident responder, not the department administrator who applied the fix.
What a compromise review looks for
Volexity’s account of the original intrusion shows what a review has to cover. Attackers had placed an implant in memory, written web shells to disk and altered logs. A review therefore looks for unfamiliar files in the application’s web directories and unexpected programs launched by the server’s own process. It also checks for outbound connections to unknown addresses and new or changed administrator accounts.
Because logs on the server itself may have been edited, evidence from outside the server matters more. Firewall logs, proxy logs and the records kept by network detection tools are harder for an intruder on the server to tamper with. A memory capture before rebooting can preserve evidence of an implant that would otherwise vanish.
If the review finds signs of intrusion, the event becomes an incident with legal consequences. Wikis in quality and clinical departments sometimes hold patient details in incident reviews or case notes. Under the HIPAA breach notification rule, an impermissible disclosure of protected health information is presumed to be a breach unless a documented risk assessment shows a low probability that the information was compromised. Counsel and the privacy officer belong in the review from the start.
Clinical checks
Clinical confirmation matters too. After a defensive change on clinical workstations, someone should check that key workflows still function: document viewing in the electronic record, printing of wristbands and labels, and integrations with imaging and lab systems. A short checklist, run by clinical informatics on a sample of units, catches breakage before it becomes a safety report.
Evidence that the change stuck
Confirmation produces a small set of figures. For each segment of the estate, the team reports the share of devices confirmed to have the change and the devices it could not reach. It also lists the exceptions, each with a named owner and a compensating control. The person who authorized the change then accepts the residual list in writing or asks for more work.
The console is not the only source. Endpoint detection tools can query devices directly to confirm the registry key is gone. An external scan, run from outside the network, can confirm that a blocked Confluence server is no longer reachable. Checking from a second source catches the cases where the console reports success that did not happen.
Closing the event
The emergency ends with its own short sequence. When the patch arrives, it goes through an accelerated version of the normal cycle. Emergency changes are either ratified through the change process or reversed. With Follina, the diagnostic tool’s troubleshooters remained available through Windows’ Get Help app after the workaround, so many organizations could leave the protocol disabled.
An after-action review, held within a couple of weeks, compares how long each role took against what the rule expected. It records what broke, what was missed and which roster entries were wrong. The changes it produces are the cheapest improvements the organization will make all year.
Each role needs a name, a deputy and a phone number. Health systems that had filled all three treated the week as routine. Those that had filled none discovered that their exposure was set by their org chart rather than their technology.
Safety, money and partners
A delay in any of the three roles can leave a forgotten wiki server open to intruders over a weekend, and the consequences follow in five areas.
- Patient safety. A defensive change that breaks label printing or image viewing can harm care. So can an intruder who reaches clinical systems. Both risks are real, and the decision between them belongs to people with clinical as well as technical authority.
- Money. A compromise that starts on a forgotten wiki server can spread. Recovery, lost revenue during downtime, and legal costs all follow. Hours of delay in the authorization step can be the difference between an uneventful weekend and a reportable incident.
- Regulators and insurers. After an incident, the questions are about process: what you knew, when you knew it, and what you did. A decision log and a written delegation rule are evidence of reasonable governance.
- Partners. Affiliated practices share your network and often your brand. If they cannot be required to act, their weakness is your weakness.
- Staff. People who fear blame for a defensive change that goes wrong will hesitate. A no-penalty rule for reasonable calls is a workforce policy as much as a security one.
The costs fall unevenly. Clinical departments bear the disruption of a defensive change. The security team bears the blame if a change goes wrong, and again if an intrusion follows inaction. Affiliates bear the cost of obligations they did not choose. Patients bear the risk either way, which is why the decision belongs to people who answer for their care as well as for the network.
The case for leaving things on
The argument for pre-delegated authority has a serious counter-argument. Hospitals know that downtime harms care. Every defensive change carries some chance of breaking a workflow, and most zero-days never touch a given organization. Frequent emergency actions on weak signals would wear out clinical goodwill and teach staff to ignore security alerts.
There is also a governance concern. A CISO with power to disrupt systems is not accountable for patient outcomes in the way a chief medical officer is. Concentrating that power can look like a security team overriding clinical judgment.
The answer lies in the design of the rule rather than in abandoning it. Authority without a clinical sign-off is limited to non-clinical systems. Triggers are objective, not a matter of one person’s anxiety. The least disruptive effective action comes first, such as blocking internet access instead of shutting a system down. Every decision is logged and reviewed.
The counter-argument does carry weight in one place. Where compensating controls already blunt an attack, the case for a risky emergency change weakens. Follina is an example: an organization that enforced Protected View and blocked Office applications from launching other programs had less need to rush the registry change onto every clinical workstation. The rule should allow a recorded decision to wait in such cases.
Paperwork agreed in calm conditions
Good preparation for a week like this is not expensive. It is mostly paperwork agreed in calm conditions, plus a few tools that most organizations already own.
What the prepared systems had
- A one-page emergency authority rule, signed by the CIO and a senior clinical leader, that names who may restrict what, and under which trigger.
- A named on-call clinical approver for changes that touch patient care, with a named fallback.
- An execution roster covering every segment of the estate, including affiliates, research, clinical engineering and contractors, with a deputy for each.
- Contract language with affiliated practices that obliges them to apply emergency security changes within a set time.
- Regular external attack surface scanning, with results compared against the central configuration database.
- A gap report owner and a compromise review routine for any flaw exploited before disclosure.
- A short clinical workflow checklist that informatics staff can run after any defensive change.
Where preparation breaks down
- Treating every emergency as a normal change. Routing an exploited zero-day through the weekly change board guarantees delay.
- Assuming the inventory is complete. The servers that cause trouble are, almost by definition, the ones nobody listed.
- Declaring victory at “pushed.” A setting sent to ten thousand devices has not reached the ones that were switched off, or that later reverted.
- Confusing patched with clean. If attackers had days of head start, the fix closes the door but does not tell you who walked through it.
- Punishing reasonable calls. One reprimand for a defensive change that inconvenienced a department will slow every future decision.
- Failing to record decisions not to act. Inaction can be the right call, but only a written rationale shows that it was a call at all.
Rehearsing it
Paperwork that has never been exercised tends to fail on first use. A tabletop exercise built around a no-patch scenario tests the rule, the roster and the confirmation steps in an afternoon. CISA publishes tabletop exercise packages that organizations can adapt, and a health system can write its own scenario around a wiki server or a malicious attachment.
The useful scenarios start on a weekday evening, not at nine in the morning. They test whether the on-call clinical approver answers, whether the managed service provider acts on instruction, and whether anyone knows how to reach the research lab. They also test rollback by deliberately breaking a workflow and timing the recovery.
Running such an exercise once or twice a year costs little compared with discovering the gaps during a live event. The findings feed straight back into the delegation rule, the roster and the affiliate contracts.
Testing authority before the next unpatched flaw
A leader does not need to understand registry settings to test whether the organization is ready. These plain questions will reveal most gaps quickly.
- If a critical flaw were being actively exploited tonight, who could restrict a non-clinical system without asking anyone first? Is that written down?
- For a change that touches patient care, who is the on-call clinical approver this week, and who is their backup?
- Can we name, for each part of our network, the person who could make a change within hours, including affiliated practices, research labs, medical devices and contractors?
- After fixing a flaw that was exploited before disclosure, do we check for signs of compromise and change the passwords stored on that system?
- If someone makes a reasonable defensive call that turns out to disrupt a department, what happens to them?
These questions are about authority and people rather than technology, and they decide how a health system fares in a week when there is no patch to install.
After each real event, a short summary of the decision log belongs with the board committee that oversees risk. It should show what was known, what was decided, how long each role took and what will change. Over time, those summaries become the best evidence of whether the organization is getting faster.
With hindsight
Both flaws were patched, and the immediate waves of exploitation faded. Microsoft’s security update shipped in the June 14 Patch Tuesday release, with a fix for a related variant in July, and fixed Confluence versions had been available since June 3. The immediate emergency was over.
Microsoft later moved against the component itself. In January 2023, it announced that the Microsoft Support Diagnostic Tool was deprecated and would be removed in a future Windows release. A helper that most users never knew they had was being retired, in part because it had become an attack path. Retiring unneeded features is one of the few ways to shrink the attack surface for good.
Confluence’s troubles did not end in 2022. In October 2023, Atlassian disclosed two more critical flaws in its self-managed Confluence products, and both were exploited in the wild, the second by ransomware operators. Health systems that had built the three roles in 2022 had a rehearsal behind them. Those that had not faced the same scramble with the same software.
The pattern also repeated at larger scale. Through 2023 and 2024, exploited flaws in internet-facing products, including file transfer tools and VPN gateways, produced the same scramble and caused serious breaches in health care. A file transfer tool is software organizations use to send large files to partners. A VPN gateway is the secure front door that lets remote staff into the internal network. Both sit at the edge, facing the internet, which is exactly what makes them attractive targets.
The best-known examples followed the 2022 script closely. A zero-day in the MOVEit Transfer file-sharing product, disclosed at the end of May 2023, was used by an extortion group to steal data from a long list of organizations, health care among them. In January 2024, exploited flaws in Ivanti’s Connect Secure VPN gateways led CISA to issue an emergency directive and then to order federal agencies to disconnect the devices. Each time, the same three questions came back: who can authorize switching something off, who can do it everywhere, and who confirms it worked.
CISA’s Known Exploited Vulnerabilities catalog became a standard prioritization input well beyond the federal agencies it was built for. That is a welcome shift. A short, trusted list of flaws attackers are actually using gives busy teams, and their boards, a shared basis for deciding what is urgent.
Atlassian ended support for its Server products in February 2024, moving many wikis to managed cloud or Data Center editions and reducing the number of forgotten servers. That change did some of the inventory work for health systems, by shrinking the population of self-run wikis in departments. It did not remove the risk entirely: Data Center is still run by the customer, and the 2023 flaws affected it too. Moving to the vendor’s cloud shifted patching to the vendor, which is the larger change.
HHS published voluntary cybersecurity performance goals for health care in January 2024. Mitigating known vulnerabilities is one of the essential goals, and asset inventory is among the enhanced ones. Another essential goal covers cybersecurity requirements for vendors and suppliers. Those map closely onto the weaknesses this week exposed: not knowing what you have, not acting quickly on flaws known to be in use, and not being able to require action from partners.
In January 2025, HHS went further and proposed revisions to the HIPAA Security Rule. They would make several of these practices explicit, including a technology asset inventory, a network map and defined timelines for patching. Whatever its final form, the proposal shows the direction of travel: practices that were good governance in 2022 are moving toward stated expectations.
The clinical device edge improved for new equipment. Since March 2023, manufacturers seeking FDA clearance for devices that connect to networks have had to submit plans to monitor and address vulnerabilities after sale, along with a software bill of materials. That helps with devices bought from now on. The installed base of older equipment running embedded Windows remains a long-lived problem.
By 2026 more health systems have written emergency authority into policy. Fewer have contractual reach into affiliated practices, which remain a common gap. That is the place to look next. The authorization question has largely been answered on paper. The execution question, reaching every edge of an estate you do not fully own, is still open in many organizations. It is the one the next flaw with no patch will test.
Spotted an error? Tell us and we will check it and correct the article where needed.