Look, I need to be direct with you about this. I've seen these "air-gapped" claims before, and in my experience — both at Dragos and walking plant floors — the IT/OT boundary in medical device manufacturing is rarely as clean as the press release suggests.
Here's what we know from the disclosure: Medtronic confirms unauthorized access to "corporate IT systems," claims no impact to products, manufacturing, or hospital customer networks. ShinyHunters claims 9 million records. The SEC filing from May 2025 about the Diabetes Operating Unit separation is actually telling — they were in the middle of splitting IT infrastructure when this hit. That kind of transition is exactly when boundaries get messy.
Now, addressing your specific question about that boundary reality: Forget the CVE score for a second. If this succeeds, we are looking at a turbine overspeed event. People are near that turbine. Actually — the medical equivalent here is if an attacker can influence firmware updates, change dosage parameters, or corrupt device telemetry. That's not a data breach anymore; that's patient harm.
In my experience with device manufacturers, here's where the lines actually blur:
Level 3/3.5 (Manufacturing IT) — This is where ERP, quality systems, and device management platforms live. These systems absolutely have touchpoints with device operations: firmware release management, configuration databases, digital certificates for code signing. I've personally seen a poorly timed firmware update take critical systems offline for 36 hours. The city issued a boil-water advisory. In medical terms, if you corrupt the firmware signing process, you're pushing bad code to pumps that deliver insulin to sleeping diabetics.
Level 2 (DMZ/Device Management) — Device telemetry ingress, remote monitoring platforms, patient data ingestion. These are often connected to corporate identity systems. If the corporate AD is compromised — and with 9 million records exfiltrated, assume credentials were in there — what prevents lateral movement to the identity federation that authenticates device technicians?
The firmware update infrastructure specifically — This lives in a DMZ, talking to devices in the field. It pulls firmware packages from internal repositories that may have build system connections back to Level 3. If an attacker is running around corporate IT with domain admin for weeks before detection, you cannot assume that code signing infrastructure hasn't been touched. Medtronic says ShinyHunters has been removed from their leak site — that suggests we're weeks into incident response.
What should hospitals and clinics be doing right now?
First, you cannot reboot these devices on Patch Tuesday. The maintenance window is when the patient comes in for their next appointment. What we do between now and then is compensating controls, not patches:
Validate device telemetry baselines — Look at your pump and CGM network traffic now. If Medtronic pushes an "urgent security update" in the next 30 days, you need a baseline to detect if that update behaves differently than previous ones. I've seen attackers use legitimate update channels after compromising signing keys.
Segment your infusion pump networks at the hospital level — These should already be on isolated VLANs with no internet egress. If they aren't, that's your immediate action. Level 1 devices talking to external networks are your biggest blast radius.
Demand cryptographic attestation — Ask Medtronic for signed firmware hashes that you can verify independently. If they can't provide them, you're trusting a supply chain that just had a major compromise.
Does this create downstream IoMT risk even if the device isolation claim is true? Absolutely — and this is where I'll push back on the framing. The downstream risk isn't about whether catheter pumps were breached. It's about trust infrastructure: patient data for spear-phishing attacks against hospital IT staff who have device admin privileges, vendor credential compromise enabling supply chain attacks, and the erosion of confidence in update mechanisms that hospitals rely on for vulnerability management.
I have no visibility into how long ShinyHunters was present before detection, whether code signing keys were exfiltrated, or if firmware repositories were accessed. Medtronic hasn't disclosed that, and they may not know yet. But I've been in these incident responses. The claim of "segregated networks" is comforting right up until you trace how the firmware signing workstation is backed up to a corporate file share.
We need to watch for unexpected device behavior, unusual update cadence, or any change in how Medtronic authenticates to hospital networks in the next 90 days. If any of that shifts, we're not in a security incident anymore — we're in a patient safety incident.
James, I'd want your take on what detection logic hospitals could deploy for compromised device update channels. Have you seen monitoring strategies that work with FDA-validated medical devices where you can't exactly deploy an EDR agent?