When a healthcare software vendor is breached, the exposure does not stop at the vendor's perimeter. It extends to every file its customers sent it, every credential it holds into customer environments, and every record of those exchanges that exists only in the vendor's systems. Most hospitals learn the scope of their own exposure months later, from the vendor, on the vendor's timeline.

The Craneware incident disclosed on July 20, 2026 is a clear example of that structure. Here is what happened, why a back-office vendor breach reaches so far, and what a health system can verify without waiting for anyone else.

What happened at Craneware?

Craneware, an Edinburgh-based healthcare financial software company, filed a notice with the London Stock Exchange on July 20, 2026 disclosing unauthorized access to a subset of its data environment. The company reported that a significant volume of file names were viewed and exfiltrated, along with a percentage of employee data and a subset of customer and partner records. Craneware's assessment at the time of disclosure was that a large portion of the data involved was non-sensitive or already public regulatory data, with the investigation ongoing.

Craneware notified the United Kingdom's Information Commissioner's Office and the United States Federal Bureau of Investigation. The company said its incident response plan contained the incident without disruption to customer service, and that external investigators found no further indicators of compromise.

Scale is what matters for United States providers. Craneware's billing, pricing, and pharmacy software is used by more than 2,000 hospitals and close to 10,000 clinics and retail pharmacies, according to the company. As of disclosure, Craneware had not confirmed whether patient information was among the stolen files, a question that determines whether United States health privacy rules apply to the affected data.

Sources: Cybersecurity Dive, The Record, HIPAA Journal

What is third-party risk in healthcare data exchange?

Third-party risk in healthcare data exchange is the exposure a provider organization carries through the vendors, clearinghouses, and business associates it sends sensitive data to, or that hold standing access into its systems. It is distinct from the organization's own security posture because the provider does not control the vendor's architecture, cannot audit it continuously, and typically cannot verify the scope of a vendor incident independently.

The category has grown quickly. Fortified Health Security reported that healthcare providers identified six times more supply-chain risks in the first half of 2026 than in the first half of 2025, with nearly two-thirds of those risks rated critical or high severity.

Which of your vendors look like this?

The Craneware pattern is not specific to chargemaster software. It applies to any vendor that sits between many provider organizations and holds their data. In a typical health system that includes:

• Revenue cycle and chargemaster platforms
• Claims clearinghouses and billing services
• Coding, auditing, and clinical documentation improvement vendors
• Pharmacy and 340B administration platforms
• Transcription and dictation services
• Patient communication, statement, and collection vendors
• Electronic health record hosting and integration partners
• Release of information and records-request processors

If a vendor appears on your business associate agreement list and receives recurring files, it belongs on this list. Our healthcare data exchange overview covers how these relationships typically map to real file flows.

Why does a back-office vendor breach reach so many hospitals at once?

Because the vendor sits between them. A revenue cycle vendor is not one relationship, it is a hub connecting thousands of provider organizations to one set of systems and one set of credentials.

That creates three multipliers a hospital does not control:

One compromise, many downstream organizations. An attacker who reaches the vendor reaches a slice of every customer relationship the vendor maintains, without attacking any of those customers directly.

Standing access in both directions. Vendors typically hold long-lived credentials into customer environments for data pulls, file drops, and support access. Customers hold long-lived credentials into the vendor. Neither side usually maintains a live inventory of the other's. This is the problem that identity-bound access is designed to remove, by replacing standing credentials with access tied to a verified identity and a bounded session.

Shared blast radius on evidence. If the record of what was exchanged lives in the vendor's platform, a vendor compromise degrades your ability to establish your own facts at exactly the moment you need them.

What data actually moves between a hospital and a revenue cycle vendor?

More than most security reviews assume. Typical flows include:

• Charge detail and claims files containing patient identifiers, service codes, and dates of service
• Remittance and denial files returned from payers
• Pharmacy dispensing and 340B eligibility data
• Contract and pricing files that reveal negotiated payer terms
• Support exports, which are often ad hoc, often large, and often outside the standard integration path

That last category is the one that goes unmapped. Scheduled integrations get documented during procurement. The file a revenue cycle analyst sends to a vendor support engineer at 4:00pm to troubleshoot a claims issue usually does not. Content inspection at the point of transfer is the practical control here, because it catches protected health information in exports nobody classified in advance. Our data loss prevention engine is built for that case.

Why is "we sent it securely" different from "we can prove what we sent"?

Encryption in transit answers a question nobody asks after an incident. Regulators, counsel, and your own board want scope: which files, to whom, containing what, authorized by which person, on what date.

Most organizations cannot answer that quickly for vendor exchanges, for structural reasons:

