Remote Monitoring and Management (RMM) Tool Security Guide

Remote monitoring and management (RMM) tools give whoever controls them interactive, persistent and usually privileged access to every endpoint they reach, and attackers have learned that legitimate RMM software rarely trips an alert. The same signed agent that lets an IT team or managed service provider (MSP) patch and support devices lets a ransomware operator, a tech support scammer or a compromised MSP do the same. This guide covers governance of approved RMM, the RMM inventory, allowlisting and blocking unauthorised remote access software, baselining and RMM detection, hardening the RMM platform itself and the MSP relationship. It is written for endpoint, SOC and IT operations teams and for anyone who buys managed services. It names tool categories, not products.

Key takeaways

• RMM abuse is a common access and persistence path. CISA, NSA and MS-ISAC note that RMM software "generally does not trigger antivirus or antimalware defenses" and lets attackers "avoid using custom malware".
• Approve one RMM, block the rest. Allowlist the approved agent by publisher and block both installation and execution of portable versions of anything else, at the endpoint and at the network edge.
• The RMM console is a tier 0 system. Whoever controls it can run scripts as SYSTEM or root on every managed device, so it needs phishing-resistant MFA, least privilege roles and safeguards on mass actions.
• Baseline normal before you hunt. Know which hosts run which agent, which technicians connect and when, so an unapproved RMM agent or an out-of-hours session stands out.
• MSP access is your attack surface. Contract for MFA, separate credentials per customer, log retention of at least six months and incident notification timeframes.

What counts as an RMM or remote access tool

ATT&CK T1219 Remote Access Tools describes adversaries using legitimate remote access software to create "an interactive command and control channel", and in v20 splits it into T1219.001 IDE Tunneling, T1219.002 Remote Desktop Software and T1219.003 Remote Access Hardware. The same risk spans several categories of remote access software:

Remote Desktop specifically is covered in the Remote Desktop (RDP) Security Guide; this guide concentrates on RMM and remote support software.

How RMM tools are abused

Joint advisory AA23-025A (CISA, NSA and MS-ISAC, January 2023) and the 2023 joint Guide to Securing Remote Access Software describe the main patterns of remote monitoring and management tool abuse. The joint guide notes that RMM agents carry valid code-signing certificates and are often deployed silently by script, which is why remote access tool abuse blends into normal IT activity on Windows, macOS and Linux alike. The descriptions below are conceptual, for defenders.

• Help desk lures: AA23-025A reports "help desk-themed phishing emails" since at least June 2022 that led staff to download remote support software, which was then used for refund scams. Microsoft reported in May 2024 that Storm-1811 flooded inboxes with spam, then phoned victims posing as IT support and talked them into granting a Quick Assist session, followed by more RMM tools and ransomware.
• Fake RMM and lookalike installers: lures that pose as an IT support portal, a software update or a familiar RMM download page, and binaries renamed to blend in; the joint guide cites a remote access tool renamed as ctfmon.exe, a legitimate Windows process name.
• Portable executables: the joint guide notes that portable remote support tools run in the user's context without installation, so removing local admin rights and blocking installers does not stop them.
• Remote access tool persistence: the guide calls RMM "an attractive tool for malicious actors to maintain persistence and move laterally". Attackers install a second, quieter RMM agent as a backup channel after the first foothold, often deployed silently by script.
• Compromised RMM platform or MSP: ATT&CK T1199 Trusted Relationship covers abuse of IT providers' access. AA23-025A warns attackers "can exploit trust relationships in MSP networks", reaching many customers at once.
• Abuse of the approved tool: valid technician credentials, an exposed console or an unpatched on-premises RMM server let an attacker use the tool you approved, where allowlisting does not help.

The Living off the Land Guide places RMM abuse among other dual-use tools.

Governing approved RMM

Start with policy: one approved RMM platform for internal IT, one per MSP where contracts require it, and one approved remote support method for the help desk. Everything else is unauthorised by default.

