A vendor most patients never see was quietly emptied out.
Craneware an Edinburgh, Scotland-based healthcare technology company that heavily serves the U.S. market has confirmed it is investigating a cybersecurity incident in which a significant amount of data was stolen. Craneware builds accounting, pricing, and pharmacy software, and runs a cloud platform called Trisus that hospitals and pharmacies use to price services, manage drug programs, and bill patients.
In a cybersecurity incident notice filed on July 20, 2026, the company said that “a significant volume of file names were viewed and exfiltrated” before the attackers were forced out. “A percentage of Craneware employee data as well as a subset of customer and partner records have been accessed and exfiltrated,” the company stated. Its current assessment is that “a large element of the data involved is non-sensitive or already public regulatory data” but Craneware has not yet confirmed whether any patient data was compromised, and the review is still in its early stages.
Craneware says it activated its incident response plan and contained the incident with no disruption to customer services or its own operations. Outside investigators reported no further signs of compromise, indicating the attackers had been ejected from the network. There was no confirmed encryption or ransomware event disclosed this looks, so far, like a quiet data-theft intrusion at a vendor sitting at the center of thousands of healthcare organizations.
The reach of one healthcare software company
What we know so far
The Craneware breach at a glance
- The victim is a vendor, not a single hospital the exposure fans out to its entire customer base
- Employee data was accessed and exfiltrated
- A subset of customer and partner records was stolen
- A significant volume of file names was viewed and taken
- The company’s early assessment: much of the data is non-sensitive or already-public regulatory data
- Craneware has not yet confirmed whether patient data was involved
- The attack was reported to the UK’s Information Commissioner’s Office (ICO) and the U.S. FBI
- No threat actor has been named, and no group has publicly claimed responsibility
The unknowns are the point. Craneware itself does not yet know the full scope of what was taken, whether patient records are involved, or who was behind it. For the thousands of hospitals, clinics, and pharmacies that rely on the platform, that means waiting on a vendor’s investigation to learn whether their data and their patients’ data is on the loose. The breach is contained, but the accounting of it has only begun.
One vendor, thousands of front doors
This is supply-chain risk in its purest form. None of Craneware’s customers were themselves hacked they simply used a mainstream healthcare software platform, as thousands of providers do. But when that single vendor is compromised, the fallout does not stay put. It radiates outward to every organization whose records the vendor holds, each of which may now have to investigate, notify, and answer for data it never controlled directly.
Healthcare vendors are especially attractive targets precisely because of this multiplier. A single successful intrusion at a billing or pricing platform can yield data from hundreds or thousands of providers at once far more efficient for an attacker than breaking into one hospital at a time. That is why 2026 has seen a steady drumbeat of attacks on healthcare software makers, clearinghouses, and medical-device companies rather than on individual clinics.
And the lesson reaches well past healthcare. Every business hands sensitive data to outside platforms a billing service, a cloud application, a practice-management or case-management system, a document host. When you do, you inherit that vendor’s security posture, its incident response, and its timeline for telling you something went wrong. A medical practice, a law firm, or an accounting office is only as secure as the least-guarded platform holding its clients’ records and it usually finds out about a vendor breach on the vendor’s schedule, not its own.
The notifications haven’t even started yet
Craneware says it is “continuing to assess the precise nature and scope of all the data involved” and is working to identify affected parties and prepare appropriate notifications, including any further filings required by regulators. In plain terms: the breach-notification clock is running, but the letters have not gone out. Every customer organization is now waiting to learn whether it, too, must notify its own patients or clients.
That is where vendor breaches get legally complicated. Under HIPAA, a company like Craneware that handles protected health information on behalf of providers is typically a business associate contractually and legally obligated to safeguard that data and to notify the covered entities it serves. But the covered entities the hospitals and practices generally retain their own duty to notify affected individuals “without unreasonable delay and no later than 60 days” after discovery. When a vendor is slow to characterize a breach, its customers can be pushed right up against, or past, their own deadlines.
Here is the part every business owner should sit with: the intrusion happened at the vendor, but the regulatory and reputational exposure is shared and for many providers, the patient-facing notification obligation is entirely their own. Outsourcing where your data lives does not outsource your accountability for it. When a third party loses your clients’ records, you may still keep the deadlines, the regulators, and the hard conversations with the people whose data was exposed.
What your practice should do this week
- Inventory every vendor that touches your patient or client data. Your billing service, pricing and pharmacy software, EHR, clearinghouse, backup provider, and cloud storage all hold sensitive records. You can’t manage risk you can’t see start with a written list of who holds what.
- Get security commitments from each vendor in writing. Require a signed Business Associate Agreement (or equivalent), confirmation of MFA and encryption, and breach-notification terms with hard deadlines so a vendor can’t quietly investigate for weeks while your own clock runs.
- Ask your vendors directly about Craneware-style incidents. If you use Craneware, Trisus, or any billing/pricing platform, ask now whether your data was involved and when you’ll get a definitive answer. Silence is not the same as “you’re fine.”
- Rehearse a vendor-breach response before you need it. Write and practice a plan for what happens when a third party not your own network is the source of a breach: who you call, how fast you can notify, and how you document the timeline.
- Assume credentials and access will be abused, and limit the blast radius. Enforce multi-factor authentication everywhere, remove vendor and employee accounts the moment they’re no longer needed, and monitor access to sensitive systems so an intrusion doesn’t go unnoticed for weeks.
Your patients’ data rides on platforms you don’t own.
The Craneware breach is unsettling precisely because most of its customers did nothing wrong. They used a leading healthcare software platform, ran normal operations, and may still end up sending breach letters to their own patients because the company they trusted with pricing and billing data was quietly broken into. The most dangerous gap in your defenses may be one that isn’t on your network at all.
Every practice, firm, and office that hands data to an outside platform should ask the Craneware question now: if our vendor were breached tomorrow, would we even know and how long would our patients wait to find out? The organizations that come through incidents like this intact are the ones that treat vendor risk as their own risk, demand real notification commitments before they sign, and can name with confidence every outside platform holding their clients’ records and who is guarding it. If you can’t answer that today, that’s the gap to close now before a vendor’s breach becomes your notification letter.