One ransomware attack helped stall claims, payments, and pharmacy workflows across U.S. healthcare. My main takeaway is simple: this was not just a breach at one company. It showed how much the system depends on a few shared vendors, how weak access controls can open the door, and how many providers were not ready to work without a key clearinghouse.
If I had to sum up the article in plain English, it comes down to this:
- A stolen login hit an MFA gap on Change Healthcare’s Citrix portal in February 2024
- Attackers stayed inside for 9 days and took about 4 TB of data
- The outage disrupted a company that handles about 15 billion transactions a year
- About 94% of U.S. hospitals reported financial strain
- About 74% said patient care was affected
- Data tied to about 190 million Americans was exposed
- The big weak spots were:
- Vendor concentration
- Poor visibility into fourth parties
- Weak network separation
- Old systems and exposed remote access
- Poor downtime and cash-flow planning
- Leadership treating cyber as only an IT issue
What should healthcare leaders do now?
- Put phishing-resistant MFA on every remote access path
- Map vendor and subcontractor dependencies
- Set up backup routes for claims and payment workflows
- Tighten network separation between clinical, corporate, and vendor-connected systems
- Build manual fallback processes for claims, eligibility, and pharmacy work
- Treat cyber risk like a business, finance, and patient-care risk, not just a security task
Here’s the short version: one weak login and one shared vendor helped expose system-level risk across healthcare. If I were leading a hospital, payer, or large practice, I’d read this case as a warning about dependency, access control, and downtime planning all at once.
The Change Healthcare Ransomware Attack That Crippled U.S. Healthcare | Healthcare |

