Kaseya and the most privileged system nobody on site runs

The week

Holiday weekends are when offices empty out, on-call rotations thin and nobody expects bad news. On Friday, July 2, 2021, the start of the US Independence Day weekend, the REvil ransomware group made use of exactly that.

Ransomware is malicious software that scrambles, or encrypts, an organization’s files so they cannot be opened, after which the attackers demand payment for the key to unscramble them. REvil was one of the best-known criminal groups running it.

This time, REvil did not break into its victims one at a time. It exploited a previously unknown vulnerability, a security flaw the maker had not yet fixed, in on-premises installations of Kaseya VSA. VSA is a remote monitoring and management tool widely used by managed service providers, or MSPs. An MSP is an outside company that runs IT for other organizations, typically small and mid-sized businesses, schools and local governments that cannot justify a full IT department. Tools like VSA let one MSP technician look after hundreds of computers across many clients from a single screen: installing updates, running scripts and fixing problems remotely. “On-premises” means the MSP ran the VSA server itself rather than using Kaseya’s cloud-hosted version.

The attackers used VSA’s own software deployment function to push ransomware to computers those providers managed. To each victim machine, the ransomware looked like a routine update from its trusted IT provider.

The attack landed in a tense season. In May, a ransomware attack on Colonial Pipeline had led the company to shut down fuel deliveries across much of the US East Coast. In early June, the FBI attributed an attack on the meat processor JBS to REvil, and JBS said it had paid the equivalent of $11 million. Ransomware had been on the agenda when President Biden met President Putin in Geneva on June 16. Six months earlier, the SolarWinds compromise had shown how a trusted software update could carry attackers into thousands of networks.

A race the defenders nearly won

The Dutch Institute for Vulnerability Disclosure, or DIVD, a volunteer group of security researchers, had been studying VSA since the start of April 2021. According to its published timeline, it informed Kaseya of a set of vulnerabilities on April 6. Kaseya released patches for some of them in April and May. On June 26 it fixed two more, including a credentials leak and business logic flaw, in its cloud-hosted service. The fix for on-premises servers was still in progress when the attack began. The attackers got there first.

The first days

Kaseya told customers to shut down on-premises VSA servers at once and took its cloud service offline as a precaution. DIVD scanned the internet for exposed VSA servers that day and notified their owners. On July 3, the Cybersecurity and Infrastructure Security Agency (CISA) posted an initial advisory. On July 4, CISA and the FBI issued joint guidance for MSPs and their customers. On July 5, the White House said the federal government would investigate.

Kaseya later said fewer than 60 of its direct customers, many of them MSPs, were compromised, all of them running on-premises VSA. It estimated that fewer than 1,500 downstream organizations were affected and said it had found no evidence that its cloud customers were compromised. It released a tool customers could run to check their servers for signs of compromise. REvil demanded $70 million for a universal decryptor, a single key that would unlock every victim’s files at once.

The effects reached well outside IT. In Sweden, the Coop grocery chain closed most of its roughly 800 stores for days after its cash registers and self-service checkouts stopped working. One of its software suppliers, Visma EssCom, confirmed it had been affected by the Kaseya incident. Bloomberg reported early on that more than 1,000 organizations in 11 countries had been hit.

Opportunists followed within the week. Security researchers reported phishing emails disguised as Kaseya security updates that installed attack tools instead. Kaseya said it planned to restore its cloud service and release the on-premises fix on July 11, and it published runbooks telling customers to keep on-premises servers isolated until then. For the MSPs and their clients, the holiday weekend turned into a recovery that ran well into the following weeks.

Most of the organizations hit through Kaseya had never heard of VSA. They were dental practices, accounting firms, schools, municipalities and small manufacturers that paid a provider to run their IT precisely so they would not need to understand its tools.

That arrangement moves work. It does not move accountability. A client’s data, operations and regulatory duties stay with the client, while the most powerful software in its environment is chosen, configured and patched by someone else. Hiring an MSP is a little like giving a property management company the master keys to every apartment in your building. It is sensible, often necessary, and it means the security of your building now depends on how carefully that company guards its key cabinet.

