Topic starter
19/08/2026 3:26 pm
TL;DR: A Citrix portal without MFA turned Change Healthcare into a healthcare-wide exposure point, Sprocket Security reports, with claims disruption, PHI exposure and regulatory liability following. Third-party access needs direct verification, because contracts alone do not show whether patient data paths are actually controlled.
Editorial analysis by NHI Mgmt Group, based on content published by Sprocket Security: “Why Your EHR Vendor’s Security Is Your Compliance Problem”.
Key questions
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.
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.
Q: What fails when a healthcare vendor has PHI access without MFA?
A: The failure is not limited to account compromise.
Practitioner guidance
- 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.
- 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.
Bottom line: The Change Healthcare incident shows that a single weak external access path can turn a supplier breach into a healthcare-wide operational event.
Glossary terms: Third-Party PHI Risk, Business Associate, Satisfactory Assurance, External Identity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
19/08/2026 4:11 pm
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.
A few things that frame the scale:
- Only 36% of health IT leaders say their organisation applies a privileged access strategy consistently across the enterprise, according to Ponemon Institute research.
A question worth separating out:
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.
👉 Read our full editorial: Change Healthcare shows why third-party PHI risk is your risk