How ConnectWise’s breach tested small practices’ business associate agreements

The week

On May 28, 2025, ConnectWise said it had detected suspicious activity in its environment linked to a sophisticated nation-state actor, meaning hackers working for or on behalf of a foreign government, typically well funded and patient. ConnectWise makes ScreenConnect, remote access software that is widely used by managed service providers and internal IT teams. Most small medical practices never think about the company that makes their IT provider’s tools. That week they had a reason to.

A word on each of those terms. Remote access software lets a technician see and control a computer from somewhere else, as if sitting at the keyboard. It is how your IT support fixes a problem on your laptop without visiting. A managed service provider, or MSP, is an outside firm that runs IT for organizations too small to have their own department: it installs software, applies updates, watches for problems and answers the help desk. To do that efficiently, an MSP installs small remote access programs, called agents, on every client machine, and manages them all from one central screen.

ConnectWise said the activity had affected a very small number of customers of its cloud-hosted ScreenConnect service, the version ConnectWise runs on its own servers rather than one a customer installs itself. It had engaged Google’s Mandiant unit for forensics, the detailed investigation of what attackers did. It notified affected customers and law enforcement, and strengthened monitoring. It published no detailed technical findings.

Security reporters linked the activity to a ScreenConnect vulnerability, a flaw in the software, that ConnectWise had patched in April. A patch is the software fix that closes such a flaw. The disclosure came about fifteen months after a critical ScreenConnect flaw was widely exploited in February 2024. It also arrived amid long-running federal warnings that attackers abuse legitimate remote monitoring and management tools, the very tools IT providers rely on, because they offer a ready-made, trusted way in.

For a doctor’s office, the uncomfortable point is this: a company it has never signed a contract with may hold a key to its patient records.

Most physician groups, ambulatory surgery centers and small specialty practices do not run their own IT. They hire a managed service provider, which reaches into their systems through remote access and monitoring tools. That makes the tooling vendor a supplier two contracts away. The practice signs with the provider, and the provider licenses the tools.

A practice cannot audit ConnectWise or any other tooling vendor. It can only set what the provider must do, through the master services agreement and the HIPAA business associate agreement that sits beside it. Those two documents need to settle four things, and most settle none of them well: which tools touch the practice, how access through them is controlled, what the provider must disclose, and who pays when something goes wrong.

How one console reaches every client

An IT provider works much like a building superintendent who looks after fifty apartment buildings across town. Rather than drive to each building every time a light bulb fails, the superintendent has a master key cabinet in a central office, with keys to every building, plus cameras and sensors that report problems. That is roughly what a remote monitoring and management tool, usually shortened to RMM, does for an IT provider.

Each client computer runs a small program, the agent, that reports its health back to the provider and accepts instructions: install this update, restart this service, let this technician take control of the screen. The provider runs a console, a single control panel where technicians see every client and every machine. Remote access software such as ScreenConnect is the part that lets a technician take over a screen to fix something live.

The console can be self-hosted, meaning the provider runs it on its own servers, or vendor-hosted (also called cloud-hosted), meaning the tool’s maker runs it and the provider logs in over the internet. The ConnectWise disclosure concerned customers of the cloud-hosted service.

The efficiency is real. One technician can look after hundreds of machines, which is why small practices can afford professional IT at all. But the master key cabinet is also the most valuable thing in town to a burglar. An attacker who controls a provider’s console, or the vendor’s cloud service behind it, can reach every client at once. And because the tools are legitimate and expected, their activity often looks normal to security software.

Most security tools are designed to spot software behaving like a burglar. Remote access software is designed to behave exactly like a trusted technician, because that is its job. When an attacker uses it, the activity can look like an ordinary support session, which is why federal agencies have spent years warning about this kind of abuse.

Which tools touch the practice

Many practices cannot name the remote access and monitoring tools on their machines. Providers often run more than one, switch tools over time, and leave old agents installed after a migration. Clinical device vendors add their own. Each agent is a path in.

The services agreement should require the provider to keep a current list of every remote tool it uses in the practice’s environment, including whether each is vendor-hosted or self-hosted. It should require notice before tools are added or changed, and removal of agents no longer in use.

Third-party agents should be on the list too: imaging, lab and EHR vendors often maintain their own remote access. The EHR, or electronic health record, is the system that holds patient charts, and its vendor may need to connect in for support. Those connections are just as real a path in as the provider’s own.

This is a short clause with a large effect. When a tooling vendor announces an incident, the practice can tell within an hour whether it is exposed.

The list has a second use. Cyber insurers increasingly ask applicants which remote access tools are in use and how they are secured. A practice that cannot answer accurately risks a misstatement on its application, which can complicate a later claim. The provider’s tool list, kept current under contract, is the evidence behind that answer.

