Security
On Friday, a popular IT tool called Kaseya VSA was hacked.

Remote Monitoring and Management (RMM) software gives IT teams and Managed Service Providers (MSPs) powerful tools for managing endpoints remotely. Administrators can monitor device health, deploy software, execute scripts, install patches, troubleshoot systems, and remotely access endpoints from a centralized platform.
These capabilities make RMM security particularly important. If an attacker compromises an RMM platform or privileged account, the same administrative capabilities used by legitimate technicians can potentially be abused across multiple managed endpoints.
The 2021 Kaseya VSA attack demonstrated the potential impact. Attackers exploited vulnerabilities affecting the RMM platform as part of a ransomware attack that reached downstream organizations. The incident highlighted a broader security principle for the industry: RMM platforms should be treated as privileged infrastructure and protected accordingly.
There are common-sense steps to securing RMM software, such as keeping software patched, maintaining reliable backups, using strong authentication, and limiting administrative privileges. However, organizations should go further by applying multiple layers of protection around RMM access, automation, endpoints, and administrative activity.
This guide covers practical RMM security controls that IT teams and MSPs can use to reduce risk and limit the potential impact of compromised accounts, software vulnerabilities, malware, and other threats.
RMM platforms typically have much more control over endpoints than ordinary business applications. Depending on the platform and permissions assigned, an administrator may be able to:
For an internal IT department, compromising this level of access could expose a significant portion of the organization's infrastructure. For an MSP, the potential scope can be even greater because a single RMM environment may provide administrative access to endpoints belonging to multiple customers.
RMM security therefore needs to address more than passwords. Identity, permissions, network exposure, endpoint security, automation, logging, backups, and incident response should all be part of the security strategy.
Understanding how RMM environments can be exposed helps IT teams determine where additional controls are needed.
Administrator credentials are valuable because they can provide extensive access to managed endpoints. Stolen passwords, phishing attacks, credential reuse, or poorly controlled accounts can give attackers a path into an RMM environment.
Multi-factor authentication, individual user accounts, least privilege, and regular access reviews can reduce this risk.
Like any software, RMM platforms can contain vulnerabilities.
Keeping the platform and supporting infrastructure updated reduces exposure to known vulnerabilities. Zero-day vulnerabilities present a more difficult challenge because a patch may not initially exist.
This is one reason RMM security should use defense in depth. If one control fails, other security layers can still limit what an attacker can reach or do.
Not every technician needs unrestricted access to every endpoint, customer, script, or administrative function.
Overprivileged accounts increase the potential impact of compromised credentials and human error. Permissions should reflect actual job responsibilities.
Remote access is one of the most useful capabilities of RMM software, but it is also sensitive.
Organizations should control who can initiate remote sessions, which endpoints each user can access, and what technicians can do during those sessions.
RMM scripting and automation can execute actions across large groups of endpoints very quickly.
This efficiency can become a security risk if an account is compromised or an unsafe script is deployed. Controls around script creation, approval, execution, and logging can help reduce this risk.
Organizations should combine several security controls rather than relying on a single defensive measure.
Enable multi-factor authentication (MFA) for RMM user accounts, particularly accounts with administrative privileges.
MFA adds another authentication requirement when someone attempts to access an account. This can reduce the risk associated with stolen or exposed passwords.
MFA should not be treated as the only defense. It works best alongside strong passwords, individual accounts, appropriate permissions, monitoring, and other access controls.
Users should only receive the permissions required to perform their responsibilities.
A technician responsible for a particular customer, department, or endpoint group does not necessarily need unrestricted administrative access across the entire environment.
Review privileges regularly and remove access when:
Reducing unnecessary privileges limits what a compromised account can potentially affect.
Role-based access control (RBAC) makes it easier to assign permissions consistently.
Instead of manually creating unique permission sets for every technician, organizations can establish roles based on responsibilities and assign appropriate access to those roles.
Sensitive functions such as account administration, scripting, security configuration, and backup deletion may warrant tighter restrictions.
Where practical, limit where administrators can access the RMM management interface.
Organizations may use network restrictions, approved IP addresses, VPN access, or other controls depending on their RMM architecture and operational requirements.
Reducing unnecessary exposure can eliminate potential paths into privileged management systems.
For applicable internet-facing infrastructure, a Web Application Firewall (WAF) can add another layer of protection against certain web-based attacks.
A WAF can inspect web traffic and apply security rules intended to identify or block malicious requests.
It does not replace secure application development, vulnerability remediation, authentication, or patching. Instead, it forms another component of a layered security strategy.
Intrusion detection and prevention technologies can help identify suspicious network activity.
An Intrusion Prevention System (IPS), for example, may identify known malicious traffic patterns and block certain attacks before they reach protected infrastructure.
Organizations should combine these technologies with endpoint monitoring and RMM activity logging to improve visibility across different layers of the environment.
Apply security updates to RMM infrastructure and related systems promptly.
Organizations using self-hosted platforms should establish clear responsibility for maintaining the RMM server, operating system, database, supporting services, and other infrastructure.
Patch management reduces exposure to known vulnerabilities, although additional controls remain necessary for threats that do not yet have available patches.
Securing the management platform does not eliminate the need to protect individual endpoints.
Endpoint controls can provide additional barriers if another component of the environment is compromised.
Define the minimum security configuration required for managed endpoints.
Depending on the organization and device type, this baseline can include:
RMM monitoring can help IT teams determine whether these controls remain enabled across managed devices.
Secure Boot is designed to help protect the startup process by allowing a system to boot using trusted software.
On compatible hardware and operating systems, Secure Boot can form part of an organization's endpoint security baseline. It may help protect against certain threats that attempt to interfere with the system before the operating system fully loads.
Secure Boot does not directly protect an RMM platform from compromise and should not be considered a replacement for endpoint protection, patching, MFA, or access controls.
Instead, it adds another security layer to supported endpoints.
IT teams managing large device fleets can establish standards for when Secure Boot should be enabled and periodically verify that endpoint security configurations remain compliant.
Automation is one of the major advantages of RMM software. A technician can perform an administrative task once and deploy it across many endpoints.
That capability deserves additional safeguards.
RMM platforms should provide safeguards for unusual or high-impact mass scripting activity.
For example, an organization could require additional verification when an account attempts to execute a new script across a large number of endpoints.
Alerts can also be generated when script activity differs significantly from the technician's normal behavior.
Organizations can implement approval processes for sensitive scripts.
Instead of allowing any technician to immediately create and execute new scripts across production endpoints, higher-risk automation can require review by another authorized person.
Once reviewed and approved, trusted scripts can be maintained in a controlled script library.
For particularly sensitive environments, consider separating the ability to create automation from the ability to approve high-impact execution.
Separation of duties reduces the amount of control held by a single account.
RMM platforms should maintain detailed records of script activity.
Logs should make it possible to determine:
These records can be invaluable when investigating suspicious activity.
Account security is fundamental because legitimate RMM credentials can provide extensive access.
Every technician should have an individual account.
Shared accounts make it difficult to determine which administrator performed an action and complicate incident investigations.
Individual identities improve accountability and allow permissions to be revoked without disrupting other technicians.
Periodically review RMM users and their permissions.
Look for:
Account reviews should also be incorporated into employee offboarding procedures.
New administrative accounts should not appear without appropriate authorization.
RMM platforms should provide mechanisms for notifying administrators when accounts are created or when privileges change.
For particularly sensitive environments, organizations may require approval before privileged accounts become active.
Backups are critical during ransomware and other destructive security incidents.
If an attacker gains administrative access to an environment, they may attempt to destroy or encrypt backups before disrupting production systems.
Do not assume every RMM administrator needs permission to delete or modify backups.
Backup administration should follow least privilege.
High-risk operations such as deleting or overwriting backups can require additional authentication or approval.
This can make it more difficult for a compromised administrative session to immediately destroy recovery options.
Organizations should maintain backups according to their recovery requirements and ensure that compromise of ordinary endpoint credentials does not automatically provide unrestricted control over every backup.
Periodically test restoration procedures so the organization knows its backups can actually be used during an incident.
Preventive controls are important, but organizations also need the ability to identify suspicious activity.
Potential indicators of RMM abuse can include:
Not every unusual event indicates an attack. Monitoring provides the information IT teams need to investigate whether activity is legitimate.
RMM logs can be combined with information from endpoints, authentication systems, firewalls, and other security tools.
Centralized visibility can make it easier to identify relationships between events.
For example, an unusual administrator login followed by a new script deployment across hundreds of endpoints deserves considerably more attention than either event viewed in isolation.
Organizations should have an incident-response plan before an RMM security incident occurs.
A compromised RMM environment can affect many systems quickly, so teams need clearly defined responsibilities and escalation procedures.
Identify the RMM infrastructure and endpoints potentially involved in the incident.
Where appropriate, isolate affected systems to limit further malicious activity while preserving logs and evidence required for investigation.
Investigate administrator accounts, active sessions, service accounts, API credentials, and other authentication mechanisms that may have been exposed.
Credentials should be handled according to the organization's incident-response procedures.
Analyze recent:
This can help establish the scope and timeline of the compromise.
When investigating how to remove malware from RMM-managed endpoints, first determine what malware is present and how extensively the endpoint has been compromised.
Deleting a visible malicious file may not fully remediate the system. Malware can establish persistence, create additional accounts, alter security settings, steal credentials, or deploy other malicious components.
IT teams should follow established incident-response procedures, identify affected systems, contain the threat, and validate that remediation has removed malicious persistence.
For serious compromises, rebuilding affected endpoints from a known-good state may provide greater assurance than attempting to clean individual malicious components.
If systems need to be restored, confirm that the selected backups predate the compromise and have not been altered.
After restoration, validate security configurations, apply necessary updates, address compromised credentials, and monitor systems for signs of recurring malicious activity.
A repeatable security checklist helps IT teams verify that important controls remain in place.
Review the following regularly:
The checklist should be reviewed whenever the RMM environment, security requirements, or threat landscape changes.
Some RMM security measures can add friction for technicians and administrators. Additional authentication, restricted privileges, script approvals, and access controls can add steps to tasks that would otherwise be immediate.
The level of access provided by RMM software makes those safeguards important.
The Kaseya VSA incident demonstrated the potential consequences when vulnerabilities in privileged management infrastructure are exploited. However, RMM security should not focus on preventing a repeat of one particular attack.
Organizations need controls capable of addressing multiple failure scenarios, including compromised credentials, excessive privileges, malicious scripts, software vulnerabilities, malware, misconfiguration, and human error.
No single security measure can eliminate all of these risks.
MFA can protect authentication but cannot patch a software vulnerability. Secure Boot can protect aspects of the endpoint startup process but cannot prevent stolen RMM credentials. A firewall can restrict network access but cannot necessarily stop an authorized account from being abused.
Layering these controls creates a stronger overall security posture.
RMM security refers to the controls and practices used to protect Remote Monitoring and Management platforms, administrative accounts, remote connections, automation, and managed endpoints against unauthorized access and abuse.
Because RMM software can provide extensive control over endpoints, organizations should treat it as privileged IT infrastructure.
RMM platforms provide centralized administrative capabilities. A sufficiently privileged RMM account may be able to remotely access systems, execute scripts, deploy software, or change configurations across multiple endpoints.
This makes protecting RMM accounts and administrative capabilities particularly important.
MSPs can strengthen RMM security by requiring MFA, applying least privilege, reviewing accounts regularly, controlling remote access, monitoring administrative activity, protecting scripts and automation, maintaining reliable backups, and securing individual endpoints.
Secure Boot primarily protects the boot process of supported endpoints rather than the RMM platform itself.
It can contribute to a layered endpoint security strategy alongside endpoint protection, patching, access controls, encryption, and monitoring.
MFA can significantly strengthen account authentication, but it cannot prevent every type of RMM compromise.
For example, MFA does not eliminate vulnerabilities in the underlying software. Organizations should combine MFA with patching, least privilege, monitoring, network controls, and other defensive measures.
Organizations can restrict scripting privileges, maintain approved script libraries, require additional authorization for high-impact automation, monitor mass script execution, and retain logs showing who executed scripts and where they ran.
Follow your incident-response process. Determine the scope of the compromise, isolate affected systems where appropriate, investigate accounts and administrative activity, address malicious access, remediate affected endpoints, and restore systems from trusted backups when necessary.
At Level, we understand the modern challenges faced by IT professionals. That's why we've crafted a robust, browser-based Remote Monitoring and Management (RMM) platform that's as flexible as it is secure. Whether your team operates on Windows, Mac, or Linux, Level equips you with the tools to manage, monitor, and control your company's devices seamlessly from anywhere.
Ready to revolutionize how your IT team works? Experience the power of managing a thousand devices as effortlessly as one. Start with Level today—sign up for a free trial or book a demo to see Level in action.