The attack exposed three gaps in that arrangement, which we take in order: privilege, what the provider’s tooling can do inside the client; concentration, how one tool’s failure spreads across many clients at once; and contract, what the agreement says about either.

First comes a short explanation of the technology. After the three gaps, we look at the costs that fall outside the IT budget, at how the gaps compound, and at the practical steps and test questions that follow.

What a remote management tool can do

A remote monitoring and management platform, often shortened to RMM, is the toolkit an IT provider uses to look after computers it cannot physically touch. It has two parts.

The first is the agent: a small program installed on every managed laptop, desktop and server. It runs in the background, reports on the machine’s health, and waits for instructions.

The second is the console: the central control panel the provider’s technicians use. From the console, a technician can see every managed machine across every client, push out software updates, run scripts that change settings, and fix problems without leaving their desk. In VSA’s case, as in many such products, a provider could run the console on its own server (on-premises) or use the vendor’s cloud-hosted version.

For small organizations, this is genuinely valuable. It means security updates get installed, backups get checked and broken laptops get repaired, at a cost they can afford. The same features that make it valuable make it dangerous in the wrong hands. A tool designed to install software on every machine at once will install ransomware on every machine at once, if someone else is giving the instructions.

The flaw REvil used was what security teams call a zero-day: a vulnerability that is being exploited before a fix is available, so defenders have had zero days to patch it. In this case the flaw had been reported and a fix was in progress, but it was not yet in customers’ hands.

The attack chain, in outline

Public analyses describe a short chain. The attackers exploited flaws in internet-facing, on-premises VSA servers, among those DIVD had reported, to get past authentication. They then used the server to schedule a task that looked like a routine VSA procedure. Agents on managed machines collected the task and ran it. Security firms that analyzed the attack published detections for files dropped into the agent’s working folder and for misuse of Windows’ built-in certificate utility to decode the payload. Encryption followed on each machine.

No phishing email or stolen password was needed on the victims’ side. Every step after the server compromise used features the product was designed to provide.

How the agent and the console talk

An RMM agent typically checks in with its console on a schedule and asks whether there is work for it. When a technician schedules a task, such as a patch, a script or a software install, the agent collects it at the next check-in and runs it with system rights. That design lets the console reach machines behind firewalls and on home networks without opening inbound connections to each one. It also means the console is the single point that decides what every agent runs.

To keep routine tasks from being blocked, many deployments exclude the agent and its working folders from antivirus scanning. The Kaseya attack staged its payload in VSA’s working folder and ran it through the agent, so those exclusions worked in the attacker’s favor. Security teams that published detections afterward looked for exactly that behavior: unexpected executables appearing in the agent’s working folder.

Self-hosted or vendor-hosted

MSPs chose on-premises VSA for reasons that made sense. It gave them control over data location, integration and upgrade timing, and some had used the product for years before a cloud version existed. The trade-off is that a self-hosted console is only as current as its operator’s patching. Kaseya fixed its cloud service on June 26. The on-premises servers waited for a release that had not shipped by July 2.

Hosting also decides who can see the console from the internet. A self-hosted console exposed to the internet, so technicians can reach it from anywhere, is a target for anyone scanning for that product. DIVD’s scans before and during the attack were looking for exactly those servers. The cloud version carries a different risk: a flaw in the vendor’s own service reaches every customer on it, which is why Kaseya took it offline as a precaution.

Privilege: the agent that outranks your administrators

In IT, privilege means how much a given account or program is allowed to do. An ordinary employee’s account can open their own files. An administrator account can install software, change security settings and read almost anything. The more privilege, the more damage if it is misused.

An RMM agent usually runs with full system rights and takes instructions from a central console that can push software, run scripts and change settings across every device. That is the product working as designed. It also means the console holds more effective authority over a client’s estate than any administrator account the client itself controls.

