Change Healthcare 2024: How a Missing MFA Prompt Cost $22M and 100M Records.

What Happened

On February 21, 2024, Change Healthcare, a UnitedHealth Group subsidiary that processes roughly 15 billion healthcare transactions a year, detected an intrusion into its technology environment. Within hours, Change Healthcare took systems offline. The intrusion was later attributed by multiple sources to the ALPHV/BlackCat ransomware group.

UnitedHealth Group CEO Andrew Witty testified to the U.S. Senate Finance Committee on May 1, 2024, that the attackers gained initial access through a Citrix remote-access portal that was not protected by multi-factor authentication. Once inside, the attackers moved laterally through the Change Healthcare environment for approximately nine days before deploying ransomware.

The operational impact was national. Change Healthcare's platforms handle prescription claims, eligibility verification, payment processing, and other routine functions for a large share of U.S. providers and pharmacies. With those platforms offline, independent pharmacies struggled to verify insurance or process claims; hospitals and clinics reported disruptions to revenue cycle operations. The worst of the disruption lasted weeks for critical functions and months for some downstream services.

UnitedHealth Group disclosed to the U.S. Securities and Exchange Commission in its Q1 2024 earnings reporting that it had incurred approximately $872 million in direct costs during the quarter related to the attack. Witty testified that UnitedHealth paid the attackers a $22 million ransom in an attempt to protect affected data.

By October 2024, UnitedHealth had completed enough of its notification analysis to estimate that approximately 100 million individuals had protected health information affected by the breach. That figure makes Change Healthcare the largest HIPAA-covered breach in U.S. history.

The U.S. Department of Health and Human Services Office for Civil Rights (OCR) opened an investigation into the incident and issued industry-wide guidance on third-party risk management and HIPAA Security Rule compliance for clearinghouses and business associates in the weeks following the disclosure.

What Was Wrong

The root cause was a specific, well-understood control gap. A remote-access portal capable of reaching a covered entity's production environment did not require a second factor of authentication. A stolen or phished username and password was enough to log in.

This was not an exotic zero-day. It was not a novel supply-chain attack. It was an access-control failure on a control that has been table-stakes in healthcare IT for nearly a decade. The HIPAA Security Rule's access control standard (45 CFR §164.312(a)(1)) requires technical policies and procedures that limit electronic access to authorized users. The addressable implementation specifications have long been interpreted by auditors and by OCR to include multi-factor authentication where risk analysis indicates elevated sensitivity, which it clearly does for a clearinghouse processing data for roughly one in three Americans.

Secondary failures compounded the impact. Network segmentation was not sufficient to prevent nine days of lateral movement. Vendor risk analysis on the Citrix portal does not appear to have escalated the MFA gap. And the blast radius of the portal, meaning the data and systems reachable from a single successful login, was not proportional to the control posture.

A narrower technical observation: Citrix remote-access gateways are not inherently insecure. They are a well-understood technology. But they are also an enumerable attack surface, and they advertise themselves via TLS fingerprints and HTTP banners that threat actors continuously scan for. A publicly reachable Citrix portal without MFA is a known, indexed, pre-vetted target.

What We Would Do Differently

The Defender's lens on this case is unambiguous. A single-factor remote-access portal into an environment touching PHI at clearinghouse scale would not survive a tabletop risk review conducted by a competent CISO, much less OCR audit scrutiny. Every remote-access entry point should be enrolled in the identity provider, should require phishing-resistant MFA (FIDO2 where feasible, TOTP at minimum), and should be continuously logged to a SIEM with detection rules for unusual access patterns.

The Architect's lens adds that the portal design itself needed attention. Direct-to-production remote access is a pattern we actively engineer out of client environments. Zero-trust network access (ZTNA), device-posture checks, and least-privilege session constraints all raise the cost of a stolen credential to something approaching the cost of the data behind it. The correct pattern for a modern clearinghouse is a mediated, ephemeral, per-session gateway that enforces identity, device, and context before any connection reaches production.

We would also revisit the blast-radius math. Third-party platforms that process data for one in three Americans are effectively critical infrastructure. The control budget for those platforms should be calibrated to the aggregate risk they carry, not to the individual transaction they execute. That is a design principle, not a policy choice, and it is one that auditors and regulators are increasingly going to apply.

Finally, we would pressure-test vendor attestation. The gap between what a vendor's security attestation says and what its production configuration actually enforces is where most regulated-industry breaches now live. A BAA that says "we enforce MFA on all remote access" is not the same as MFA actually being enforced on all remote access. Treat attestations as hypotheses to verify, not guarantees to rely on.

The AI angle.

Every AI vendor your organization onboards in 2025 and beyond is going to ask for some form of remote access into your environment. A data connector to your CRM. An API gateway into your clinical system. A service-account credential on your identity provider. A webhook endpoint that reaches your document store. Each of these is functionally another Citrix portal — a remote-access surface with a credential, a scope, and a blast radius.

The Change Healthcare lesson applies directly to AI adoption. Enforce MFA at the identity-provider layer on every AI tool's access path. Enumerate the blast radius before you deploy, not after. Treat the vendor's security attestation (SOC 2, HIPAA BAA, ISO 27001) as a hypothesis to verify, not a guarantee to rely on. Require quarterly access reviews on every AI integration, not annual, because AI vendor behavior (new features, new scopes, new integrations) moves faster than annual cadence can catch.

Mid-market organizations that roll out AI faster than they rehearse this discipline are going to write their own version of the Change Healthcare case study inside the next twenty-four months. The failure mode will not be novel. It will be a forgotten MFA toggle on an AI integration that a vendor shipped with permissive defaults, compromised via a phished credential, reached into a regulated data store the vendor assured you was out of scope. That story is already being drafted. The only question is whose tenant it gets published under.

This Week's Action Items

• Audit every remote-access entry point. Pull a list of every VPN, Citrix, remote-desktop, and vendor portal that can reach production systems touching regulated data. For each, verify MFA is enforced at the identity-provider layer, not just "available."
• Review third-party remote access. Identify every vendor with any form of remote access into your environment. Require each to confirm MFA enforcement in writing within 30 days, and add the confirmation to your BAA file.
• Reassess your HIPAA risk analysis on remote access. If your most recent risk analysis predates your current remote-access footprint, schedule an update before the end of the quarter. OCR is looking for this.
• Model your blast radius. For each remote-access portal, answer: if a single credential is compromised, how many records does an attacker reach in the first hour? If the answer is greater than zero for any portal that touches PHI, the control budget for that portal is probably too low.
• Write the tabletop. Schedule a one-hour tabletop for the next leadership offsite: "A vendor remote-access portal without MFA is compromised on Monday at 4am. Walk the first 48 hours." Most teams have never done this drill.