Third-party access is now one of the biggest weak points in healthcare supply chain systems. I’m looking at a simple pattern: vendors, service providers, APIs, and service accounts often have too much access, too little review, and weak login controls. That mix has helped drive breaches that hit 184 million people in 2024, with 31 million more affected by mid-2025.
If you want the short version, here it is:
- Many breaches start outside the hospital, through a vendor or connected partner
- Weak or missing MFA is still a common failure point
- Shared accounts and extra privileges make misuse harder to track
- APIs, tokens, and service accounts are often missed in access reviews
- Fourth-party risk matters too, because a vendor’s vendor can become the entry point
- Care delivery can be disrupted, not just data exposed
The article also shows that this is not only a security problem. It affects claims, pharmacy access, device support, billing, and even patient treatment timelines. Cases like Change Healthcare, TriZetto, Kroll, and NYC Health + Hospitals show how one weak connection can spread across many providers.
Here’s the core takeaway I’d keep in mind: don’t focus only on whether a vendor has access. Focus on who has it, how they log in, what systems they can reach, how long access stays open, and whether subcontractors are in the chain.
A few controls stand out again and again:
- Use named accounts, not shared logins
- Require phishing-resistant MFA
- Limit vendors to task-based, time-limited access
- Track service accounts, API keys, and tokens like user identities
- Segment vendor connections so one stolen account cannot move far
- Review BAAs, audit rights, and subcontractor terms on a set schedule
- Keep a named internal owner for each high-risk vendor
- Test outage plans for vendor failures that last more than 72 hours
| Risk area | What keeps going wrong | What to fix first |
|---|---|---|
| Vendor logins | Missing MFA, shared credentials, stale access | Named accounts, MFA, timed access |
| Privileged access | Vendors can reach more systems than needed | Role limits, JIT access, no standing admin rights |
| Machine identities | APIs, tokens, and service accounts are poorly tracked | Inventory, rotation, lifecycle tracking |
| Vendor oversight | Access is reviewed too rarely | 90-day log checks, ownership, offboarding steps |
| Fourth-party exposure | Breach starts at a vendor’s vendor | Stronger BAA terms, subcontractor checks, audit rights |
If I had to sum up the article in one line, it would be this: healthcare supply chain risk is often an access-control problem hiding inside vendor relationships.
Reducing Third-Party Risk in Healthcare
sbb-itb-535baee
What Recent Studies Show About Third-Party Access Risk
Third-Party Access Risks in Healthcare: Key Stats & Breach Data 2024–2026
The research keeps pointing to the same issue: third-party access is now a major weak spot in healthcare.
Third parties were involved in 48% of all healthcare breaches in 2025, up 60% year over year from 30% the year before [2]. Another survey found that 90% of serious healthcare data breaches involve a third party, and the average hospital system is connected to more than 1,000 vendors [9]. At the same time, 60% of healthcare delivery organizations do not routinely monitor third-party access to sensitive information [4]. That leaves one big issue on the table: who gets access, how that access is watched, and when it is taken away.
Common Attack Paths Documented Across Studies
One of the main attack paths is weak authentication. Studies point to stolen vendor logins, vendor accounts with too much access, shared credentials, and long-lived tokens or API keys. Only 23% of third-party cloud platforms have fixed missing or misconfigured MFA [2]. In plain terms, attackers often don’t have to force their way in. They just sign in.
Supply chain incidents also slip past many standard access reviews because they often depend on integrations and machine identities that sit outside normal HR-based account checks [6].
Once attackers get in, researchers describe four ways a small breach can spread into a much bigger problem:
- Weak segmentation
- Alert floods that bury early warning signs
- Tightly coupled workflows
- Trusted-partner abuse [3]
Non-human identities, such as service accounts, tokens, and API connections, are another blind spot that keeps showing up in the data. 72% of organizations have experienced or suspect a breach involving NHIs, and enterprises that had a compromised NHI averaged 2.7 separate incidents over a 12-month period [5][6]. Organizations also estimate that more than 20% of non-human identities are not secured well enough [5][6].
The third parties that show up most often are usually the ones with persistent access, broad integrations, and weak oversight.
Which Third Parties Appear Most Often in Incident Data
Recent reports keep naming the same vendor groups in incident data: cloud procurement, claims and revenue cycle, pharmacy, logistics, and medical-device service vendors [4][2]. A small set of upstream vendors - especially claims processors and aggregators - drives most of the sector-wide risk [8].
In Q1 2026, just four upstream vendor breaches accounted for 67.6% of all patient impact - 10.75 million out of 15.9 million affected individuals [8]. One case stood out. TriZetto Provider Solutions, a healthcare payments and claims processing vendor, was breached in early 2026, exposing data for 3,433,965 patients and affecting about 9% of the OCHIN member network [8].
In May 2026, The Oncology Institute (TOI) disclosed a breach in which an unauthorized party accessed patient data through Kroll, the third-party administrator for one of TOI's software vendors [2]. That is the fourth-party pattern in action: the breach happens at a vendor’s vendor, which makes the chain of responsibility much harder to trace [2].
| Vendor Category | Example Entity | Primary Risk |
|---|---|---|
| Claims/Payment Processors | TriZetto Provider Solutions | High concentration; broad downstream impact [8] |
| Practice Aggregators | QualDerm Partners | Concentrated exposure across multiple specialty practices [8] |
| Benefit Platforms | Healthcare Interactive (HCIactive) | Exposure of insurance enrollment and sensitive PII/PHI [8] |
| Third-Party Administrators | Kroll | Fourth-party risk; access to software vendor environments [2] |
| Data Analytics | Insightin Health | Ransomware targeting payer and insurer data [8] |
Effects on Operations and Patient Care When Supply Chain Systems Are Compromised
When these access failures hit core supply chain systems, the fallout goes well beyond exposed records. It starts to disrupt day-to-day care. The average cost of a healthcare vendor-related breach is $4.88 million [9].
In February 2026, NYC Health + Hospitals - the largest public health system in the United States - found that attackers had been inside its network for eleven weeks, from November 25, 2025, to February 11, 2026. The breach exposed biometric identifiers and medical records for 1.8 million people and was tied to a security failure at a third-party vendor [7]. Cases like this don’t just create a data problem. They can interrupt medication dispensing, slow down diagnostic workflows, and put patient safety at risk [9].
Access Control Failures Repeatedly Found in Supply Chain Data Systems
The problem isn't just getting in. It's what happens after access is granted.
The breach data covered earlier shows a clear pattern: attackers often don't need to break down the door. They use access that already exists and wasn't tightly limited.
Over-Privileged Accounts, Shared Credentials, and Weak Authentication
Across healthcare research, one issue shows up again and again: vendor access often stays active too long, reaches too far, and becomes hard to track after approval. As Rich DeFabritus of Forescout puts it:
"Vendor access is frequently: Persistent rather than temporary; Broader than necessary for the task at hand; Extended to new systems and data over time; Poorly documented once approved." [1]
On the ground, this can get messy fast. A vendor may be hired to update one application, then end up with credentials that also reach EHRs, procurement systems, or clinical databases that have nothing to do with the original task.
Once those credentials are stolen, or passed around a vendor team, basic questions become hard to answer. Who logged in? What did they touch? When did it happen? Shared accounts blur responsibility and make forensic review much harder.
Weak authentication makes that risk worse. The February 2024 Change Healthcare breach showed the same pattern in plain terms: missing MFA on a vendor remote-access portal can lead to sector-wide disruption. One missing control at one vendor can ripple outward into a national event.
The same pattern also shows up in machine access, where identities are often created faster than they're reviewed.
Unmanaged APIs, Service Accounts, and Incomplete Asset Inventories
Machine identities are often tougher to track than user accounts. Service accounts, API keys, and integration tokens tie together EHR platforms, inventory systems, procurement tools, and third-party applications. After setup, those links are often left undocumented, which creates blind spots around integrations.
At the center of the issue is visibility. Many organizations can't clearly name every third party, what access it has, how it authenticates, or what network path it uses. Internal vendor records often miss 30% to 50% of connected vendors [10]. If an organization can't map its machine identities, it can't pull access fast or limit lateral movement with much confidence.
Comparison Table: Recurring Access Weaknesses and Their Impact
These access weaknesses show up again and again in healthcare supply chain systems.
| Access Weakness | Description | Impact on Supply Chain Operations | Impact on PHI/PII Exposure |
|---|---|---|---|
| Shared Accounts | One credential used by multiple vendor staff. | Prevents accountability; complicates incident isolation. | Makes it difficult to trace which individual accessed records. |
| Missing MFA | No second factor on vendor portals. | Allows easy entry via stolen credentials. | Increases the risk of identity-based access to sensitive patient data. |
| Over-Privileged Roles | Default admin-level access. | Enables lateral movement to ERP or clinical systems. | Broadens access to databases and EHRs beyond the vendor's role. |
| Unmanaged APIs | Undocumented EHR-to-third-party connections. | Creates entry points that bypass firewalls. | Can expose data undetected to unauthorized parties. |
| Weak Offboarding | Access left active after termination. | Maintains dormant accounts that can be hijacked. | Extends the risk of PHI exposure from residual connections. |
Healthcare organizations can't always shut off vendor access on the spot, even when risk is clear. Clinical systems often depend on those connections. Surgical systems, imaging tools, and infusion pumps may all rely on active third-party access, which turns this into a patient safety issue, not just an IT issue.
That's why the practical next step isn't broad vendor lockouts. It's tighter identity scoping, with access kept narrow, specific, and easier to review.
Research-Backed Controls and Operating Models for Risk Reduction
Because these failures show up again and again, the controls should too. The weak spots in access management from the last section can be addressed with controls most security teams already know well. The hard part isn't figuring out what to do. It's doing it the same way, every time.
Identity, Remote Access, and Zero Trust Controls Most Consistently Supported
Start with the basics that matter most: unique named accounts, phishing-resistant MFA on every vendor access point that can reach PHI, and task-specific access that expires when the work is done. Add JIT access and Zero Standing Privilege so elevated permissions exist ONLY when needed, then disappear by default.
Service accounts and API tokens need the same level of care as human users. Treat them as full identities, with short-lived tokens, set rotation schedules, and lifecycle tracking for every integration. If an integration can touch sensitive systems, it shouldn't sit in the shadows.
Network segmentation adds another layer of control. When vendor access is limited to specific segments, and those segments are tied to patient-critical assets, a stolen credential has far less room to move. That can make a bad day a lot less bad.
Contractual Governance, Continuous Monitoring, and Measurable Oversight
Technical controls cut exposure. Governance decides whether those controls keep working.
The strongest programs don't stop at access rules. They pair those rules with continuous oversight of vendors and their activity. That means moving away from point-in-time reviews and toward monitoring that reflects what's happening now.
For example, instead of checking access once a year, review the last 90 days of vendor authentication logs for off-hours logins or activity tied to dormant accounts. That kind of review is much more likely to catch trouble early. It also helps to assign a named internal business owner to every vendor relationship - someone responsible for approvals, periodic reviews, and offboarding. When ownership is vague, things slip.
On the contract side, Business Associate Agreements (BAAs) can't be treated like paperwork that's signed once and forgotten. Each active BAA should be checked to confirm it has been reviewed and updated within the past 24 months, and that it includes current breach notification clauses plus explicit audit rights. That's a direct step with compliance and incident response value. Third-party access needs continuous governance, not a one-time approval.
As vendors add more AI features, governance has to cover that layer too. Healthcare organizations are starting to set up AI governance committees and use frameworks such as the Health Sector Coordinating Council (HSCC) AI Cybersecurity Governance Framework to benchmark oversight of AI-enabled vendors [11].
Comparison Table: Mitigation Approaches and Implementation Considerations
| Mitigation Approach | Key Controls | Representative Source Types | Primary Healthcare Supply Chain Benefit | Implementation Considerations for U.S. HDOs |
|---|---|---|---|---|
| Identity & Access Management (IAM) | Unique named accounts, RBAC, JIT access, phishing-resistant MFA | Guidance (NIST CSF 2.0), Industry Reports (Imprivata) | Prevents credential abuse and ensures clear audit trails for PHI access | Requires workflow integration with vendor onboarding and offboarding |
| Secure Remote Access | Session monitoring, conditional access, VPN/gateway revocation | Case-based research (Change Healthcare lessons), Technical guidance | Limits the duration and scope of external connectivity to clinical systems | Needs session logging for forensics and incident response |
| Zero Trust Segmentation | Micro-segmentation, lateral movement prevention, continuous verification | Forescout research, NIST SP 800-207 | Contains ransomware blast radius and protects patient-critical IoT/IoMT devices | Needs real-time asset visibility, especially in legacy environments |
| Automated Third-Party Risk Assessment | Continuous monitoring, automated evidence collection, AI-assisted questionnaires | Industry best practices, KLAS Research | Replaces slow manual reviews with real-time vendor risk posture data | Requires integration with ongoing vendor lifecycle management |
| Contractual Controls | BAA language, incident notification terms, audit rights | HIPAA regulatory requirements | Establishes legal accountability and clear response protocols | Must be paired with technical enforcement and periodic review cycles |
Governance Priorities and Conclusion for U.S. Healthcare Leaders
What Healthcare Leaders Should Prioritize Next
The controls above matter. But governance is what decides whether those controls stick.
One number says a lot: 27% of healthcare organizations are still developing formal governance for third-party onboarding [11]. In plain English, a lot of teams are still handling third-party access risk without one steady system behind it.
The next step is to move past once-a-year questionnaires and build a connected governance model that covers the full vendor lifecycle workflows, from onboarding to offboarding. That structure should include PHI, clinical systems, IoT, medical devices, and supply chain platforms, so vendor-owned devices and unmanaged assets don’t slip past review [1]. It also helps to spell out ownership and escalation paths early. When nobody is sure who owns a vendor relationship, gaps tend to show up fast.
Leaders should put the most attention on access paths that could interrupt patient care if something goes wrong. That includes:
- Assigning a named internal owner to every high-risk vendor relationship
- Keeping tested contingency plans for vendor outages that last more than 72 hours [9]
- Requiring BAAs that extend security duties to subcontractors and require audit verification [9]
As the Dallas Federal Reserve research put it:
"The lesson is not to improve vendor questionnaires. The lesson is that questionnaire-based programmes are insufficient for critical vendor relationships." [9]
Boards and executive teams also need a short list of metrics that show whether governance works in day-to-day practice, not just on paper. Good examples include the share of PHI-handling vendors with verified MFA and encryption enforcement, vendor risk-tier distribution, and remediation timelines for high-risk findings [12]. Implementing a collaborative risk exchange can further streamline these governance workflows.
Research Gaps, AI-Related Risks, and Key Takeaways
Two issues now sit at the center of many governance reviews: AI-driven vendor changes and fourth-party exposure.
When a vendor adds AI after onboarding, many healthcare organizations still don’t have a set process to reassess risk. That can leave teams in a bad spot, where the vendor relationship looks the same on paper even though the risk profile has changed. Setting up an AI governance committee and using the HSCC Health Industry AI Cybersecurity Governance Framework can help leaders check how these tools are being overseen [11].
Fourth-party risk is still one of the toughest parts to verify. HITECH requires BAAs to extend security duties to subcontractors, but few organizations confirm that this happens in practice [9]. That leaves a stubborn gap in many TPRM programs: the breach happens at a vendor’s vendor, and tracing who was supposed to do what becomes almost impossible [9].
FAQs
Why is third-party access so risky in healthcare?
Third-party access creates risk in healthcare because vendor networks can turn into entry points for cyberattacks. That risk gets worse when organizations give vendors too much access, don’t watch what they do, or keep old credentials active longer than they should.
And this isn’t a small issue. Vendors often support mission-critical systems like EHRs and medical devices. If one of those connections is compromised, the damage can spread fast, disrupting patient care and exposing sensitive PHI.
What are non-human identities in supply chain systems?
In supply chain systems, non-human identities are machine-based credentials and automated ways for systems - not people - to log in and interact.
Common examples include API tokens, service accounts, OAuth grants, signing certificates, and CI/CD runner identities. When teams don’t govern them well, these identities can lead to persistent access, too many permissions, and blind spots in visibility. That mix can open the door to unauthorized lateral movement across a network.
How can hospitals reduce fourth-party access risk?
Hospitals can cut fourth-party access risk by keeping an up-to-date inventory of vendors and their subcontractors instead of leaning only on basic questionnaires. Business Associate Agreements (BAAs) should also state that subcontractors must meet the same security standards as primary vendors.
For high-risk partners, due diligence needs to go further. That can include penetration testing and vulnerability assessments to spot weak points before they turn into bigger problems.
Tools like Censinet RiskOps™ can help automate these evaluations, give teams better visibility into downstream dependencies, and support continuous monitoring.