Few clients treated it that way. A bank or health system that runs its own IT will typically require multi-factor authentication for domain administrators, log their actions and review them. Multi-factor authentication means a password alone is not enough: the user must also confirm a code from a phone or a hardware key, so a stolen password by itself does not open the door. The same organization may let a provider reach every endpoint through a console it has never seen, with security controls it has never asked about.

In the Kaseya case the attackers did not need anyone’s password. They exploited the on-premises VSA server itself and then used the trusted deployment channel, so the ransomware arrived as an ordinary management task. Endpoint tools that trusted the agent did not stop it. Endpoint tools are the security programs, such as antivirus, that run on each computer. They are often configured to trust the management agent, because blocking it would stop legitimate IT work. In this attack that trust became the delivery route.

Closing the gap starts with an inventory question that most third-party risk programs did not ask in 2021: which external tools hold privileged, persistent access to our systems? The answer usually includes:

• the MSP’s monitoring platform;
• remote support tools used to take over a screen for help-desk calls;
• backup agents;
• endpoint security consoles run by a provider;
• vendor support accounts.

Each belongs on the same list as the client’s own privileged accounts, with the same expectations. Those are strong authentication to the console, restricted network exposure, a record of what it executes, and a client-side owner who reviews that record. “Restricted network exposure” simply means the console should not be reachable from anywhere on the internet by anyone who finds it.

Controls that fit a third party

Privileged access management, the discipline banks and health systems apply to their own administrators, has equivalents for a provider. Credentials for the console and for any accounts it uses can be held in a vault rather than shared. Access to the most sensitive systems can be granted for a set period on request, rather than standing open. High-risk actions, such as pushing a script to every machine, can require a second approver. Sessions can be logged and the logs sent to the client.

Each control has a cost the provider will notice. Approval steps slow down urgent fixes, and per-client vaults add work for a provider serving hundreds of clients. The useful question for a client is which of these controls the provider already uses, and which it would add for a fee. The answer belongs in the contract, which we come to below.

Least privilege inside the console

The console itself has settings that limit damage. Technician roles can be scoped so that one person can reach only certain clients. The library of scripts that can be pushed can be restricted and reviewed. Modules the provider does not use can be turned off. Some products allow a client environment to require approval before a new script runs there. These settings would not have stopped an attacker who controlled the server outright, but they narrow what a stolen technician account can do, which is the more common attack.

The client has levers on its own side too. Its endpoint detection tools can watch what the agent launches rather than trusting it blindly. Alerts on an agent starting unusual programs, or on many machines changing at once, give early warning. An exception that trusts the agent should be a recorded decision with an owner, not a default left from installation.

Different organizations, different starting points

The exposure looks different by type of organization. A small medical practice or a town office may outsource all of its IT, so the MSP’s console is effectively its only administrator. A health system or regional bank usually runs its own IT but still grants vendors standing access for support, backup or monitoring. The second group already has privileged access controls; it often has not applied them to vendors. Agencies that handle criminal justice information face CJIS Security Policy requirements on access and authentication that extend to contractors with access, which makes the console a compliance question as well as a security one.

Banks and credit unions bring their own frame. Supervisory third-party guidance expects due diligence, contract provisions and ongoing monitoring in proportion to a relationship’s risk. Risk here depends on access, not spend. An MSP whose console reaches every branch workstation is a high-risk relationship even if its invoice is small, and examiners can be expected to look at it that way. Health care clients need the business associate relationship to reflect the same reality.

Concentration: one console, many clients, one weekend

The second gap is structural. A handful of management products serve a large share of MSPs, and each MSP serves dozens or hundreds of clients. A flaw in one product therefore travels through a few intermediaries to a very large number of organizations simultaneously.

Kaseya’s own estimate, a few dozen direct customers and up to roughly 1,500 downstream organizations, shows the multiplier. One software vendor sits above a few dozen MSPs, which sit above many hundreds of clients, and an attacker who compromises the vendor reaches the clients without ever having to find them.

