RMM Security: Hardening Your Own Stack Against Supply Chain Attacks

Your RMM reaches every endpoint you manage. That's the point of the tool, and it's also why attackers want it more than they want any single client network. RMM abuse showed up in roughly one in four incidents Huntress investigated over the past year, a 277% jump on the prior period. The controls that stop it aren't exotic, but they land in a specific order, and the PSA half of the problem gets almost no coverage anywhere. Here's what to harden, in what sequence, and what to put to the vendors holding your keys.

TL;DR

• RMM security starts with blast radius. One compromised tenant reaches every endpoint under it, so harden the console like a client environment.
• MFA and scoped access matter most. Enforced SSO plus per client roles closes common intrusion paths.
• API tokens are the quiet gap. Long lived tokens outlive password resets and offboarding.
• PSA is the other half. Documentation, credentials, and contracts live there, rarely hardened.
• Watch for a second RMM. Attackers install their own agent as a backdoor.

Why Your RMM Is the Most Valuable Box in the Room

An attacker who phishes one of your clients gets one network. An attacker who gets into your RMM gets a signed, trusted, pre approved path to every network you touch, and the traffic looks exactly like a technician doing a Tuesday afternoon patch run.

That last part is what makes it hard. RMM abuse doesn't trip the alarms that malware trips, because there's no malware. The agent is legitimate, the certificate is valid, the process is allowlisted by your own EDR policy, and the script execution is a feature you pay for. Security teams call this living off the land. In an MSP context it's more accurate to say the attacker is living off your trust relationship.

The economics follow from that. Ransomware operators worked out years ago that compromising one MSP is worth more than compromising fifty small businesses, because it costs the same effort and pays out fifty times. Huntress data puts more than half of the cases following suspicious Atera activity in direct connection to ransomware, and notes that when tools like Atera or RustDesk get abused, the damage can land in an hour or two rather than the days of dwell time defenders are used to planning around.

An hour is not enough time to notice, escalate, and contain. Which means detection alone won't save you here. The controls have to be preventive.

The Huntress team behind those numbers walks through how RMM abuse hides in plain sight:

What Kaseya and SimpleHelp Cost Their MSPs

Two incidents define the shape of this threat, and they failed in different ways. The last column is the one to read first.

Kaseya was the vendor's failure to own. REvil got in through a zero day, so there was no patch to miss and no configuration that would have helped. Coop Sweden closed 800 grocery stores because its point of sale systems were managed by an MSP running VSA. Nobody on that list had done anything wrong at the MSP level.

SimpleHelp inverted the pattern. CVE-2024-57727 let unauthenticated attackers pull arbitrary files, stored credentials included, straight off the server, and a fix shipped the same month the flaw was disclosed. DragonForce still got four months of use out of it, reaching an MSP's server, exfiltrating data, and pushing a locker to that MSP's client endpoints. CISA was still publishing advisories about the same unpatched flaw in June.

The difference matters. Kaseya was a vendor supply chain failure you couldn't patch your way out of. SimpleHelp was a patch that existed and hadn't been applied. The second category is the one you control, and it's the larger of the two by volume.

For the wider landscape these two incidents sit in, this breakdown of the Huntress 2026 Cyber Threat Report covers the year in attacker tradecraft:

The RMM Controls That Carry the Most Weight

The Five Eyes joint advisory AA22-131A is still the best baseline published for this, and it's worth reading in full. What follows is the subset that pays back fastest for a small to mid sized MSP, ordered by return on effort rather than by category.

Two of those deserve expansion.

API tokens are the control people skip. A technician leaves, you disable the account, you rotate the shared credentials, and you feel finished. The token that person generated to wire the RMM into a ticketing integration two years ago is still valid, still has API scope, and doesn't appear in any offboarding checklist. Pull the full token list quarterly, match every token to a named owner and a live integration, and kill everything that fails that test. It takes an afternoon.

The RMM console itself needs its own patch SLA. Every MSP has a patch policy for clients. Far fewer have a written commitment on how fast they patch their own management plane, which is the single system whose compromise costs the most. Put a number on it, 72 hours for critical, and hold to it the same way you'd hold to a client SLA.

Beyond that, the vaulting question. Administrator credentials used to authenticate into the RMM should live in a privileged access manager rather than a shared password entry, so that use is logged, scoped, and revocable in one move. We went through where that fits in the broader tooling picture in the MSP security stack breakdown.

Your PSA Is the Other Half of the Blast Radius

Search for RMM hardening guidance and you'll find plenty. Search for PSA hardening and the well runs dry, which is a strange gap given what's inside a PSA.

Your PSA holds client documentation, network diagrams, escalation contacts, contract terms, billing detail, and in a lot of deployments the credential store as well. An attacker who gets read access to that doesn't need your RMM. They have a map of every client environment you manage, ranked by contract value, with the technical detail to plan a targeted intrusion and the commercial detail to price the extortion. It's a reconnaissance goldmine that requires no exploitation to use.

Ransomware crews increasingly skip encryption entirely and go straight to data theft plus extortion, and a PSA export is close to the ideal target for that model. It's structured, it's sensitive, it names other companies, and it proves the breach on sight.

