Two healthcare breaches surfaced in July 2026, and neither involved a software vulnerability. Both involved somebody your organisation had decided to trust.
Medtronic: 3.8 million notified
Per Veracode's CISO briefing, the Medtronic incident occurred in April 2026 and notifications went out in July 2026 — a three-month gap that is itself worth noting. Attribution points to ShinyHunters, the extortion-linked group.
Scale: approximately 3.8 million individuals notified, against roughly 9 million records claimed by the actors. Exposed data included names, contact details, dates of birth, Social Security numbers, and health-related information.
The affected systems were corporate IT — not device or operational technology. That distinction matters and deserves to be stated clearly, because "medical device company breached" invites a conclusion about implanted devices that the facts do not support. The compromise was of the enterprise, not the pacemaker.
AdaptHealth: the contractor session
Disclosed 2 July 2026, and methodologically similar enough that Veracode assesses ShinyHunters as the likely actor.
The entry vector: social engineering against a third-party contractor, leading to session compromise. From there, attackers reached cloud applications, patient management systems, and external EHR portals, exfiltrating PII, PHI, and insurance billing credentials.
No exploit. No CVE. No zero-day. A human being with legitimate access was talked out of their session, and the session was enough.
The pattern
Put these next to the June and July software supply chain incidents — Polymarket's compromised vendor, the AsyncAPI bot token, the jscrambler publishing credentials — and one shape emerges across all of them:
The attacker did not defeat a control. They inherited a trust relationship.
- Polymarket: trusted a vendor's script
- AsyncAPI: trusted a bot's identity
- jscrambler: trusted a publishing credential
- AdaptHealth: trusted a contractor's session
- Medtronic: trusted a third-party connection
Every one of these was an intentional grant. Somebody approved each of them, usually for a good reason, usually years ago, usually with a review that has never been repeated.
This is why third-party risk management as most organisations practise it does not work. The annual questionnaire establishes that the vendor has a security programme. It does not establish what that vendor's code can reach in your environment today, which of their sessions are still live, what scope their tokens carry, or whether the contractor onboarded for a six-week project in 2024 still has an active account.
TPRM that is disconnected from technical reality is documentation, not defence.
What healthcare-specific pressure adds
For covered entities and business associates, this is not only a security problem:
- HIPAA breach notification obligations, with the 60-day clock and the OCR portal for breaches affecting 500+ individuals.
- Business associate agreements that need to have actually specified the security obligations you are now relying on.
- State-level requirements layered on top, several materially stricter than HIPAA.
- The three-month gap between the Medtronic incident and notification will attract regulatory attention on its own, independent of the breach.
And the population affected is the least able to respond. A stolen SSN attached to health information is not a password you rotate. It is a permanent identity exposure for 3.8 million people.
What actually reduces this exposure
Contractor access with an expiry by default. Not "we review quarterly" — access that expires on the project end date unless someone actively renews it. The default state of a contractor account after their engagement ends should be gone, not dormant.
Session hygiene as a real control. Short session lifetimes, re-authentication for sensitive operations, device binding, and — critically — the ability to enumerate and revoke live third-party sessions in minutes. AdaptHealth's incident turned on a session; the containment question is how quickly a session can be killed once suspected.
Phishing-resistant MFA for all third-party access. ShinyHunters' methodology is social engineering. SMS and TOTP codes are relayed in real time; hardware-backed WebAuthn is not.
Scope third-party integrations to the minimum data set. Most vendor integrations are granted read access to whole record sets because scoping them was harder than not scoping them.
Authenticated exposure testing of the portals themselves. External EHR portals and patient management systems are internet-facing applications holding PHI, and they need to be tested as such — logged in, in their real deployed configuration.
Vendor inventory tied to data classification. Which third parties touch PHI? Most organisations cannot produce that list on demand, and it is the first thing a regulator asks for.
How Safeguard helps, at scale
TPRM connected to actual technical exposure. Safeguard's third-party risk management ties vendor posture to what that vendor's code and integrations can genuinely reach in your environment — so prioritisation reflects blast radius rather than questionnaire completeness. For a health system with 400 vendor relationships, that ordering is the whole game: the vendor with an API token against your patient records is not the same risk as the vendor who prints your letterhead, and a spreadsheet treats them identically.
Authenticated DAST against the systems that actually hold the data. Safeguard's first-party DAST tests running applications behind authentication — external portals, patient management interfaces, cloud apps — surfacing exposure in the deployed configuration rather than only in source. This is the layer where the AdaptHealth-class systems live, and it is the layer most application security programmes skip because it is harder than scanning a repository.
Compliance packs and audit-ready evidence. Safeguard produces per-release CycloneDX and SPDX SBOMs, VEX statements, and SLSA provenance, with compliance mappings including HIPAA-relevant controls alongside DORA, NIS2, EU CRA, FDA premarket, SOC 2, ISO, and FedRAMP. When notification obligations start a 60-day clock, the difference between a programme with continuous evidence and one that assembles evidence during the incident is measured in regulatory outcomes.
Lion, for the credential and session layer. Lion enforces just-in-time secret brokering, capability scoping, egress allowlists, and signed audit trails — so a compromised third-party or contractor context holds no standing credentials, reaches only what it was scoped to, cannot exfiltrate to an arbitrary destination, and leaves a reviewable record. Against an actor whose method is social engineering rather than exploitation, reducing what a successful social-engineering attempt yields is the only durable control.
Eagle for prioritisation across a large regulated estate. Eagle reasons over exploitability and context to cut false positives by roughly 80% and compress remediation from 45 days to 3 — which for an organisation with thousands of findings across hundreds of applications is what makes a defensible remediation programme possible rather than theoretical.
Griffin for the remediation volume. Griffin authors and tests fix PRs autonomously through your existing merge gates, so the findings that matter get closed rather than accumulating in a register that gets shown to auditors as evidence of awareness.
Neither of these breaches needed a clever attacker. They needed an organisation that had granted access and then stopped looking at it.
Sources: Veracode: Supply Chain Compromises from June and July 2026 · Veracode: Cyber Risk Intelligence, July 2026
