Notifications
Clear all
Topic starter
19/08/2026 3:26 pm
TL;DR: Change Healthcare’s February 2024 ransomware attack exposed how a Citrix portal without MFA can cascade into claims disruption, PHI exposure, and regulatory liability for thousands of providers, according to Sprocket Security’s analysis. The incident shows that vendor assurance based on BAAs and questionnaires is not enough when third-party access controls govern patient data.
NHIMG editorial — based on content published by Sprocket Security covering the Change Healthcare ransomware breach and third-party PHI risk
By the numbers:
- 55% of healthcare data breaches now originate from a third-party vendor, according to Ponemon Institute’s 2023 Third-Party Risk in Healthcare report.
- 60% of organisations do not conduct a security assessment of a vendor before signing a contract granting PHI access, according to Ponemon Institute’s 2023 Third-Party Risk in Healthcare report.
Questions worth separating out
Q: What breaks when third-party access to PHI is not offboarded promptly?
A: Delayed offboarding leaves business associates, subcontractors, or integration accounts with access after the business need has ended.
Q: Why do vendor authentication failures create HIPAA exposure for covered entities?
A: Because HIPAA accountability does not stop at the contract boundary.
Q: How do organisations know whether their vendor risk monitoring is working?
A: Vendor risk monitoring is working when changes in posture, access, or behaviour trigger action before the next scheduled review.
Practitioner guidance
- Require verified MFA for every vendor portal touching PHI Do not accept attestation that MFA exists somewhere in the environment.
- Replace questionnaire-only assurance with evidence-based vendor testing Ask for recent penetration testing, external attack-surface findings, and remediation proof for the systems that handle claims or PHI.
- Tie business associate oversight to identity control checks Map each business associate to the identities, secrets, and sessions it uses to access regulated data.
What's in the full article
Sprocket Security's full article covers the operational detail this post intentionally leaves for the source:
- The specific healthcare vendor-risk questions and evidence checks the article recommends before granting PHI access.
- The control distinctions between a BAA, a questionnaire, and an independently verified security assessment.
- The maturity markers for continuous vendor monitoring, including how to treat changing external attack surfaces.
- The practical implications of continuous penetration testing for higher-risk health IT vendors.
👉 Read Sprocket Security's analysis of the Change Healthcare third-party PHI risk pattern →
Change Healthcare and PHI supply-chain risk: are your controls keeping up?
Explore further
19/08/2026 4:11 pm
Third-party access governance is now a core identity security problem. The Change Healthcare incident shows that external access to regulated systems can be the true control plane of enterprise risk. If a vendor identity can reach PHI, then IAM, PAM, and vendor oversight are inseparable. Practitioners should treat third-party identities as governed access paths, not contract artefacts.
A question worth separating out:
Q: Who is accountable when a business associate has broader PHI access than necessary?
A: The covered entity remains responsible for governing how PHI is shared, while the business associate must follow the contract and preserve minimum necessary handling. In practice, accountability should be shared across legal, privacy, IAM, and vendor management teams. If the relationship changes, access must change with it.
👉 Read our full editorial: Change Healthcare shows why third-party PHI risk is your risk