The controls are similar in shape to the RMM list and different in emphasis. Scope technician visibility to assigned clients only rather than the whole book. Turn off bulk export for anyone who doesn't need it, and alert when it fires. Separate documentation storage from the credential vault so one compromise doesn't yield both. Log and review access to the highest value client records the same way a law firm reviews access to a sealed matter.

And check whether your PSA and RMM share an identity provider and an admin group. In a lot of stacks they do, which means one compromised admin identity opens both halves at once. If they're separate products from separate vendors, that separation is only real when the accounts are genuinely distinct.

There's a retention question sitting underneath this too. PSAs accumulate. Ticket bodies from 2019 still carry the plaintext credentials a technician pasted in before anyone wrote a policy about it, and closed tickets rarely get purged because storage is cheap and nobody owns the decision. Run a keyword sweep across historical ticket text for password, passwd, and the naming pattern your team uses for local admin accounts. Whatever comes back is a credential you thought was rotated years ago, sitting in a system with a wider access list than your vault. Redact it, then set a retention rule so the same debt doesn't rebuild.

The integrations deserve a pass as well. A PSA typically holds connections into email, billing, documentation, and the RMM itself, each authenticated with a token that was scoped generously on day one to make setup work. Those tokens are lateral movement paths in both directions: into the PSA from a compromised integration, and out of the PSA into everything it's wired to. Treat the integration list the same way you treat the token list, quarterly, with a named owner per entry.

How to Spot a Second RMM You Didn't Install

Here's the control almost nobody writes about. A common attacker move is to install their own remote monitoring tool once they're inside, because it gives durable access that survives credential resets and blends into an environment where remote access agents are already normal. Atera, RustDesk, ScreenConnect, AnyDesk, and TeamViewer all show up in incident reports being used this way.

The detection is straightforward when you're looking for it and invisible when you aren't. Build an allowlist of the remote access tools your MSP sanctions, which should be a very short list. Then run a recurring query across managed endpoints for installed software, running services, and outbound connections matching known RMM signatures outside that list. Anything that comes back is either shadow IT or an intrusion, and both need an answer today.

Do the same for your own environment, not just client environments. The MSP's internal workstations are the ones that hold the console sessions.

This is also where the discipline of knowing what's running in an environment pays off generally, the same problem we looked at with unvetted apps landing in client stacks.

Red Canary's intelligence team sees the same surge from their vantage point. Their February data preview is a quick watch:

The Questions to Put to Your RMM and PSA Vendor

You inherit your vendor's security posture whether you evaluate it or not. Kaseya proved that. These are the questions that produce useful answers rather than a marketing PDF, and they belong in renewal conversations and new evaluations alike:

1. Can you enforce SSO and MFA at the tenant level so local authentication is impossible, not merely discouraged?
2. How is tenant isolation implemented, and has it been tested by a third party? Ask for the report, not the assertion.
3. Are agent updates cryptographically signed, and can a compromise of your build pipeline push code to my endpoints?
4. What's your committed breach notification window in hours, and is it in the contract or the marketing copy?
5. What's your median time from vulnerability disclosure to patch availability over the last 24 months?
6. Can I export my full data set, including ticket history and documentation, in a usable format without a support ticket?

That last one reads like a procurement question rather than a security question. It's both. An MSP that can't leave a compromised vendor quickly is an MSP that has to keep running the compromised vendor while it figures out a migration, and that window is measured in months. Portability is a security control. We laid out the wider vendor assessment approach in the vendor risk management guide.

A 30, 60, 90 Day Sequence

Checklists fail because everything on them looks equally urgent. It isn't. Work in this order:

Days 1 to 30. Enforce MFA on every RMM and PSA account with zero exemptions, including break glass, which gets a hardware key instead. Inventory every API token, kill the orphans. Confirm no management console is reachable from the open internet. Write the patch SLA for your own tooling and put a name against it.

Days 31 to 60. Rebuild roles so technicians see only assigned clients in both RMM and PSA. Turn on script approval and mass action alerting, and route those alerts somewhere a human reads within minutes. Run the unauthorized RMM sweep across every managed endpoint and your own internal machines.

Days 61 to 90. Move admin credentials into a privileged access manager. Send the vendor questions above to your RMM and PSA providers in writing. Run a tabletop on the scenario where your RMM tenant is confirmed compromised at 2pm on a Friday, and find out how long it takes you to cut agent connectivity across every client.

That tabletop is the most uncomfortable and most useful item on the list. Teams routinely discover they have no rehearsed way to sever RMM access at scale, which is precisely the capability the one hour ransomware window demands.

Where Fewer Consoles Means Less Surface

There's a structural point underneath all of this. Every additional console with privileged reach into client environments is another identity boundary, another patch obligation, another token store, another audit log nobody reads. Eight tools means eight chances to miss the SimpleHelp patch.

That's part of why we built OpenFrame the way we did. It's AI-native infrastructure for IT and security work, with native PSA included rather than bolted on from a third party, which collapses the RMM and PSA identity problem into one boundary to harden instead of two to keep in sync. No lock-in on the data, so the portability question above has a clean answer. It won't fix a weak MFA policy, and consolidation is a smaller lever than access control. But fewer privileged consoles is a genuinely smaller attack surface, and that arithmetic doesn't change.

Whatever you run, the sequence holds. MFA, scoping, tokens, patching, detection, in that order.

Your clients bought your judgment about security. The tool you use to deliver it is the one asset that reaches all of them at once. Harden it first.