Secure File Transfer Protocol logs are thin. A Secure File Transfer Protocol server records filenames, timestamps, and internet protocol addresses. It does not record who authorized the transfer, whether the recipient identity was verified, or what business purpose the transfer served. We covered the compliance gaps this creates in HIPAA-compliant file transfer without SFTP, and the broader architectural differences in SFTP versus managed file transfer.

Email and portal exchanges fragment the record. When some files move by managed transfer, some by email attachment, and some through a vendor's own upload portal, there is no single place to reconstruct the sequence.

Evidence held by the counterparty is not independent evidence. If your only record of a vendor exchange is the vendor's record, then in a vendor breach investigation your evidence and the incident share a failure domain.

The practical effect is that scoping takes weeks and produces a range rather than a number. That range is what ends up driving the notification decision.

How long does it take to scope a vendor breach?

It depends almost entirely on whether you hold your own record. Organizations that can query a complete, independent log of external file exchanges answer the scope question in days. Organizations reconstructing from email archives, integration configurations, and vendor-supplied lists typically spend weeks, and finish with an estimate rather than a determination.

The difference is not effort or headcount. It is whether the evidence existed before the incident.

What can a health system verify on its own?

Three things, all inside your control regardless of what any vendor does.

An inventory of vendor data flows, including the unscheduled ones. Not the integration diagram from procurement. The actual list of what leaves your environment for each vendor, including support exports and one-off transfers, and which system produced each one.

A credential inventory in both directions. Which vendor accounts hold standing access to your systems, when each was last rotated, and how fast you can revoke each one. Then the reverse: which of your credentials sit in the vendor's environment right now. Onboarding vendors through approval workflows with time-bound access rather than issuing permanent accounts keeps this list short by construction.

An audit record you hold yourself. A log of every external file exchange, written to storage you control, that a third party can verify independently of the application that produced it. If that record is tamper-evident and stored outside the application's write path, it survives incidents on either side of the relationship. This is what audit and compliance evidence is for, and what SOC 2 examiners test when they ask whether an administrator can alter their own audit trail.

The third item is what turns an open-ended investigation into a bounded one. When you can produce a verified record of what you sent a vendor and when, your notification scope is determined by your evidence rather than by the vendor's disclosure timeline.

How does architecture change the blast radius?

Different file transfer architectures fail differently, and the differences show up in the questions above.

Credential lifetime determines the exposure window. Permanent Secure Shell keys and service account passwords provide access until someone discovers the compromise and rotates them manually. Short-lived, identity-bound credentials expire on their own, whether or not anyone has noticed anything. The investigation question shifts from what an attacker could reach over months to what they could reach inside the credential's lifetime. We walk through the mechanics in ephemeral credentials for healthcare data exchange and the migration path in replacing SFTP keys with short-lived certificates.

Where data rests determines who is in scope. A self-hosted deployment keeps files inside your environment rather than in a vendor's multi-tenant platform. That does not make your environment safer by itself, but it does mean a platform vendor's incident is not automatically your incident.

Where audit records rest determines whether you can prove anything. Audit logs stored in the same application database an administrator can reach are not tamper-evident. Records exported to write-once storage you control, with a cryptographic hash chain a third party can recompute, are. Our security architecture documents how that export works.

MnemoShare is built around those three properties: no permanent credentials, self-hosted deployment inside your own environment, and tamper-evident audit records exported to write-once storage that feeds your existing security information and event management system. We are not claiming any architecture would have changed the outcome at a specific vendor, and nobody outside those investigations is positioned to say so. What we are saying is that these properties determine how large your scoping problem is when a partner has a bad month.

Questions to bring to your next vendor review

For each vendor that touches patient or financial data:

1. What is the complete list of files we send you and you send us, including support exports?
2. What credentials do you hold into our environment, when were they last rotated, and how quickly can we revoke them?
3. If you were compromised today, what record would we hold of our exchanges with you that does not depend on your systems?
4. Can an administrator on your side modify or delete the audit records of their own actions? If not, what mechanism prevents it?
5. What is your notification commitment to us, in hours, and what triggers it?

Question three is the one most organizations cannot answer. It is also the cheapest to fix, because it does not require the vendor's cooperation.

Where to start

If you exchange sensitive files with outside partners and cannot currently produce an independent, tamper-evident record of those exchanges, start there rather than with a platform migration. Inventory the flows, identify which carry protected health information, and get an audit record you control for the highest-risk ones first. Expand from there.

For a walkthrough of how this applies to protected health information specifically, see HIPAA-compliant file sharing. To see how the audit export and credential model work against your own vendor list, request a demo.