How would you know if someone other than your IT provider had remote control of your computers right now? For most business owners the honest answer is that they would not, and that gap is exactly what attackers exploited in 2025. RMM tool abuse, where criminals use the same remote monitoring and management software IT teams rely on, rose 277% year over year in the Huntress 2026 Cyber Threat Report, and it showed up in nearly a quarter of the incidents Huntress investigated.
The short answer for SMB leaders: RMM tool abuse is not mainly a story about your provider's platform being hacked. It is about attackers installing or logging into a second, unapproved remote tool that your security stack treats as normal IT activity. The fix is governance your provider can prove: an approved-tool list, blocking of everything else, and alerts on any new remote access software.
RMM tool abuse is growing because it is cheaper and quieter than malware. Huntress reported in its announcement of the 2026 report that, alongside the 277% rise in RMM abuse, use of traditional hacking tools fell 53% and remote access trojans fell 20%. Attackers did not stop wanting remote control. They simply switched to commercial software that already carries a valid signature and a reputation for being safe.
That shift matters for a business owner because most security tools are tuned to catch unknown, malicious code. A signed copy of ScreenConnect, AnyDesk, or another mainstream remote support product is not unknown. In many environments it is explicitly allowlisted, because the IT provider uses one of those products and does not want its own technicians blocked. The attacker inherits that trust, and the intrusion looks like a technician doing routine work.
The federal government documented the pattern years before the current spike. In advisory AA23-025A, CISA, NSA, and MS-ISAC described a campaign in which help desk-themed phishing emails led federal employees to download portable copies of ScreenConnect and AnyDesk. Because portable versions run in the user's context without installation or administrator rights, they slipped past controls designed to block software installs, and the attackers used the sessions to run refund scams against victims' bank accounts.
The technique has since matured. Huntress researchers documented attackers daisy-chaining rogue RMM tools in cases investigated during December 2025 and January 2026, including using the legitimate deployment tool Action1 to push ScreenConnect clients through installer packages. Stacking tools this way means that removing one agent does not end the intrusion, because a second or third remote channel is already in place. Huntress also observed lower-skilled actors using rogue RMM installers to launch scripts that searched browser history for financial services such as QuickBooks.
The assumption we hear most often is some version of "my MSP already has remote access, so any remote access tool on our network must be theirs." That belief is understandable and it is wrong. In a typical small business, remote access software arrives from several directions over the years: a previous IT vendor, a line-of-business software vendor's support team, an employee who installed a free tool to work from home, or a contractor who never removed their client. Nobody owns the list, so nobody notices when an attacker adds one more.
This is a different risk from the one we covered in what happens if your IT provider's own console is breached. That scenario is about the provider's platform becoming the attack path. RMM tool abuse is usually quieter: the provider's platform is fine, but the provider is not watching for remote tools it did not deploy. The questions you ask have to cover both.
Ask questions that require evidence, not reassurance. A provider managing this risk should be able to show you, in writing, which remote tools are approved for your environment and what happens when something else appears. These five questions separate a provider that has thought about RMM abuse from one that has not:
Notice what these questions have in common. None of them is about buying another product. They test whether your provider treats remote access as a controlled privilege with an owner, the same way you would treat a master key to the building. If you already hold a regular review with your provider, these belong on the agenda alongside the quarterly questions every business should be asking its IT provider.
A good answer is specific, documented, and testable. The provider names the tools, shows you the application control policy, and can demonstrate an alert firing when an unapproved agent is installed on a test machine. A weak answer leans on brand names ("we use a top-tier EDR"), on intent ("we would never allow that"), or on the provider's own tool being secure, which does not address tools the provider did not install.
Community resources make this easier to verify than it used to be. The LOLRMM project catalogs remote monitoring and management tools that can be abused, along with the files, network indicators, and registry artifacts each one leaves behind. A provider that references a catalog like this, or maintains its own equivalent, is treating unknown remote tools as something to hunt for rather than something to assume away.
The impact is that an attacker gets the same reach your IT provider has, without your provider knowing. RMM software typically runs with high privileges and can push scripts, transfer files, and open interactive sessions on every machine where it is installed. In the CISA case, that reach was used for direct financial fraud. In ransomware intrusions, the same access is used to stage data theft and encryption across the network.
There is also an oversight cost that leadership tends to underestimate. Cyber insurers and auditors increasingly ask who has remote and privileged access to your systems. If the true answer includes tools nobody can account for, any attestation you sign is weaker than it looks. That is the same problem we describe in cleaning up IAM, MFA, and privileged access: remote access tools are privileged access, and they belong in the same inventory as admin accounts.
The pattern is not limited to traditional software either. Our AI Lab has written about ghost AI agents that keep their credentials after their owners leave, and the governance lesson is identical: any non-human access path that outlives its business purpose becomes someone else's opportunity.
For a 20 to 300 person company, a defensible baseline does not require an enterprise security budget. It requires four things done consistently. First, a written list of approved remote tools with an owner for each. Second, application control that enforces that list, including portable executables. Third, monitoring that alerts a human when new remote access software is installed or executed, regardless of whether it is signed. Fourth, multi-factor authentication on every RMM and remote support login, including the provider's technicians and any third-party vendor portals.
Because many of these intrusions begin with a phone call or an email pretending to be the help desk, staff awareness is part of the control set too. CISA's advisory paired its technical mitigations with user training and phishing exercises for exactly that reason. If your team would let a caller "from IT" walk them through installing a support tool, the rest of the controls are being tested every day. Our guide to the phishing and social engineering tactics businesses fall for covers how those calls are typically scripted.
Finally, put the commitments in the contract. If your provider tells you unapproved RMM tools are blocked and alerted on, that statement should appear in your service agreement and be reported on, which is the same principle behind holding your MSP accountable with SLA metrics and QBRs.
When we onboard a client, one of the first things we do is inventory every remote access and RMM agent already present, because inherited tools from previous vendors are common. Each tool either gets a documented owner and purpose or gets removed. From there, our prevention-first stack uses default-deny application control, so an unapproved remote tool, including a portable one, simply does not run, rather than running and hoping someone notices.
Our security operations team then monitors for new remote access software attempts and for unusual use of approved tools, such as sessions at odd hours or from unexpected locations. Clients can see which tools are approved and why, so the answer to "who can reach our computers remotely?" is a list you can read, not a promise.
The 277% rise in RMM tool abuse is a governance problem before it is a technology problem. Start by asking your provider for the approved-tool list and the alert they would see if a second agent appeared, and judge the answer by how specific it is.
To see how application control, monitoring, and response fit together in a managed program, review Securafy's managed security services.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk through your current remote access tooling, where the blind spots are, and the fastest way to close them.