There is a category of software that is installed on virtually every managed endpoint in an enterprise, runs with administrative privileges, has authenticated network access to every machine it manages, is specifically designed to be operated remotely from outside the organisation’s network, and is trusted by default in most endpoint detection configurations.
That software category is remote monitoring and management tools. SimpleHelp, AnyDesk, ConnectWise ScreenConnect, N-able, Kaseya, TeamViewer — pick your vendor. The category’s defining properties are also precisely the properties that make it the most attractive attack surface in the enterprise.
The Trust Problem Is By Design
RMM tools are trusted because they need to be. An IT support analyst connecting to a remote employee’s laptop during a support session needs to be able to run as administrator. A patch management agent needs to execute software installation. A remote monitoring daemon needs to enumerate running processes. These capabilities are not accidents — they are the entire value proposition.
The problem is that “trusted by endpoint security” means EDR products, AV, and SIEM platforms have been tuned to suppress alerts on RMM tool activity. That’s necessary to prevent every legitimate support session from generating a tier-1 incident ticket. But it also means that when an attacker creates a rogue SimpleHelp technician account via an authentication bypass and uses it to connect to corporate endpoints, the activity looks identical to legitimate IT support work from the perspective of every monitoring tool that has been trained to ignore it.
The SimpleHelp OIDC flaw disclosed today is the fourth new RMM-class vulnerability disclosed in 2026, following ConnectWise ScreenConnect (February, mass exploitation within 48 hours), AnyDesk (March, supply chain credential compromise), and a Kaseya VSA authentication bypass in May. CISA published guidance in 2024 on threat actors using legitimate RMM software as remote access tools, documenting that multiple nation-state and cybercriminal actors had adopted the technique systematically. The guidance was necessary because the technique was working — and working consistently enough to warrant a joint advisory from CISA, NSA, and MS-ISAC.
The Structural Failure Is Visibility, Not Patching
The instinctive response to each new RMM vulnerability is to patch the affected product and move on. That response is necessary but insufficient, because the underlying problem is not that SimpleHelp has a bug this week. It is that most organisations have no operational visibility into what their RMM tools are actually doing on a day-to-day basis.
Ask the security team at a typical mid-sized enterprise: how many remote sessions occurred via your RMM platform last Tuesday? Which endpoints were accessed? Which technician accounts initiated those sessions? Were any initiated from IP addresses outside your IT team’s normal working locations? For most organisations, these questions cannot be answered without a dedicated log analysis exercise — which means they cannot be answered in real time, and certainly cannot be answered in the first hours of an incident.
This is not a logging failure. Most RMM platforms log this data. The failure is that RMM session logs are not being ingested into the SIEM, not being correlated against technician identity, and not being baselined to detect anomalous patterns. The same organisation that has meticulous Active Directory logon monitoring will have zero SIEM rules for “remote support session initiated to domain controller outside business hours from an account created in the last 24 hours.”
What Effective RMM Monitoring Looks Like
The controls that actually work for RMM security are operational, not just architectural. They include:
Ingesting RMM session logs into the SIEM with meaningful context. This means source IP, destination endpoint, technician account name, session duration, and whether files were transferred or commands executed. Most platforms expose this via API or syslog — the integration work is non-trivial but tractable.
Alerting on account creation events in RMM platforms. The SimpleHelp attack, the ConnectWise attack, and the Kaseya attack all involved the creation of rogue accounts. If your SIEM is alerting on new account creation in Active Directory, it should be alerting on new account creation in your RMM platform. These are equivalent privileges in practice.
Baselining “normal” RMM activity. Which endpoints receive support sessions most frequently? During which hours? From which technician accounts? What geographic regions do the source IPs resolve to? Deviation from baseline is a detection signal that doesn’t require knowing what the attack looks like in advance.
Requiring MFA on RMM technician accounts from external networks. This is table-stakes that many organisations have not implemented, partly because the onboarding friction for support staff is real and partly because MFA for RMM platforms is sometimes a paid tier feature.
The Vendor Market Reality
The harder truth is that the RMM vendor market has not yet internalised the security responsibility that comes with shipping a product that runs with administrative privileges on every managed endpoint. Security posture varies wildly between vendors. Some products ship with MFA optional and disabled by default, weak default credentials for the server management interface, and no logging of session commands.
Enterprises selecting RMM vendors — or evaluating renewals — should be asking for the security posture information that other enterprise software categories already provide as standard: a current SOC 2 Type II report, CVE history with patch cadence, MFA requirements, session logging capabilities, and penetration test summaries. An RMM vendor that declines to provide this information is providing a de facto answer.
The Simon Hullard quote attributed to the 2024 CISA RMM advisory has been cited frequently because it remains accurate: threat actors using RMM software “do not need to develop their own malware or exploit vulnerabilities if they can use legitimate tools that already exist in the environment.” Every organisation that treats its RMM platform as a transparent, always-trusted tool rather than a privileged access system requiring the same scrutiny as a domain controller is offering attackers that convenience.
The SimpleHelp patch ships today. The visibility and monitoring programme needs to start shipping too.
Share this article