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

At a glance

What this is: This analysis argues that the Change Healthcare ransomware incident exposed how third-party PHI access can turn a vendor-side security failure into a healthcare-wide operational and compliance crisis.

Why it matters: It matters to IAM, PAM, and GRC teams because business associate oversight, privileged vendor access, and authentication controls now directly shape PHI risk and HIPAA accountability.

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.

👉 Read Sprocket Security's analysis of the Change Healthcare third-party PHI risk pattern

Context

Change Healthcare is a third-party risk case, but the underlying issue is broader than healthcare. When a vendor holds sensitive data and exposes it through weak authentication or poor access controls, the customer inherits the operational, financial, and compliance fallout even if the breach never touches its own network.

In identity terms, this is a governance problem around trusted external access. A business associate agreement can define liability, but it cannot enforce multi-factor authentication, validate privileged access, or continuously test the vendor’s control environment.

The Change Healthcare incident is not typical because of its scale, but it is typical in mechanism: one weak entry point in a connected ecosystem can create a system-wide problem when access is already established and oversight is mostly documentary.

Key questions

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. That widens exposure, complicates breach analysis, and creates a gap between accountability and actual access. HIPAA governance fails when access outlives the relationship that justified it.

Q: Why do vendor authentication failures create HIPAA exposure for covered entities?

A: Because HIPAA accountability does not stop at the contract boundary. Covered entities still have to obtain satisfactory assurance that business associates safeguard PHI, and that means validating control effectiveness. If a vendor portal lacks MFA or testing, regulators can treat that as a governance failure, not just a vendor issue.

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. If the programme only produces cleaner questionnaires but no faster remediation, it is not detecting live risk. Effective monitoring creates a current, decision-ready view of vendor exposure rather than a historical record.

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.

Technical breakdown

Why third-party access turns into enterprise exposure

Health IT ecosystems rely on federated trust, subcontractors, and persistent integrations. That means a vendor’s authenticated access can reach claims, scheduling, credentialing, or EHR workflows without traversing the customer’s perimeter controls. If the vendor identity is trusted by design, the attacker does not need to breach the customer directly. They only need to abuse the trusted path. This is why vendor access governance is really an identity problem, not just a procurement problem. The strongest technical control is not a contract clause, but verified enforcement of authentication, session policy, and least privilege at the vendor edge.

Practical implication: Verify that every third-party path into PHI is separately controlled, monitored, and bounded by least privilege.

What a BAA can and cannot do in practice

A business associate agreement is a legal mechanism for allocating responsibility, notification, and remediation. It is not a control that blocks exploitation. It cannot force MFA, patch a Citrix gateway, or prove that a vendor’s external attack surface has been tested. In governance terms, BAAs often create a false sense of closure because they formalise accountability without validating technical readiness. The gap becomes dangerous when organisations treat attestation as evidence. For IAM and GRC teams, the issue is not whether the agreement exists, but whether the access it authorises is actually secured in operation.

Practical implication: Use BAAs as a legal baseline, then require evidence of controls that protect the exact systems holding PHI.

Why vendor authentication failures become compliance failures

When a third party uses weak or absent MFA on a portal that reaches regulated data, the failure is not only technical. It also becomes a control failure under the customer’s compliance obligations because the covered entity still has to obtain satisfactory assurance that PHI is safeguarded. In practice, that means auditors and regulators will look for due diligence, monitoring, and remediation follow-through, not just a signed document. The operational lesson is that identity assurance must extend beyond internal users to every external account, secret, and session that can touch regulated data.

Practical implication: Map external access to compliance obligations and evidence the controls that prove ongoing assurance, not one-time approval.

Threat narrative

Attacker objective: The attacker aimed to disrupt healthcare operations through ransomware while exploiting trusted third-party access to maximise leverage across the claims ecosystem.

