Secure RMM and remote-access software before attackers use it

Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.

What the joint guide establishes

Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.

Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.

The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.

Establish an authorized remote-access inventory

DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.

1. Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.
2. Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.
3. Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.
4. Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.
5. Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.

Make the provider boundary explicit

DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.

Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.

Applicability and limits

The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.

Official reference

Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.