sbb-itb-535baee
The incident: what happened and how the disruption spread
Change Healthcare Ransomware Attack: Timeline & Impact by the Numbers
Attack timeline, entry point, and immediate operational fallout
On February 12, 2024, attackers got into Change Healthcare’s Citrix portal with stolen credentials. That portal did not have MFA. From there, they stayed inside for nine days without being caught and exfiltrated about 4 terabytes of data. [3][4] On February 21, ALPHV/BlackCat affiliates launched ransomware encryption, and Change Healthcare detected the intrusion. [3][4]
UnitedHealth Group then took more than 100 systems offline to contain the breach and protect the rest of the enterprise. [3][2] That move also shut down the EDI workflows behind claims submission, eligibility checks, payment processing, and pharmacy benefit transactions. [3][4]
| Date | Event |
|---|---|
| Feb. 12, 2024 | Attackers entered through the Citrix portal with stolen credentials; the portal lacked MFA [3][4] |
| Feb. 12–20, 2024 | Attackers moved across systems and exfiltrated about 4 terabytes of data [4] |
| Feb. 21, 2024 | Ransomware was deployed; Change Healthcare detected the intrusion and took more than 100 systems offline [3][4] |
| March 7, 2024 | Change Healthcare confirmed that sensitive health and financial data was stolen [3][4] |
| March 2024 | UnitedHealth Group paid a $22 million ransom [3][4] |
Those facts matter because the outage didn’t stop at Change Healthcare. It moved through links in the healthcare payment chain that many providers couldn’t even see.
Why the impact reached far beyond the primary target
Change Healthcare handles about 15 billion transactions each year. [1][5] So when it went down, the effects spread fast.
A big part of the problem was hidden reliance. Many providers didn’t know their billing ran through Change Healthcare at all, which meant they had no backup ready when systems failed. [5] In some cases, billing firms and subcontractors routed transactions through Change without telling clients about that dependency. [5] For small practices and rural providers, losing that cash flow wasn’t just a hassle. It could put the whole business at risk.
Reid Health, for example, was not directly breached, but it still said the outage disrupted revenue cycle work and claims processing. [1] UnitedHealth Group paid a $22 million ransom and later issued $9 billion in provider loans to help keep cash moving. [2][3]
What this showed, plain and simple, is how much strain can come from too much dependence on one vendor, weak segmentation, and poor recovery planning. Those cracks in the system come into sharper focus in the vulnerabilities the attack exposed next.
Systemic vulnerabilities the attack exposed
The attack laid bare three weak spots: vendor concentration, weak containment, and thin downtime planning.
Third-party concentration risk and limited vendor visibility
The clearest lesson here is concentration risk. Too many providers lean on a small set of clearinghouses and vendor chains they can't fully trace. They may know their direct vendors, but not the vendors behind those vendors. That blind spot matters. About 80% of stolen protected health information (PHI) in recent years came from third-party vendors and software services, not from hospitals themselves. [6]
A lot of healthcare groups still handle vendor security like a procurement checkbox, not a continuity problem. That mindset leaves them exposed when one outside partner fails and the damage ripples through billing, claims, and care operations.
Concentration risk gets worse when attackers aren't boxed in after they get access.
Legacy systems, weak segmentation, and lateral movement paths
Once attackers get in, segmentation decides how far they can go. In healthcare, that problem is often bigger than it should be. Unsupported operating systems, medical devices that can't be patched without FDA re-certification, and weak network separation can all widen the blast radius.
When systems are only loosely separated, attackers can move between environments that should be kept apart. That's the danger of lateral movement: one foothold turns into access across many systems.
Clinical, corporate, and managed-service environments need hard boundaries. Without them, a single intrusion can spread much farther than anyone expects.
If containment breaks down, recovery then comes down to one thing: whether the organization can still function without the vendor.
Downtime readiness and governance gaps
Most business continuity and disaster recovery plans were built for internal outages. A server fails, backups start, systems come back. That's a very different problem from losing a critical third-party vendor for weeks.
Plans that cover in-house infrastructure but skip the scenario of a clearinghouse going dark for six weeks aren't enough. Healthcare organizations need:
- Manual workflows
- Alternative routing
- Cash-flow contingencies for long vendor outages
This isn't just about IT recovery. It's about keeping claims moving, payments coming in, and care from getting delayed when a vendor is unavailable.
There's also a leadership issue here. Cyber risk is still too often treated as an IT or compliance matter instead of a clinical and business one. But when a vendor outage slows care and chokes off revenue, cyber risk becomes operational risk, highlighting the economic impact of third-party risk.
What healthcare organizations should do next
The Change Healthcare attack made one thing plain: the problem wasn't a single weak spot. It exposed weak links across hospitals, payers, and vendors. And it showed where leaders should act first.
The first job is vendor visibility. Hidden dependencies helped turn one breach into a market-wide outage.
Reduce exposure from vendors, fourth parties, and shared services
Most healthcare organizations know their direct vendors. Far fewer know who those vendors depend on - their vendors' vendors, or fourth parties. That can include billing companies and clearinghouses sitting upstream. And that's often where concentration risk stays out of sight. When one upstream vendor turns into a claims choke point, a single breach can jam the market [8].
Go deep enough in your mapping to answer a blunt question: if a critical vendor goes dark, what fails first, and what can staff handle by hand? That means documenting subcontractor chains in your Business Associate inventory and updating BAAs so downstream breach-notice and dependency-disclosure duties are spelled out [5].
Visibility matters. But on its own, it won't stop an attacker who's already inside.
Contain disruption with segmentation, modernization, and recovery planning
Weak segmentation and remote access controls gave the breach room to move far past the initial entry point. Start with phishing-resistant MFA on every remote-access path, including Citrix portals, VPNs, and RDP gateways. The Change Healthcare attack started through a Citrix portal that did not have MFA [8].
Then tighten access further. Use just-in-time access so admin rights aren't sitting there all the time. Watch credential-leak sources closely, and reset exposed passwords fast.
Downtime planning also needs to be practical, not just written down. Teams need manual fallback workflows for claims, eligibility, and pharmacy operations. They also need exercises built around a hard scenario: a critical vendor is offline for three weeks or more [7].
Containment only matters if the organization can still function when a key vendor goes offline.
Build governance that treats cyber risk as operational risk
When a vendor outage costs providers an estimated $100 million per day in lost revenue and directly affects patient care at 74% of hospitals, cyber risk is not just an IT issue. It's enterprise risk. It hits revenue cycle, patient care, and continuity of operations at the same time [6][7].
So governance has to match that reality. Set up an enterprise cyber risk committee with people from clinical operations, finance, compliance, supply chain, legal, and executive leadership - not just IT and security.
Ownership also needs to be plain:
- Compliance leaders own BAA downstream breach-notice requirements
- Procurement teams account for concentrated SaaS risk in contracts
- Clinical leaders own the manual fallback workflows that keep care moving when a vendor fails
The metrics below are worth tracking at the leadership level:
| Governance Metric | What It Measures | Target |
|---|---|---|
| MFA Coverage % | Remote access portal exposure | 100% phishing-resistant MFA [8] |
| Attacker Dwell Time | Detection effectiveness | Below the 9-day benchmark [8][6] |
| Vendor Dependency Depth | Concentration risk visibility | Mapped to the fourth-party level [5] |
| Electronic protected health information encryption status | Data protection at rest and in transit | 100% coverage [6] |
Conclusion: from one breach to a sector-wide resilience plan
The Change Healthcare attack was more than an MFA failure. It showed how one vendor outage can turn into a sector-wide breakdown across U.S. healthcare. In plain terms, resilience is a dependency, segmentation, and recovery issue - not just a malware issue.
Third-party dependency, legacy systems, weak segmentation, and poor governance create direct patient, clinical, and financial risk. A healthcare organization doesn't even need to be the main target to face immediate operational and financial damage. The table below links each weakness to the control that most directly lowers the risk.
| Systemic Weakness | Practical Control to Prioritize | Accountable Owner | Expected Resilience Outcome |
|---|---|---|---|
| Untracked vendor dependencies | Dependency mapping and multi-vendor redundancy for critical EDI/claims flows | Chief Supply Chain Officer / CISO | Reduced cascading disruption from single-point failures |
| Unprotected remote access portals | Phishing-resistant MFA on all remote access portals; decommission non-MFA systems | CIO | Elimination of common entry points for ransomware |
| Weak Segmentation | Micro-segmentation of vendor-access and clinical networks | Network Engineering / CISO | Contained blast radius; reduced lateral movement |
| Privileged access abuse | Multi-admin approval for destructive actions | IT Operations / CISO | Reduced risk of destructive changes across shared systems |
| Poor Downtime Readiness | Immutable, air-gapped backups and degraded-mode playbooks | Business Continuity Manager | Ability to maintain patient care and billing continuity during extended vendor outages |
| Governance Gaps | Integrated ERM that treats cyber as a clinical and financial risk | Board of Directors / CEO | Cyber risk treated as core enterprise risk |
FAQs
How can we find hidden fourth-party risks?
Look past direct vendor lists and map the clinical and business workflows each vendor supports.
A lot of fourth-party ties never show up in formal records. So it helps to review API logs, outbound traffic, and authentication activity to find hidden links, like shared cloud services or upstream identity providers. SBOMs and HBOMs can also surface embedded components that procurement teams may not see.
What should a hospital do if a key vendor goes offline?
If a key vendor goes offline, hospitals should switch at once to pre-tested downtime procedures that don't depend on internet access or other digital systems. The first priorities are patient safety, manual clinical work, and backup communication tools like radios or phone lines.
Healthcare leaders should also:
- Map workflow-level dependencies
- Rehearse total-loss downtime plans
- Maintain out-of-band communications and backup operational plans
How should leaders measure healthcare cyber resilience?
Healthcare leaders should measure cyber resilience by mapping dependencies across clinical and business workflows, not just counting technical assets. What matters most is simple: can care and core operations keep going during a disruption?
That means looking past servers and software inventories to see what each service depends on in day-to-day work. For something like ED triage or pharmacy verification, leaders need to pinpoint the systems, vendors, and data feeds behind the process.
They should also stress-test what happens if a key vendor goes down or a cloud service fails. At the same time, they need to track patient safety during outages and test contingency plans against actual downtime scenarios, not just paper exercises.