• RMM inventory: the joint guide's first step is to "Audit remote access software and their configurations on devices on your network". Record each approved tool, version, owner, which device groups run the agent, which tenant or console it reports to, and who holds console access.
• Tenant binding: an approved product enrolled to someone else's tenant is still unauthorised. Check agent configuration for your tenant or server identifier, not just the binary's publisher.
• Remove what is not used: ATT&CK mitigation M1042 says disable unnecessary remote connection functions, including built-in features of supported applications. Microsoft advises organisations that use another tool, such as Remote Help, to "block or remove Quick Assist as a best practice".
• Ownership: one service owner for each RMM platform, with access reviews of technician accounts at least quarterly.

RMM allowlisting and blocking unauthorised remote access software

AA23-025A calls for application controls that "allowlist approved RMM programs" and "prevent both installation and execution of portable versions of unauthorized RMM software". Layer the controls so that one gap does not open the door:

Run application control in audit mode first, collect every remote access tool that would be blocked, and resolve each one before enforcing. See the Application Allowlisting Guide.

RMM baselining and detection

The joint guide says defenders "should first establish a security baseline of normal network activity". For RMM that means a list of which agents run where, which consoles they talk to, which technician accounts open sessions and at what hours. Detection then looks for deviations.

ATT&CK's detection strategy for T1219 is tool-agnostic: agent execution, followed by persistence, a long-lived outbound connection and interactive child processes. Build rules on that chain rather than on product names alone. On Windows, process and DNS telemetry from Sysmon helps; see the Sysmon Guide.

Hardening the RMM platform

An RMM console with script execution is equivalent to domain admin on every managed device. The joint guide's recommendations and identity practice point to the same controls:

• Strong authentication: SSO with phishing-resistant MFA for every technician; the guide recommends "just-in-time access and/or two-factor authentication based on the level of risks".
• Least privilege roles: configure "'reduced privilege' RMM tools for common uses, like read-only monitoring", and reserve script execution and remote control for a smaller group.
• Mass action safeguards: the guide suggests re-triggering MFA if one account pushes commands to 10 or more devices within an hour. Require approval or a second person for scripts targeting all devices.
• Script governance: maintain a reviewed script library, sign scripts where the platform supports it and log every execution with the script content.
• Exposure and patching: do not expose on-premises RMM servers or consoles directly to the internet; patch them on an emergency cycle, prioritising internet-facing systems as the guide advises.
• Logging: forward console audit logs (logins, role changes, sessions, scripts, agent enrolments) to your SIEM and keep them at least as long as your incident look-back.
• Session consent: for user devices, require end-user acceptance and an on-screen indicator for interactive sessions where workflows allow.

Where identity fits

RMM access is identity access. Technician accounts, MSP accounts, API keys used by ticketing or PSA integrations and agent enrolment tokens are all credentials that can command every endpoint. Give technicians named accounts, never shared logins; store RMM API keys in a vault with owners and rotation; and revoke access the day a technician or MSP leaves. See the Third-Party Access Guide and the Privileged Access Management Guide.

MSP RMM security

When an MSP runs RMM on your estate, its security becomes yours. The 2022 joint MSP advisory from the Five Eyes agencies and the NCSC's 2025 guidance on choosing an MSP give a contract baseline.

In 2023 CISA's Joint Cyber Defense Collaborative published, with its partners, an RMM Cyber Defense Plan organised into two pillars, Operational Collaboration and Cyber Defense Guidance, to improve threat information sharing across the RMM ecosystem. Ask whether your RMM provider and MSP take part in such sharing. See the Third-Party Risk Management Guide.

Responding to unauthorised RMM

1. Treat it as an incident until explained: an unapproved agent may be a user's convenience install or an attacker's backup channel.
2. Contain: isolate the host and block the tool's cloud domains across the estate, since a second host may run the same agent.
3. Establish the session history: when the tool arrived, who launched it, inbound session times and source details from local tool logs, and any files transferred.
4. Hunt estate-wide for the same binary, hash, service name and domains, and for any other remote access tool installed in the same window.
5. Reset credentials used on the host and check for new accounts, scheduled tasks and other persistence.
6. Close the gap that allowed it: application control rule, egress block or user awareness.