1. Entry occurred through a Citrix portal that lacked multi-factor authentication, giving attackers a weak but trusted path into the vendor environment.
2. Escalation followed as the attacker used vendor-side access to move into systems supporting claims processing and healthcare operations.
3. Impact was system-wide disruption, with claims processing frozen and PHI exposure creating operational, financial, and regulatory fallout for providers.

NHI Mgmt Group analysis

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.

The real failure mode is assurance without verification. BAAs, questionnaires, and SOC 2 reports often create documentation-based confidence that is weaker than the access they are meant to govern. The gap is especially dangerous when authentication, session control, and patch status are never independently validated. Practitioners should convert attestation into evidence-based assurance.

Vendor authentication weakness becomes customer liability at the point of data exposure. When a business associate’s portal lacks MFA, the issue is not local to the vendor because it changes the customer’s compliance and operational exposure. This is where HIPAA, access governance, and incident response converge. Practitioners should make external authentication a monitored control, not a procurement checkbox.

Third-party PHI exposure creates lifecycle risk, not just onboarding risk. Organisations often over-focus on signing the contract and under-focus on monitoring what happens after access is granted. That leaves dormant trust relationships in place long after the original risk review has gone stale. Practitioners should manage vendor access as a living lifecycle with review, test, and offboarding triggers.

Continuous validation is the only workable response to connected healthcare ecosystems. The named concept here is vendor trust drift: the gradual gap between what a vendor was approved to do and what its environment actually allows over time. That drift is what turns a single weak portal into system-wide exposure. Practitioners should assume the approved state will decay unless it is continuously checked.

What this signals

Third-party access should now be treated as an identity perimeter in its own right. When external accounts can reach regulated data, the programme risk is less about where the attacker starts and more about which trust relationships remain active without continuous validation.

Vendor trust drift: the access a partner was approved for can diverge from the access it effectively has over time. That drift is where healthcare, IAM, and GRC teams need recurring evidence, not annual reassurance.

For identity teams, the operational signal is clear: every external authentication path, secret, and privileged session tied to PHI needs a lifecycle owner. Without that ownership, offboarding and review become theoretical even when the contract says they exist.

For practitioners

• Require verified MFA for every vendor portal touching PHI Do not accept attestation that MFA exists somewhere in the environment. Validate that MFA is enforced on the exact Citrix, VPN, SSO, and admin paths that reach PHI, and confirm exceptions are impossible or tightly time-bound.
• 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. Use the evidence to decide whether a vendor’s access should remain active or be restricted.
• Tie business associate oversight to identity control checks Map each business associate to the identities, secrets, and sessions it uses to access regulated data. Review those paths on a recurring schedule, and trigger reassessment when a vendor adds integrations, changes authentication, or expands PHI scope.
• Monitor high-risk vendor access as a living lifecycle Track onboarding, periodic review, escalation, and offboarding for every vendor with claims or PHI access. Treat stale access, unused integrations, and unreviewed subcontractors as active risk indicators rather than administrative leftovers.

Key takeaways

• The breach shows that third-party authentication weaknesses can become enterprise-wide PHI exposure, not isolated vendor incidents.
• The scale matters because healthcare customers inherit the operational and regulatory fallout when a trusted vendor access path fails.
• Verified MFA, evidence-based assurance, and continuous vendor lifecycle review are the controls that would have reduced the blast radius.

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.
• 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.
• Evidence-Based Assurance: Evidence-based assurance means validating that a vendor’s controls actually work, rather than accepting policy statements or completed questionnaires. In practice, it relies on testing, logging, external attack-surface review, and remediation proof to show that access to regulated data is genuinely controlled.
• Claim Trust Drift: Claim trust drift is the gap between where a token was issued and where it is later accepted without enough restriction. It happens when audience, issuer, or lifetime controls are too broad, allowing a valid cryptographic token to create invalid access across systems.

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.

👉 Sprocket Security's full post covers the vendor assessment gap, HIPAA accountability chain, and control evidence questions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to govern access beyond the human user. It helps security and identity teams build the control thinking needed for modern identity programmes.