This pattern is often called a supply chain attack: rather than attacking a target directly, the attacker compromises something the target trusts and receives from a supplier. It is efficient for criminals for the same reason outsourcing is efficient for clients. One relationship serves many.

Concentration also changes the recovery. A provider with one compromised client can send its best engineers. A provider with forty compromised clients on a holiday weekend has to triage, and some clients will wait. REvil chose its timing with that in mind. Clients that assumed their provider would respond as if they were its only customer found out otherwise.

Precedents that were already visible

The pattern was not new in July 2021. Six months earlier, the SolarWinds compromise had shown how a trusted software update could carry an attacker into thousands of networks. Attacks through MSPs and their tools had also been reported before Kaseya, on a smaller scale. What Kaseya added was speed and breadth: one flaw, exploited on one afternoon, reaching organizations in many countries through dozens of providers at once.

An individual client cannot remove this concentration, but it can see it and plan for it. The useful questions for a provider are concrete. The first is whether the management platform is self-hosted or vendor-hosted, and who patches it. The second is whether the client is managed from a console shared with other clients or a separate one. The third is how the provider would rank clients for response if the platform were compromised, and where this client sits.

Providers that segment their management infrastructure, separating clients or groups of clients so one breach cannot reach all of them, reduce the blast radius for everyone. A client that cannot get answers to these questions has learned something about its provider.

Seeing the fourth parties

A client’s provider has its own providers. The RMM vendor, the remote access tool, the backup service and the ticketing system are all suppliers to the MSP and, through it, part of the client’s exposure. Risk teams call these fourth parties. In the Kaseya case, most victims had a contract with an MSP and none with Kaseya.

A client cannot review every fourth party, and should not try. It can ask its provider for a list of the tools that reach client systems, and for notice when that list changes. That list tells the client which vendor advisories to watch. When a flaw in a major RMM or remote access product is announced, the client then knows within minutes whether it is exposed, rather than waiting for its provider to call.

Concentration in recovery resources

The multiplier also applies to recovery. Incident response firms, backup restoration capacity and the provider’s own staff are finite. When many organizations are hit at once, they compete for the same people. A client with a pre-arranged incident response retainer, independent of its MSP, does not depend entirely on its provider’s triage. A client whose only responder is the compromised provider does.

A counter-argument deserves a fair hearing here. For most small organizations, an MSP using a mainstream RMM tool is far safer than the alternative, which is often no dedicated IT staff at all. Concentration risk is the price of economies of scale that bring patching and monitoring within reach. The point holds, and it argues for managing the concentration rather than abandoning outsourcing. The steps above cost little compared with building an in-house IT function.

Contract: what the agreement does not say

The third gap lies in the paperwork. Many managed services agreements in 2021 described uptime, ticket response times and pricing in detail and said almost nothing about the security of the provider’s own tools. Typical omissions included:

• any duty to notify the client when the provider itself is compromised;
• any right to see the provider’s security assessments;
• any allocation of recovery costs;
• any statement of which party decides to disconnect a management agent in an emergency.

Clients often assumed the provider was responsible for security in general. The agreements rarely said so.

For regulated clients, this is a compliance gap as well as a commercial one. Banks and credit unions are expected to manage the risk of technology service providers under supervisory third-party guidance. Health care organizations whose provider can reach systems holding protected health information generally need a business associate agreement, the contract HIPAA requires when an outside party handles patient information on a provider’s behalf. The provider’s management platform is part of how that information could be exposed. Agencies whose systems hold criminal justice information must extend CJIS Security Policy requirements, the FBI’s security rules for that data, to contractors with access. In each case the provider’s tooling is in scope, and the contract should say so in terms an auditor can test. Organizations should check with counsel on the specific obligations that apply.

Useful clauses are specific:

• notice of a provider-side security incident within a defined number of hours;
• an annual independent assessment of the provider’s management environment;
• multi-factor authentication and logging on any console that reaches the client;
• client rights to the console’s activity logs for its own environment;
• named contacts reachable on weekends and holidays;
• a stated right for the client to disconnect agents without penalty.