Rolling out RMM controls

1. Discover: inventory every remote access tool installed or seen on the network in the last 90 days, including MSP and vendor agents.
2. Decide: choose the approved RMM and remote support method, assign owners and write the policy.
3. Harden the approved platform: SSO, MFA, roles, mass action safeguards and log forwarding, before enforcing blocks that drive all work through it.
4. Audit-mode controls: application control and DNS blocking in audit for two to four weeks; contact each owner of a would-be-blocked tool.
5. Enforce in rings: pilot IT devices first, then general users, then servers. Roll back a ring by switching its policy to audit.
6. Detect and review: deploy the detections above and review RMM console access quarterly.

Small organisations that rely on one MSP should focus on contract terms, MFA on the MSP's console, egress blocking of other RMM domains and Quick Assist removal. Large organisations often run several RMM platforms through mergers and outsourcing; consolidate where possible and treat each remaining console as a privileged system with its own access reviews.

Detection and measurement

• Unauthorised RMM rate: endpoints running remote access software not on the approved list (target zero, trended weekly).
• Allowlist coverage: share of endpoints with application control enforcing the RMM policy.
• Console identity hygiene: technician and MSP accounts with phishing-resistant MFA, and accounts unused for 30 days.
• Mass action events: scripts run against more than 10 devices, and the share with recorded approval.
• Time to contain: median hours from detecting an unapproved RMM to isolation.

Common failure patterns

• Blocking installs but not execution: portable remote support tools run anyway from the user's Downloads folder.
• Allowlisting by product, not tenant: the approved agent enrolled to an attacker's account sails through.
• Single-factor or shared technician accounts on an internet-facing console, giving one stolen password control of every device.
• No safeguards on fleet-wide actions: in the Stryker cyberattack, one hijacked admin account in a device management platform was used to wipe tens of thousands of devices. RMM consoles carry the same power.
• Leftover MSP agents from former providers that still report to consoles you no longer control.
• Help desk processes that train users to accept remote sessions from anyone who calls, which is what vishing crews exploit.

Framework mapping

Practitioner checklist

• Publish an approved list of RMM and remote support tools with owners, and treat everything else as unauthorised.
• Inventory remote access software and agent tenant bindings on every endpoint, and diff it daily.
• Allowlist the approved agent and block installation and execution of other remote access tools, including portable builds.
• Block unapproved RMM domains through DNS and proxy, and restrict the approved console to VPN, VDI or known networks.
• Remove or block Quick Assist where another remote support tool is used.
• Enforce SSO, phishing-resistant MFA, least privilege roles and approval for fleet-wide scripts on every RMM console.
• Forward RMM console audit logs to the SIEM and alert on new technicians, new source addresses and mass actions.
• Contract MSPs for MFA, per-customer credentials, six months of logs and incident notification timeframes.
• Remove agents and accounts of former MSPs and vendors.

Standards and references

• CISA, NSA and MS-ISAC: AA23-025A, Protecting Against Malicious Use of Remote Monitoring and Management Software
• CISA, NSA, FBI, MS-ISAC and INCD: Guide to Securing Remote Access Software
• CISA JCDC: Remote Monitoring and Management Cyber Defense Plan
• MITRE ATT&CK: T1219 Remote Access Tools
• MITRE ATT&CK: T1199 Trusted Relationship
• NCSC: Choosing a managed service provider (MSP)
• NCSC New Zealand and partners: Protecting against cyber threats to managed service providers and their customers
• Microsoft Threat Intelligence: Threat actors misusing Quick Assist in social engineering attacks leading to ransomware

Related NHI Mgmt Group resources: Living off the Land Guide · Third-Party Access Guide · Vishing and Smishing Guide · Endpoint Security Guide