Your RMM tool isn't just a convenience — it's a skeleton key to every machine you manage. And right now, attackers know it.
Two threads have been making the rounds in small business IT communities lately. The first: Microsoft Defender for Cloud flagging ScreenConnect agents as 'Pomal' malware — a false positive that sent admins scrambling to figure out whether their remote access tool had been trojanized or whether their EDR had gone haywire. The second: a heated discussion about NinjaOne's agent model and a pointed question nobody had a clean answer to — what actually stops a third party from pushing scripts to your client machines through your RMM?
These aren't paranoid edge cases. They're the right questions to be asking. And recent events prove it.
RMM Tools Are Now a Primary Attack Vector
According to The Hacker News, a critical vulnerability in N-able's N-central platform allowed attackers to reach managed systems and establish persistence — actively exploited in the wild as of August 2026. This wasn't a theoretical risk. Attackers compromised the RMM layer and used it to fan out across every endpoint under management. That's the nightmare scenario: one breach point, unlimited lateral movement.
The supply-chain angle is just as dangerous. According to The Hacker News, threat actors exploited flaws in TrueConf Server to replace legitimate client installers with PhantomCore malware — meaning users who thought they were downloading a trusted collaboration tool were actually installing a backdoor. The ScreenConnect false-positive scare fits this exact pattern: remote access tools are high-value trojanization targets precisely because they're trusted, privileged, and installed on every machine you manage.
With that context established, let's look at what actually separates these three platforms from a security architecture standpoint.
ScreenConnect (ConnectWise Control)
Access model: Session-based, with granular permission tiers. Admins can restrict technicians to specific machine groups, require session approval from the end user, and enforce MFA on the admin console.
Self-hosted option: Yes — and this is significant. Running your own ScreenConnect instance means you control the server, the authentication layer, and the update cadence. You're not sharing infrastructure with thousands of other MSPs.
Known risks: The Defender false-positive incident is worth understanding correctly. The flagging wasn't evidence of a real compromise — it was Defender's heuristics misfiring on a legitimate agent. But it illustrates a real problem: ScreenConnect's agent looks a lot like malware to behavioral engines because it behaves like malware (remote shell access, file transfer, persistence). That's not a ScreenConnect failure; it's a category-level risk for all RMM agents.
Verdict: Strong choice for security-conscious shops willing to self-host. The self-hosted model eliminates shared-infrastructure risk. Requires disciplined patch management on your end — which, if you're reading this post, you should already have. We've covered what happens when that discipline breaks down in our RMM security risk guide on the N-central vulnerability.
NinjaOne
Access model: Role-based access control (RBAC) with organization-level segmentation. Technicians can be scoped to specific client organizations. Script execution requires explicit role permissions.
Self-hosted option: No. NinjaOne is cloud-only, which means you're trusting their infrastructure, their access controls, and their vendor security posture.
Known risks: The Reddit concern about third-party script execution is legitimate and not unique to NinjaOne — it applies to every cloud-hosted RMM. The question is: if NinjaOne's platform is compromised (or a rogue employee abuses access), what prevents mass script execution across all managed endpoints? The answer is: NinjaOne's internal controls, their SOC 2 compliance posture, and your RBAC configuration. That's not nothing, but it's also not the same as controlling your own server.
Verdict: Excellent operational tooling, strong RBAC when configured correctly, but the cloud-only model means your blast radius in a platform-level breach is every client simultaneously. For MSPs managing government contractors or handling sensitive data, that's a risk worth pricing carefully.
TeamViewer
Access model: Persistent agent with account-based authentication. Access is tied to TeamViewer accounts, not session approval — meaning if an account is compromised, access is immediate and persistent.
Self-hosted option: Partially — TeamViewer Tensor offers on-premises options for enterprise, but the SMB-tier product is cloud-dependent.
Known risks: TeamViewer has the longest breach history of the three. The 2016 credential stuffing incident, the 2024 corporate network breach attributed to APT29, and ongoing abuse of TeamViewer by ransomware operators as a legitimate-tool-turned-attack-vector make it the most scrutinized platform in this category. It remains widely deployed because it's familiar — not because it's the most secure option.
Verdict: Acceptable for break-fix support with session-based access and strong account MFA. Not recommended as a persistent agent in environments handling sensitive data or operating under compliance frameworks like CMMC.
The Decision Framework
Before you deploy any RMM agent, answer these four questions:
- Who can authorize script execution, and how is that logged? If you can't answer this immediately, your RBAC isn't configured correctly.
- What happens if the vendor's platform is breached? Cloud-only tools inherit your vendor's security posture. Self-hosted tools inherit your own.
- How does your EDR handle the agent? If Defender or your chosen endpoint solution flags it, you need a documented exclusion policy — not a suppressed alert.
- Can you revoke access instantly? Persistent agents with account-based auth are harder to kill than session-based tools. Know your kill switch before you need it.
If your RMM is ever compromised, having a documented response plan is non-negotiable. Our RMM tool hacked emergency playbook walks through exactly what to do in the first 60 minutes.
The Uncomfortable Truth
No RMM tool is inherently safe. ScreenConnect, NinjaOne, and TeamViewer are all legitimate tools that attackers have learned to abuse, trojanize, or exploit at the platform level. The N-able breach didn't happen because N-central was a bad product — it happened because attackers follow the path of maximum leverage, and RMM platforms offer exactly that.
The safest RMM deployment is the one with the smallest blast radius: scoped permissions, MFA enforced everywhere, session logging enabled, and continuous visibility into what's running on your endpoints.
Take Action
Before your next RMM deployment — or your next renewal decision — make sure you know what's exposed. Attackers aren't waiting for you to finish your evaluation.
Oscar Six Security's Radar ($99/scan) gives small business IT teams and MSPs continuous vulnerability visibility across their environment — so you can see what your RMM agents are exposing before an attacker does. It's not a replacement for good access controls, but it's the early warning system that catches drift before it becomes an incident.
Focus Forward. We've Got Your Six.