No clause prevents a zero-day, but together they decide whether the client hears about a compromise from its provider within hours or from its own staff on Tuesday morning.

Who decides to pull the plug

One clause deserves its own discussion. In an emergency, someone must decide whether to disconnect the provider’s agents, block the console at the firewall or shut down machines. Disconnecting stops an attack in progress. It also stops patching, remote support and monitoring, so the client needs a manual fallback for the days that follow.

The contract should name who can make that call on each side and confirm the client’s right to make it alone. The client’s own runbook should describe how: which firewall rule blocks the console, who holds the credentials to change it, and how the client will reach its provider if normal channels are down. A decision that takes an hour to authorize on a holiday weekend is a decision made too late.

Evidence a small provider can give

An independent assessment, such as a SOC 2 report, is the usual way providers show their controls. Many small MSPs do not have one, and the cost can be out of reach for a provider with a handful of staff. A client can still ask for specific evidence. Examples include a screenshot of the console’s MFA settings, the current version and patch date of the RMM platform, and a description of how client environments are separated. A copy of the provider’s own incident response plan is also reasonable to request. A provider willing to share that much is easier to trust than one that offers a general assurance.

Exit and offboarding

Contracts also need to cover the end of the relationship. When a client changes providers, the old provider’s agents and accounts often remain on the client’s machines. The 2022 Five Eyes guidance specifically warned that disabling a provider’s accounts at contract end is often overlooked. A clause requiring removal of agents and accounts, with written confirmation, closes a door that otherwise stays open indefinitely.

Costs that never reach the IT budget

Coop, the Swedish grocery chain, closed most of its stores for days. Its problem was revenue, perishable stock, staff with nothing to do and customers who went elsewhere. Those costs show up nowhere on the IT budget.

For a regulated organization the list is longer. A bank whose branch computers are encrypted cannot serve customers and may have to explain to its examiners how a third party’s tool came to have that reach. A medical practice that loses access to patient records faces both care disruption and questions about whether protected health information was exposed. A local government whose systems are locked may be unable to issue permits, process payments or answer residents, and will have to account for the episode in public.

Then there is the ransom itself. A demand like REvil’s puts leadership in front of a decision with legal, ethical and practical dimensions, usually under severe time pressure and often without the information needed to make it well. Organizations that have decided in advance who makes that call, who advises them and how they will communicate are in a far better position than those improvising on a holiday weekend.

Paying also carries legal risk of its own. The Treasury Department’s Office of Foreign Assets Control has issued advisories warning that paying a ransom to a sanctioned person or group can violate US sanctions. It encourages victims to report attacks to law enforcement. Insurers, counsel and incident responders all have a role in that decision, and each should be identified before it is needed.

Measuring exposure in business terms

The cost of an RMM compromise depends on what the managed machines do. For a grocery chain, they may be the checkouts, as Coop found. For a clinic, they may be the workstations staff use to reach the electronic health record. For a county, they may run permitting, payments or emergency dispatch support. A business impact analysis that lists which processes depend on provider-managed machines, and how long each can be down, turns a technical risk into a number executives can weigh.

That analysis also guides spending. A process that cannot be down for more than a day justifies a separate recovery path, such as spare devices that are not managed by the same console or a documented manual procedure. A process that can wait a week may not.

Notification duties do not move to the provider

Regulatory clocks start with the client. Under HHS guidance on ransomware, an encryption of electronic protected health information is generally presumed to be a HIPAA breach unless the covered entity can show a low probability that the information was compromised. State breach notification laws apply to many organizations regardless of who ran the compromised tool. A client that learns of a compromise late from its provider has less time to make those assessments. Organizations should confirm with counsel which duties apply to them.

Reputation follows the same pattern. Customers and residents rarely distinguish between an organization and the provider it hired. To them, the dental office, the town hall or the credit union failed. That is the practical meaning of “outsourcing the work but keeping the risk”: the organization absorbs the cost, the scrutiny and the blame, whether or not it ever saw the console that was compromised.

