Change Healthcare shows why third-party PHI risk is your risk

At a glance

What this is: Sprocket Security argues that the Change Healthcare breach turned third-party PHI access into a system-wide healthcare outage because a vendor-facing Citrix portal lacked MFA.

Why it matters: It matters because IAM, PAM, and vendor risk teams have to treat external access to PHI as part of their own control boundary, not as an outsourced obligation.

By the numbers:

• The American Hospital Association estimated the average impact on individual hospitals at nearly $10.9 million.
• Ponemon Institute research cited by Sprocket Security found that 55% of healthcare data breaches now originate from a third-party vendor.
• Ponemon Institute research cited by Sprocket Security found that 60% of organisations do not conduct a security assessment of a vendor before signing a PHI access contract.

Context

Third-party health IT risk is an access governance problem as much as a vendor management problem. When a clearinghouse, billing platform, or integration partner can reach PHI, its authentication controls, session controls, and offboarding discipline become part of the covered entity’s real security perimeter.

Change Healthcare is a clear example of why a signed business associate agreement does not equal control assurance. The organisation did not need to be inside a provider’s network to disrupt operations, which makes this a direct IAM and vendor-access lesson for healthcare programmes and any identity governance team overseeing external access.

The article’s underlying point is that healthcare supply chains are tightly coupled, and that coupling makes external identity boundaries hard to see and harder to govern. That pattern is common rather than exceptional in modern health IT ecosystems.

Key questions

Q: What fails when a healthcare vendor has PHI access without MFA?

A: The failure is not limited to account compromise. Without MFA, a stolen password can open a trusted third-party workflow that looks legitimate to downstream systems, which allows attackers to reach PHI, claims systems, or administrative functions through an authorised session path. In healthcare, that makes a single weak login control an enterprise exposure point.

Q: Why do business associate agreements matter when third parties handle PHI?

A: Business associate agreements matter because they formalise HIPAA obligations for vendors and service providers that use or disclose PHI on a covered entity’s behalf. The agreement should require appropriate safeguards, limit permissible use, and define accountability. Without it, organisations lose clear control over downstream handling of sensitive patient data and increase compliance and breach exposure.

Q: How do security teams know whether PHI access is actually controlled?

A: They should be able to produce a current identity and access inventory for every PHI system, show when each entitlement was last reviewed, and explain why each privileged role still exists. If they cannot do that, access is being managed by assumption rather than control. Visibility is the measurement here, not policy language.

Q: What should organisations do after a vendor breach is discovered?

A: Once a vendor breach is confirmed, the priority is to contain exposure, notify the right stakeholders, and reassess all data shared with that supplier. Review access paths, rotate credentials if any were exposed, and confirm whether customer notification or regulatory reporting is required. Then test the incident response plan so the next third-party event is handled faster and more consistently.

Technical breakdown

Why vendor-facing portals become the real trust boundary

A vendor portal is often the first authenticated touchpoint into PHI workflows, so the security properties of that portal matter as much as internal controls. If MFA is missing, a stolen or guessed password can be enough to enter a trusted workflow that looks legitimate to downstream systems. In healthcare, that trust boundary is amplified because claims, referrals, credentialing, and scheduling systems frequently depend on federation or credentialed access across organisations. The result is that one weak external access point can become a high-trust entry path into data and operations.

Practical implication: treat every third-party login path to PHI as a privileged access path and require enforced MFA plus session monitoring.

Why BAAs do not function as security controls

A business associate agreement allocates legal responsibility, notification duties, and contractual expectations, but it does not enforce authentication, patching, logging, or segmentation. That difference matters because many healthcare risk programmes confuse evidence of paper compliance with evidence of operational control. A vendor can sign a BAA, return a questionnaire, and still expose PHI through a vulnerable internet-facing service. The governance failure is assuming contractual assurance substitutes for technical assurance. For identity teams, that is the same mistake as assuming a policy exists because a process document exists.

Practical implication: pair contractual review with verified control testing before any vendor gets PHI access.

How third-party identity sprawl expands the attack path

Health IT environments rarely rely on one vendor. They rely on chains of subcontractors, integrations, and delegated access relationships that create a broader identity plane than most security teams can easily map. Each authorised connection can carry its own credentials, tokens, and administrative exceptions, which means the attack surface is not limited to your direct suppliers. Once an attacker compromises a smaller integration partner, they can move laterally through legitimate access rather than through noisy exploitation. That is why third-party identity inventory is now a core governance requirement, not a documentation exercise.

Practical implication: inventory every external identity and integration that can reach PHI, then review the access path end to end.

Threat narrative

Attacker objective: The attacker aimed to obtain leverage through disruptive access to a high-value healthcare platform, then convert that access into ransomware impact and broader operational fallout.

