Remote Monitoring and Management software is one of the most important tools in a managed service provider’s stack. It helps technicians support customers, push updates, troubleshoot endpoints, run scripts, and respond quickly when something breaks.
That convenience is exactly why RMM tools deserve more security attention.
For an MSP, RMM is not just another application. It is a trusted remote access layer that may touch dozens, hundreds, or even thousands of customer systems. If attackers compromise that access, they may not need custom malware or noisy exploitation. They may be able to use legitimate tools, trusted credentials, and normal administrative workflows to move faster than defenders expect.
BleepingComputer recently highlighted the need for MSPs to test RMM security controls. That message lines up with CISA’s guidance on malicious use of remote monitoring and management software and its broader warnings about threats to managed service providers and their customers.
The takeaway is simple: MSPs should not only configure RMM securely. They should test whether those controls actually work.
Why RMM Security Matters So Much
RMM platforms sit in a sensitive position. They often have agent-based access across customer endpoints, administrative workflows, scripting capabilities, remote desktop features, software deployment functions, and monitoring visibility.
That is powerful when used correctly. It is dangerous when abused.
CISA has warned that cybercriminals can use legitimate RMM software for persistence, command and control, and remote access. This is attractive to attackers because the activity can blend into normal IT support behavior. Instead of dropping a custom backdoor, an attacker may use the same remote management channel that technicians already trust.
For MSPs, the risk is multiplied. A single weak technician account, over-permissioned role, poorly monitored script function, or shared credential can become a path into multiple customers. That creates business risk, legal risk, cyber insurance risk, and reputational risk.
The right response is not to abandon RMM. The right response is to treat it like privileged infrastructure.
Eight RMM Controls MSPs Should Test
Maintain an Approved RMM Inventory
MSPs should know exactly which RMM tools are approved, where agents are installed, who owns each deployment, and which customer environments are connected.
This sounds basic, but it is often where problems start. Shadow tools, legacy agents, trial software, unmanaged remote access utilities, and forgotten installs can create hidden access paths.
A practical test is straightforward: compare approved RMM inventory against endpoint telemetry, software inventory, EDR data, and customer asset lists. Anything outside the approved list should be investigated.
Enforce MFA and Strong Identity Controls
Every RMM administrator and technician account should require multi-factor authentication. Ideally, RMM access should be tied into centralized identity, conditional access, strong password policies, and account lifecycle management.
MSPs should test whether MFA is required for all privileged actions, all remote access methods, and all emergency accounts. They should also verify that former employees, contractors, and inactive accounts are removed quickly.
If an attacker can bypass identity controls, the RMM platform can become their front door.
Apply Least Privilege and Role-Based Access
Not every technician needs access to every customer. Not every role needs scripting rights, file transfer, command execution, policy changes, or administrator-level control.
Least privilege should be enforced by role, customer, function, and time. A help desk technician may need remote support access for a specific customer, but that does not mean they need unrestricted access across the entire client base.
MSPs should test this by asking: what can a compromised junior technician account actually do? Can it access unrelated customers? Can it run scripts broadly? Can it disable security tooling? Can it create new admin accounts?
If the answer is yes, the RMM permission model needs work.
Segment Customer Access
Customer environments should not be treated as one flat administrative plane. RMM access should be segmented so a compromise in one customer context does not automatically create access to others.
Segmentation can include separate customer groups, restricted technician assignments, different admin roles, approval workflows, and clear separation between internal MSP systems and customer systems.
This is especially important because MSP trust relationships are attractive to attackers. CISA has repeatedly warned that MSP compromises can introduce downstream risk to customers.
Monitor RMM Activity Like Security-Critical Telemetry
RMM logs should not sit unused inside the platform. Login activity, failed authentication attempts, new device enrollments, script execution, remote sessions, file transfers, privilege changes, policy updates, and agent uninstall events should feed monitoring and alerting workflows.
The test is simple: can the security team see suspicious RMM behavior quickly?
Examples include logins from unusual locations, after-hours remote sessions, mass script execution, access to many customers in a short window, new admin account creation, or changes to logging settings.
If RMM activity is not monitored, attackers may be able to operate inside trusted tooling with limited visibility.
Control Scripts, Automation, and File Transfer
RMM scripting is useful, but it is also high risk. Script execution can become a mass deployment mechanism if an account is compromised.
MSPs should restrict who can run scripts, require approval for high-impact actions, maintain script libraries, log script content and execution results, and block unapproved or ad hoc scripts where possible.
File transfer and remote shell functions should receive similar scrutiny. The goal is not to slow technicians unnecessarily. The goal is to prevent one compromised account from turning the RMM platform into a distribution system for ransomware, credential theft tools, or unauthorized software.
Patch and Harden the RMM Platform Itself
RMM platforms, agents, plugins, integrations, and supporting identity systems must be patched quickly. MSPs should also review configuration baselines, disable unused features, restrict external access, and harden administrative consoles.
Patch management should include both the RMM product and the infrastructure around it. That means identity providers, VPNs, browsers, endpoints, remote access gateways, and backup systems all matter.
A good test is to verify whether RMM security updates are tracked, prioritized, deployed, and confirmed — not just assumed.
Test Backup, Recovery, and Incident Response
If the RMM platform is abused, the MSP needs a response plan that is already practiced.
That plan should include how to disable compromised accounts, revoke sessions, isolate affected agents, communicate with customers, preserve logs, rebuild trusted access, and verify that attackers no longer have persistence.
Backups matter too. CISA recommends testing backups and keeping them isolated from ransomware paths. For MSPs, backup and recovery plans should include internal systems as well as customer-facing support systems.
What Business Owners Should Ask Their MSP
If you rely on an MSP, you do not need to know every technical detail of their RMM stack. But you should ask practical questions:
Do you require MFA for all RMM access?
Are technician permissions limited by customer and role?
Do you monitor RMM logins, sessions, scripts, and policy changes?
How do you prevent one compromised account from reaching all customers?
How often do you test RMM incident response?
Can you prove that inactive accounts and old agents are removed?
These questions are not about distrust. They are about shared risk. RMM access is part of your security boundary, even when the platform is operated by a third party.
The Bottom Line
RMM software is not inherently bad. It is essential for modern managed services. But because it provides trusted remote access, it must be governed like a privileged system.
For MSPs, that means testing identity, access, segmentation, logging, scripting, patching, backup, and incident response controls before an attacker tests them first.
For customers, it means asking whether your provider can demonstrate how RMM access is secured and monitored.
Prometheus Cybersecurity helps organizations review exposure, validate controls, and identify where trusted access could become business risk. If your team depends on RMM software, now is the right time to test the controls around it.
Resources
BleepingComputer: How to secure RMM software: 8 controls MSPs should test — https://www.bleepingcomputer.com/news/security/how-to-secure-rmm-software-8-controls-msps-should-test/
CISA: Protecting Against Malicious Use of Remote Monitoring and Management Software — https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a
CISA: Protecting Against Cyber Threats to Managed Service Providers and their Customers — https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a
NIST SP 800-171 Rev. 3 — https://csrc.nist.gov/pubs/sp/800/171/r3/final
NIST SP 800-53 Rev. 5 — https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final