One office manager’s Wednesday morning

Take a six-physician dermatology group. Its office manager reads about a remote access vendor’s incident on a Wednesday morning. Without a tool list, she emails the IT provider and waits two days for a vague reply. With a tool list attached to the contract, she opens it, sees that the named product is not among the four tools installed, and confirms by noon that the group is not exposed. Or she sees that it is, and asks the provider, under the contract, what it is doing that afternoon. Either way she spends her time acting rather than wondering.

How access is controlled

Remote tools are only as safe as the accounts that use them. The agreement should require several basic protections, each of which is easier to understand than it sounds:

• Phishing-resistant multifactor authentication for every technician. Multifactor authentication, or MFA, is a second check after the password, such as a code or a tap on a phone. “Phishing-resistant” versions, such as physical security keys, cannot be tricked out of someone by a fake login page.
• Named accounts rather than shared logins. Every technician logs in as themselves, so actions can be traced to a person.
• Separation between clients. One client’s compromise should not open another; the master key cabinet should have separately locked drawers.
• Session recording or logging the practice can obtain on request. A record of who connected, when and what they did.

Where the console is hosted by the tooling vendor, the provider should explain how that console is protected and patched.

These protections are not exotic. It mirrors federal guidance on remote monitoring and management tools that CISA, the federal Cybersecurity and Infrastructure Security Agency, and its partners have published since 2023. The difference is enforceability. A practice with these terms in writing can ask for evidence, such as an access review or a log sample, instead of accepting assurances. Asking once a year, at renewal, costs little and signals that the practice reads the reports it receives.

What the provider must disclose

Under HIPAA, the federal health privacy law, a covered entity is a healthcare provider, health plan or clearinghouse. A business associate is an outside company that handles patient information on the covered entity’s behalf. Electronic protected health information is the legal term for patient data held digitally.

A managed service provider with access to electronic protected health information is generally a business associate under HIPAA. It must sign a business associate agreement and report security incidents and breaches of unsecured protected health information to the practice. Whether a tooling vendor is a subcontractor business associate depends on its role, and practices should check that with counsel.

The gap is timing and scope. HIPAA allows up to 60 days after discovery to notify a covered entity of a breach, and many template agreements narrow incident reporting to confirmed breaches. A suspicious-activity notice from a tooling vendor may meet neither trigger, yet it is exactly when the practice needs to act: rotate credentials (change passwords and access keys), review sessions, check for new accounts an intruder might have created.

Sixty days is a long time when someone may be holding a copy of your keys. The agreement should require the provider to tell the practice within a short, fixed period of any security incident at the provider or at a vendor whose tools touch the practice. It should require sharing what the provider knows and cooperation with the practice’s own investigation and insurer.

Who pays

Managed service contracts for small healthcare organizations commonly cap the provider’s liability at a few months of fees and exclude consequential damages, the knock-on losses such as lost revenue that follow from a failure. That may suit routine service failures, like a printer that stays broken for a day. For an incident that starts in the provider’s tools, it leaves the practice holding nearly all of the cost: forensics, notification, downtime, lost visits and regulatory response.

Small practices have limited bargaining power, but they have options:

• Ask what cyber insurance the provider carries and whether clients benefit from it.
• Negotiate a higher cap that applies only to security incidents caused by the provider’s tools or negligence.
• Make notice and cooperation duties survive termination, so a provider that is fired or goes out of business still has to help.
• Confirm that the practice’s own cyber policy covers incidents originating at a service provider, because some policies treat these differently.

Counsel and the insurance broker belong in this conversation. A short meeting before renewal is far cheaper than discovering the gap after an incident.

What the first 48 hours should look like

Contract terms are only useful if they translate into action on the day. Consider how a well-prepared practice responds when a tooling vendor announces suspicious activity, compared with one that is not prepared.

Return to the dermatology group. On the morning the news breaks, the office manager checks the tool list and confirms that the affected product is installed. Because the contract requires prompt notice and cooperation, the IT provider calls her that same day rather than waiting to see whether a breach is confirmed. Together they work through a short, pre-agreed checklist:

1. Change the keys. The provider resets the passwords and access credentials its technicians use to reach the group’s machines, and any shared accounts the practice still has.
2. Look at who came in. The provider pulls the session logs for the past several weeks and checks that every connection matches a real support ticket.
3. Look for anything new. The provider checks for new user accounts, new remote tools or new scheduled tasks that nobody requested, which are common signs that an intruder has set up a way back in.
4. Bring in the advisers. The office manager calls the practice’s insurance broker to report a potential incident, because many policies expect prompt notice, and asks counsel whether anything triggers HIPAA obligations yet.
5. Write it down. Every step, finding and decision goes into a short incident note, which becomes the practice’s evidence of a reasonable response.

