The end-to-end encryption limitations that every healthcare security leader already knows about but rarely acts on just cost Medtronic nine million patient records. ShinyHunters lifted approximately nine million records out of medical technology titan Medtronic’s IT systems and is now threatening public release unless Medtronic pays their extortion demand. The records are believed to contain a mix of personally identifying information of patients and staff along with corporate intellectual property such as medical device design files and internal communications. Medtronic has confirmed the incident. The clock on customer notification, regulatory disclosure, and the predictable class-action wave is now running.
Healthcare CISOs read disclosures like this with a particular kind of dread, because every operational variable already on the desk multiplies. HIPAA has notification deadlines. State Attorneys General have separate notification timing requirements that often do not align. The FDA pays attention to medical-device manufacturers and expect adherence to its revised cybersecurity-framework guidance. Class-action plaintiff firms are primed to respond to breach events of this size. Every healthcare board that has been asking “could that happen to us?” will ask it again with greater urgency.
The Hack Was Not Sophisticated
The Medtronic disclosure is going to get framed as a sophisticated attacker doing sophisticated-attacker things. That framing is wrong. The hack exploited a known vulnerability known as the “decrypt to use” vulnerability.
The IT systems held a lot of sensitive data but left it exposed as plain text, and therefore simple for anyone to see. A hacker sitting on the inside of the network was able to review, select and steal data because their systems leave data unencrypted while the applications are running. Given that IT systems are almost never shut down and taken offline, that means that data is vulnerable to insider and hacker threats around the clock.
Encryption-at-rest, the control most large healthcare organizations point to when asked if data is encrypted, was likely configured at Medtronic. It did not matter. Encryption-at-rest only protects data at a small point in the data’s life. The moment the application needs certain data to perform a function such as serve a query, run a report, or sync to a downstream system; the data is decrypted and an attacker can pull it. If it is used regularly, it will remain in that clear text state indefinitely.
This is the same vulnerability that at the source of many different healthcare data breaches, from the early days of the 2015 Anthem breach to more recent events such as the Change Healthcare disclosure in 2024, and ongoing healthcare breaches that make headlines each week. The variable across those breaches was the entry point. The constant was that once the attacker had authenticated access, the data was in plain text and easy to parse and steal.
End-to-End Encryption Limitations: The Healthcare In Use Gap
If your encryption strategy only relies on encryption-at-rest and/or encryption-in-transit, you have an encryption strategy that misses 80+% of your data’s security exposure window.
The HIPAA Security Rule’s encryption requirement (45 CFR §164.312) is currently an addressable specification, not a required one, and the rule itself is older than the smartphone. Compliance with HIPAA encryption-at-rest is a floor, not a ceiling. Treating it as a ceiling is what produces the non-stop healthcare data losses that directly impact real people’s privacy and organizations’ intellectual property.
The answer is relatively new but logical: add encryption in use. Encryption in use (sometimes known as continuous encryption whose predecessor was homomorphic encryption) is the elegant answer.
The data stays encrypted while it is active as well as when at rest and in transit. When an attacker compromises the IT systems and goes looking for data, they come up empty handed and frustrated: forced to move on to another less well secured system. Meanwhile, operations continue unimpeded. Medical device-telemetry pipelines flow; the corporate finance team still runs its operations; the clinical systems still perform. All while keeping sensitive data such as PHI and corporate IP encrypted and secure.
What This Looks Like in Practice
In practice, encryption in use means the application never hands an attacker readable data: even when the attacker has valid credentials. Queries return ciphertext. Reports run against encrypted fields. Telemetry pipelines move data that stays encrypted end-to-end, including while it’s being processed. The PHI never surfaces in plaintext at the application layer, so there is nothing for an attacker to take that is usable.
This data architecture is not experimental. It deploys within existing data systems. It delivers remediation, not rip-and-replace. The cryptographic capabilities that make it practical at scale did not exist when HIPAA was written; but they exist now. What Medtronic and every similar breach confirm is that organizations relying on standard end-to-end encryption have a data vulnerability gap that continues to be exploited. The architectural reason why is explained in The Encryption At Rest Myth: why the controls most organizations point to leave data exposed during active use.
The Question for Your Security Team
Pull your most recent breach risk assessment and find the line item for encryption controls. Ask your security team, in writing, two questions.
- When our application is reading PHI to serve a query, is that PHI decrypted at any point?
- If it is, what would an authenticated but malicious actor be able to see?
If the answer to question one is “yes” and the answer to question two is “the data” your encryption control is leaving you vulnerable.
Moving Forward
Forward-leaning healthcare CISOs are embracing this reality and seeking options to solve it. They are issuing RFIs and running Proof of Concepts for encryption-in-use platforms because they have concluded that a breach disclosure with their organization’s name on it will read the same way unless they think differently. The cost of not solving it is well-documented. Healthcare breaches averaged $7.42 million in 2025; a number that does not include the reputational cost or the regulatory exposure that follows a breach of this profile. The procurement language work to specify healthcare encryption in use is not difficult. The sourcing is the hard part; and that work is best done proactively rather than after the fact.
If you are working on the encryption-in-use question for your own healthcare environment and want to see how Donoma is solving this challenge, schedule a no-obligation briefing today.
Frequently Asked Questions
What are the limitations of end-to-end encryption in healthcare?
“End-to-end encryption” is a marketing phrase that sounds comprehensive but describes something much narrower. It protects data at the two ends of its journey: at rest in storage and in transit between systems. What it does not protect is the middle; the moment data is actively being processed by an application. When a healthcare system queries patient records, runs a report, syncs telemetry, or processes a claim, the data must decrypt for the application to function. That window is when attackers with authenticated access find plain-text data they can read, select, and steal. The Medtronic breach exploited exactly this gap. HIPAA’s encryption-at-rest requirement does not address it either.
Why did encryption fail to protect Medtronic’s patient records?
Medtronic almost certainly had encryption-at-rest in place. That control protects data only when it is sitting inactive in storage. The moment an application reads that data to serve a function, it decrypts. An attacker with access to the running system finds readable plain-text data, not encrypted storage. ShinyHunters exploited this standard vulnerability, not a novel one. The entry point was the variable; the exposed plain-text data at the application layer was the constant.
What is encryption in use and how does it close the gap?
Encryption in use (also called continuous encryption) keeps data encrypted throughout its entire lifecycle including during active processing. Queries run against encrypted fields. Reports execute on encrypted data. Telemetry pipelines move data that stays encrypted end to end including while being processed. An attacker who gains authenticated access to the system finds ciphertext, not patient records. There is nothing readable to exfiltrate, nothing to ransom, and no notification obligation if no plain-text data was exposed.
Does HIPAA require encryption of data in use?
No. HIPAA’s encryption specification under 45 CFR §164.312 is an addressable but not required control, and it predates the widespread use of continuous encryption technology. Compliance with HIPAA encryption-at-rest is a floor, not a ceiling. Healthcare organizations that treat HIPAA compliance as the complete answer to their encryption posture are leaving the largest exposure window unaddressed. Regulatory and legal standards are evolving; courts and regulators are beginning to ask why available technology was not deployed.
What healthcare organizations are most at risk from encryption-in-use gaps?
Any healthcare organization whose applications decrypt data during active processing is at risk; which is virtually every organization using standard database and application infrastructure. Medical device manufacturers like Medtronic carry additional exposure because their data includes both PHI and corporate intellectual property such as device design files. Health insurers, hospital systems, and healthcare technology vendors that process claims or clinical data at scale face the same underlying vulnerability.
How does continuous encryption affect clinical operations?
Properly implemented continuous encryption is operationally transparent. Medical device telemetry pipelines continue to flow. Clinical systems perform as usual. The corporate finance team runs its operations without interruption. Authorized users work as they always have. What changes is what an attacker finds if they breach the perimeter: encrypted ciphertext instead of readable patient data. The protection operates below the application layer without disrupting workflows above it.
Additional Reading
The Encryption At Rest Myth: Why Your Encryption Strategy Fails to Protect Data