The decisions that matter, such as which provider to hire, what the contract requires and how much to invest in recovery, are business decisions. Executives and boards should oversee them alongside the IT manager.

How the three gaps play out together

The three gaps compound. Privilege makes a compromise severe, concentration makes it simultaneous, and a thin contract makes the response slow and disputed. A client that addresses only one of them still carries the other two.

Suppose a county’s clerk’s office, library and public works department all use the same local MSP. On a holiday Friday, the MSP’s management server is compromised through a flaw in its RMM software. Within an hour, the ransomware reaches every county laptop the agent is installed on, because the agent was built for exactly that. That is privilege.

The MSP has thirty other clients hit at the same moment, a skeleton holiday crew and no pre-agreed order of response. The county, a modest account, is near the back of the line: concentration at work.

When the county’s IT coordinator finally reaches the MSP, there is no agreement on who pays for recovery. There is no right to the logs that would show what was touched, and confusion over whether the county may disconnect the agents itself. Its insurer and its legal counsel want answers it cannot get, which is where the thin contract hurts most.

Now run the same scenario for a county that had acted on each gap. Its inventory flagged the RMM console as privileged access, and it had asked the MSP for multi-factor authentication and restricted access to the console. Its MSP ran clients in separate segments, so not every client fell at once, and the county knew where it stood in the response order. Its contract required notice within hours, gave it the logs and confirmed its right to disconnect. It might still have suffered an incident. It would have known sooner, recovered faster and argued less.

The scenario also shows why partial fixes disappoint. A county that negotiated a strong contract but left the console exposed would still have been encrypted. One that insisted on MFA and segmentation but had no notification clause might have escaped this attack and been blindsided by the next. Each gap needs its own control, and the controls only add up when all three are in place.

Treating the provider’s tools as your own

An organization does not have to become an IT shop to close these gaps. It has to treat the provider’s tools as part of its own security, because in practice they are.

• See it. Keep a current list of every outside tool with privileged, standing access, alongside internal administrator accounts.
• Ask about it. Know whether the provider’s console is self-hosted or cloud-hosted, shared or separate, and who patches it.
• Write it down. Put notification, logging, authentication and disconnection rights into the contract.
• Rehearse it. Include “our IT provider is compromised” as a scenario in incident exercises, including on a holiday.
• Back it up separately. Make sure at least one copy of critical backups cannot be reached or deleted through the same management channel that might be compromised.

The case for putting it on the vendor

A serious counter-argument holds that clients should not carry this burden at all. The flaw was in Kaseya’s software, and small clients have no realistic way to judge the security of a product they never chose. That view gained ground after 2021. The US National Cybersecurity Strategy of March 2023 argued for shifting more responsibility for insecure software to the companies that make it.

The argument is right about where the problem starts, and it does not change what a client should do this year. Liability rules move slowly, and they compensate after the fact. The steps here reduce how much damage a client suffers while the broader debate continues. They also give a client the records it would need to pursue any claim against a provider or vendor.

Measures a board can follow

A few measures show whether the work is done and stays done. They include the number of outside tools with privileged, standing access and the share confirmed to use MFA on their consoles. Another is the date of the most recent evidence received from each provider. A further one is how quickly each provider applies vendor security fixes to its own platform. The last is the date of the most recent exercise that included a provider compromise. Each can be reported in a single line.

Where to start, by size

A small organization with one MSP can cover most of this in a single meeting and a contract amendment. It can ask for the inventory, the console’s hosting and MFA status, the notification and logging terms and a separate backup copy. A larger organization with several providers needs a standing process. That means adding provider tools to the privileged access inventory, adding provider questions to third-party risk reviews, and testing the scenario in exercises at least once a year.

Sequencing matters. Separate backups and console MFA reduce harm soonest, so they come first. Contract changes usually wait for renewal, unless the provider agrees to an amendment. Exercises come last, because they test the other steps.