In most cases a review like this ends with nothing found, and the practice has spent a day of mild inconvenience. That is a good outcome, and it is cheap.

Now take a practice without these terms. The office manager hears about the incident from a colleague at another clinic. She emails the provider, which replies that it is “monitoring the situation.” Nobody resets credentials, because the provider is not obliged to and is busy with larger clients. No one pulls logs, because the practice never asked whether logs existed. Two weeks later, if something does surface, the practice has no record of what it did, and its insurer asks why it waited.

The difference between those two stories comes down to a handful of sentences in a contract, and a habit of using them.

More than a commodity purchase

It is easy to see the IT contract as a commodity purchase chosen mostly on monthly price. The ConnectWise episode shows why that view is incomplete.

Risk is concentrated. A practice may have excellent habits of its own and still be exposed through a supplier it has never met. Its security is only as good as the weakest link in a chain it does not fully see.

Regulators look at the covered entity. Under HIPAA, the practice remains responsible for protecting its patients’ information, even when a vendor caused the problem. Showing that it set clear expectations in writing and checked them is a meaningful part of a credible response.

Patients and staff feel the downtime. When remote tools are compromised, the usual response is to disconnect them, which can leave the practice without IT support at the moment it needs it most. Schedules, billing and clinical work all slow down.

Insurance depends on accuracy. As noted above, an inaccurate answer about remote tools on an insurance application can complicate a claim. The contract and the tool list are what make the answer accurate.

One page that carries all four terms

Applying these four terms does not require a new negotiation every year. A one-page security schedule, attached to the services agreement and referenced in the business associate agreement, can carry all of them. It can be reused at every renewal and across every practice in a group. For a physician group that owns several clinics, one schedule applied everywhere creates consistency and saves legal fees.

The aim is a practice that can answer, quickly and in writing, which remote tools touch its machines, who can use them, how quickly it will hear about trouble and who pays if trouble starts there.

The usual gaps are these:

• Relying on the template. Accepting the provider’s standard business associate agreement without checking its reporting triggers and timing.
• Forgetting third-party vendors. Listing the provider’s tools but not the imaging, lab or EHR vendors’ own connections.
• Never asking for evidence. Having the right clauses but never requesting an access review or a log sample.
• Ignoring old agents. Switching providers or tools and leaving the old software installed.
• Assuming insurance covers it. Not confirming how the practice’s own policy treats incidents that begin at a service provider.

What to ask the IT provider before renewal

• Can you give us a written list of every remote access and monitoring tool on our machines, including those used by our imaging, lab and EHR vendors, showing which are hosted by the vendor and which old agents are still installed?
• Does every technician use their own account with phishing-resistant MFA, and if one of your other clients were compromised, what stops the attacker reaching us?
• Can we see a log of who connected to our systems last month?
• How quickly will you tell us about a suspected incident at your firm or at one of your tool vendors, and is that in our contract?
• What is your liability cap for security incidents and what cyber insurance do you carry, and does our own cyber policy cover an incident that begins at our IT provider?

With hindsight

ConnectWise never published a full account of the intrusion. Practices and providers were left to act on limited information, which is common and is exactly why contract terms about notice and cooperation matter: they determine how much a practice learns, and how fast, when the vendor itself says little.

In June 2025 ConnectWise rotated the code-signing certificates for ScreenConnect, Automate and its RMM agents. A code-signing certificate is a digital seal that tells a computer a piece of software genuinely comes from its maker and has not been tampered with; rotating it means issuing a new seal and retiring the old one. ConnectWise cited concerns a third-party researcher had raised about how older ScreenConnect versions handled configuration data. It said that issue did not involve a compromise of its systems or certificates. Customers running self-hosted versions had to update before the cutoff, a reminder that providers need to know which versions they run and act on deadlines.

Federal advisories through 2025 and 2026 continued to describe attackers using legitimate remote access tools. The pattern has not gone away, because the tools are useful, trusted and everywhere.

On the regulatory side, the HIPAA Security Rule overhaul that HHS proposed in January 2025 would require covered entities to obtain written verification, at least annually, that business associates have deployed required technical safeguards. As of late 2026 it had not been finalized, and federal planning documents projected final action in 2027.

Practices that wrote verification and notice terms into their agreements in 2025 have, in effect, already adopted much of that proposal. That is the useful reading of this week: good contract hygiene protects against the next vendor incident and also prepares a practice for where regulation appears to be heading. A one-page schedule written now is likely to save a scramble later.