What breaks when remote monitoring and management tools are not baselined properly?

Why This Matters for Security Teams

remote monitoring and management tools are designed to create trusted access paths, which is exactly why poor baselining becomes a security problem rather than a housekeeping issue. If a SOC does not know which RMM binaries, service names, parent processes, hosts, and external destinations are normal, it cannot reliably distinguish sanctioned support from misuse. That weakens detection, slows triage, and makes containment decisions less certain.

The operational risk is not limited to one alert. A badly baselined RMM can become an accepted exception that attackers inherit, especially when it is installed on many endpoints, permitted through firewalls, or allowed to execute under privileged service accounts. Current guidance in the NIST Cybersecurity Framework 2.0 emphasises asset visibility, protective controls, and continuous monitoring because those foundations determine whether access is normal, unusual, or malicious.

Security teams also underestimate how quickly trust erodes once an RMM is used for more than one purpose. Support teams may use it for patching, remote troubleshooting, and break-glass access, while adversaries may abuse the same channel for persistence, lateral movement, and data collection. In practice, many security teams encounter RMM misuse only after an endpoint investigation has already confirmed the tool was active, rather than through intentional baselining and review.

How It Works in Practice

Effective baselining starts by defining what “normal” means for each remote management tool, not for the organisation as a whole. The SOC should track host prevalence, installation source, signed or unsigned binaries, associated services, command-line patterns, remote destinations, and the business owner for each deployment. That gives analysts enough context to separate a helpdesk platform on 500 managed laptops from the same tool appearing on a finance server at 2 a.m.

Baselining should be tied to the security data that already exists in endpoint, network, and identity telemetry. When an RMM launches, the event should be compared with expected user, device, and network behaviour. If the tool appears on a device that has no support relationship, no maintenance window, and no approved administrator account, it should be treated as suspicious until validated. This is where attack-pattern mapping from MITRE ATT&CK is useful, because many adversaries rely on legitimate remote access software to blend into routine operations.

• Maintain an inventory of approved RMM tools, versions, and business owners.
• Record where each tool is expected to run and which accounts may launch it.
• Alert on first-seen installations, unusual parent-child process chains, and rare network destinations.
• Correlate RMM use with privilege changes, credential activity, and new persistence mechanisms.
• Review whether firewall allowlists and EDR exclusions match current support needs.

Teams should also baseline the surrounding workflow. If remote support normally requires ticket numbers, change windows, and named technicians, those signals should be part of the detection logic. Where agentic automation is involved, the same discipline applies to non-human identities and service credentials, because automation without provenance quickly becomes indistinguishable from compromise. These controls tend to break down in distributed environments with many unmanaged endpoints and inconsistent support processes because normal usage varies too widely to form a stable baseline.

Common Variations and Edge Cases

Tighter RMM governance often increases operational overhead, requiring organisations to balance support speed against investigative clarity. That tradeoff becomes visible when field teams, third-party providers, and emergency responders all need remote access under different conditions. Current guidance suggests separating these use cases rather than treating every remote tool as equivalent, because the detection logic for routine helpdesk access should not be the same as break-glass administration.

There is no universal standard for this yet, but best practice is evolving toward context-aware baselines that include identity, device posture, and network segment. For example, an RMM on an engineering workstation may be acceptable during a maintenance window, while the same activity on a domain controller should trigger escalation. The same issue appears in hybrid estates where cloud-hosted support tools, VPN access, and endpoint agents all create overlapping control paths.

RMM baselining also becomes harder when tooling is shared across internal IT and managed service providers. In those cases, ownership must be explicit or alerts will be dismissed as “known support traffic” long before a real compromise is recognised. Teams that want a broader operational view should align detection, inventory, and exception handling to the same control objective described in the CISA Known Exploited Vulnerabilities Catalog and related hardening guidance, because tool exposure and exploitability often move together.

Related resources from NHI Mgmt Group

• What breaks when session monitoring is missing from industrial remote access?
• What breaks when AML monitoring tools lack strong model governance?
• What breaks when organisations skip entitlement management and go straight to runtime tools?
• What breaks when identity and device management are split across tools?