The usual errors include assuming that outsourcing IT outsources the risk, and reviewing a provider’s financial health but not its security. Others are accepting a standard contract without security terms because the provider is small or local, and letting endpoint security tools trust the management agent without anyone deciding that deliberately.

Testing the provider relationship

1. Which outside companies have software installed on our computers that can run commands or install programs, and do we have a complete list?
2. If our provider were hit along with many of its clients, where would we be in the response queue, and how do we know?
3. Does our contract require the provider to tell us within hours if it is compromised, and give us the logs for our environment?
4. Who on our side can decide to disconnect the provider’s agents in an emergency, and are we contractually allowed to?
5. Could an attacker who controlled the provider’s console also delete our backups?

The holiday version of the exercise is the most revealing. Run it as if the alert arrives on the Friday afternoon before a long weekend. Note who on the client side is reachable, who at the provider answers, and how long it takes to reach a decision on disconnecting. Most organizations find the gaps in contact lists and authority, not in technology.

With hindsight

Kaseya obtained a universal decryptor later in July 2021 and distributed it to affected customers, and REvil’s infrastructure went offline that month. A Ukrainian national charged over the attack was arrested in Poland in October 2021, extradited to the United States and sentenced in 2024. REvil’s sites reappeared in September 2021 and went dark again the following month, and in January 2022 Russia’s FSB security service announced the arrest of members of the group. The immediate story resolved faster than many expected. For the victims, the decryptor shortened recovery, but it did not undo the days of disruption that had already happened.

Kaseya remains the reference case for attacks that travel through IT service providers. It showed, more clearly than any earlier incident, how a single weakness in a widely used management tool can reach hundreds of organizations that never chose that tool themselves.

The policy response focused on the structural issue. In May 2022, cybersecurity agencies of the Five Eyes countries issued joint guidance on protecting MSPs and their customers. Much of it addressed the privilege and segmentation issues above. It called for multi-factor authentication on all MSP accounts that reach customer environments and for keeping important logs for at least six months. It also asked MSPs not to reuse administrator credentials across customers and to disable their accounts when contracts end. It said contracts should define which party owns each security responsibility. It also urged both MSPs and customers to keep backups stored separately and isolated from network connections, the last line of defense when the management channel itself is turned against them. That guidance addressed both sides of the relationship, a recognition that clients cannot simply hand the problem to their providers.

Attackers did not move on. In January 2023, CISA, the NSA and the Multi-State Information Sharing and Analysis Center warned that criminals were using legitimate remote management software to get into victims’ systems. They often used portable versions that need no administrator rights. In February 2024, ConnectWise disclosed a critical authentication bypass in its ScreenConnect remote access product. Its cloud-hosted instances were fixed by the vendor, while on-premises servers needed to be patched by their operators. CISA added the flaw to its catalog of known exploited vulnerabilities within days. The split between hosted and self-hosted instances echoed Kaseya almost exactly.

US financial regulators moved toward the provider relationship as well. The federal banking agencies finalized a computer-security incident notification rule in November 2021. It required bank service providers to notify their bank customers as soon as possible when an incident disrupts covered services for four or more hours. The same agencies issued joint guidance on third-party risk management in June 2023. The NCUA required federally insured credit unions to report cyber incidents within 72 hours from September 2023, including some incidents at third parties. The SEC’s 2024 amendments to Regulation S-P required broker-dealers, investment advisers and other covered firms to oversee service providers, including their notice of breaches.

The EU went further. Its Digital Operational Resilience Act, applied from January 2025, brought ICT service providers squarely into financial entities’ contractual and oversight duties. For financial institutions in scope, governing a provider’s technology is now an explicit obligation rather than a matter of good practice.

What held up is the central finding: a provider’s management console is part of the client’s attack surface, the set of doors an attacker might use, and has to be governed as such. What has changed is how much of that governance is now written into rules for regulated clients. The small businesses, schools and towns that made up most of Kaseya’s victims mostly fall outside those rules, and their exposure depends on their own contracts. Leaders who outsource IT should expect to know what that console can do, who protects it and what happens if it falls.