1. Entry occurred through a Citrix portal without multi-factor authentication, giving the attacker a valid access path into the vendor environment.
2. The attacker used that access to launch ransomware operations inside Change Healthcare’s environment while remaining within an authorised-looking session.
3. The impact was operational paralysis for claims processing, broad PHI exposure, and downstream financial and compliance consequences for healthcare providers.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party PHI access is now an identity governance problem, not just a vendor assurance problem. When external systems can process claims, schedule care, or credential staff, their authentication posture becomes part of the covered entity’s control boundary. That means IAM and PAM teams need to treat delegated access, not just internal accounts, as governed identities. Practitioners should assume the real perimeter is the trust relationship, not the firewall.

Satisfactory assurance is the governance gap this breach exposed. The failure mode is not merely that a vendor was breached, but that many programmes mistake contracts, questionnaires, and BAAs for operational verification. That assumption collapses when a third party’s exposed portal is enough to disrupt payments and expose PHI. The practical conclusion is that assurance must be evidence-based, not declarative.

PHI supply-chain risk is a form of identity sprawl with legal consequences. The more vendors, subcontractors, and integrations that can reach patient data, the more likely it is that one weak credential path becomes an enterprise incident. Third-party access blast radius: the scope of damage created when an external identity is overtrusted or insufficiently isolated. Security teams should use that lens to prioritise external identities with direct access to regulated data.

Healthcare resilience now depends on external access governance as much as internal detection. The article shows that business continuity can fail before internal tools ever trigger, because the compromise lives in a supplier environment. That makes onboarding verification, continuous oversight, and offboarding discipline part of operational resilience. Practitioners should align vendor access controls to the same governance standard they apply to privileged internal access.

From our research library:

• Only 36% of health IT leaders say their organisation applies a privileged access strategy consistently across the enterprise, according to Ponemon Institute research.

What this signals

Third-party PHI access is an identity boundary, not an externality. Healthcare programmes need to stop treating vendor access as someone else’s authentication problem. Once a supplier can touch claims or patient data, its credential lifecycle and session controls become part of the reader’s own risk posture.

Satisfactory assurance has to move from paperwork to proof. The practical test is whether a vendor’s access can be independently verified, not whether it can be described in a questionnaire. That shift aligns healthcare vendor oversight with the broader direction of identity governance: trust less, verify more.

External identity sprawl is the real multiplier. The more subcontractors and integrated services that can reach PHI, the more likely one weak login path will create a system-wide incident. Security teams should prioritise the suppliers with the deepest data reach first, because they define the largest blast radius.

For practitioners

• Enforce MFA on every third-party PHI access path Require multi-factor authentication on all portals, remote access channels, and administrative interfaces that can reach PHI, including vendor-supported workflows and integrated claims systems.
• Verify vendor controls before PHI access is granted Do not rely on BAAs or questionnaires alone. Test whether the vendor actually enforces the controls it claims, especially authentication, patching, logging, and external exposure management.
• Map the full PHI vendor chain Inventory direct vendors, subcontractors, and integration partners that can touch claims or patient data, then document which identities, tokens, and sessions each one uses.
• Set explicit breach notification and testing requirements Write measurable security clauses into vendor contracts, including penetration testing frequency, remediation timelines for critical vulnerabilities, and notification windows for confirmed incidents.

Key takeaways

• The Change Healthcare incident shows that a single weak external access path can turn a supplier breach into a healthcare-wide operational event.
• The article ties the breach to missing MFA, large-scale PHI exposure, and material financial impact for providers.
• The control lesson is to verify vendor identity controls directly, not to rely on BAAs, questionnaires, or contractual assurances alone.

Key terms

• Business Associate: A business associate is any external organisation that handles PHI on behalf of a covered entity. The term matters because liability and security obligations extend beyond the primary healthcare provider, making third-party access governance, contract terms, and technical controls part of the same compliance chain.
• Satisfactory Assurance: Satisfactory assurance is the standard that covered entities must use when deciding whether a business associate is protecting PHI adequately. It requires more than a signed contract and should be supported by evidence, verification, and ongoing oversight of the vendor’s actual security controls.
• Third-Party PHI Risk: Third-party PHI risk is the possibility that a vendor, subcontractor, or integration partner will expose protected health information through weak controls or compromised access. It is an identity and governance problem as much as a security problem because the customer remains tied to the trust chain.
• External Identity: An external identity is an account or access path owned outside the organisation but trusted inside it, such as a partner, vendor, contractor, or temporary worker. These identities enlarge the attack surface because they are harder to govern consistently and often fall outside standard employee lifecycle processes.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programmes they run across vendors, cloud, and internal services.