ConnectWise Breach Hits Nearly 1,000 Entra Tenants: Your RMM Is the Master Key — Treat It Like One

If you run an MSP or manage infrastructure for a living, the latest update on the ConnectWise breach is the kind of news that rearranges your week. Huntress has expanded its investigation and now sees suspicious sign-in activity — from an IP address tied to the ConnectWise breach — in nearly 1,000 Entra tenants, with more than 300 successful sign-ins. That is a sharp jump from the 162 tenants reported when the investigation first began.

One nuance matters, and the reporting says so directly: a successful sign-in does not automatically mean an attacker gained access in every one of those tenants. But 'probably fine' is not an answer you can give a client. 'Verified fine, here is the evidence' is.

And that is exactly where this stops being a security-industry headline and becomes an operations problem for every IT team and MSP: your RMM is the most privileged piece of software in your entire stack. When the vendor behind one of the industry's dominant remote management platforms is under investigation and the blast radius keeps growing, the question every team has to answer fast is: where is our exposure, and can we prove it?

The Problem in Depth

Your RMM is the highest-privilege software you own

Think about what your RMM actually does. It holds a persistent agent on every endpoint you manage. It can run scripts as SYSTEM. It can push files, open remote sessions, reboot machines, and install software across thousands of devices without anyone at the other end clicking anything. That is the entire point of an RMM — and it is also why the category keeps producing industry-wide incidents. Kaseya VSA in July 2021 turned one vendor compromise into ransomware across roughly 1,500 downstream businesses in a single weekend. ScreenConnect (ConnectWise Control) sits at the center of thousands of MSP stacks today.

When suspicious sign-ins linked to a vendor breach start appearing in Entra tenants — many of them MSP-managed — the math is brutal: one vendor problem multiplied by every client you serve.

What fragmented stacks do wrong when a vendor incident hits

Now put yourself in the chair of a lead tech at a mid-size MSP when news like this breaks. Your immediate checklist looks something like this:

1. Which of our clients run ConnectWise products directly?
2. Do we see suspicious sign-ins in any tenant we manage?
3. What remote-access software exists on every endpoint we manage — including the tools nobody told us about?
4. What have our own technicians touched recently, and can we prove it was legitimate?

In a typical stack — RMM from one vendor, monitoring from another, helpdesk from a third — every one of those answers lives in a different console. So you export an agent inventory from the RMM as a CSV, pull software inventories from the monitoring tool, walk through Entra sign-in logs tenant by tenant through the portal or Graph API, and try to reconcile device names that do not match across systems. The RMM knows about its own agent; it has no idea about the AnyDesk install an employee added in 2022. The monitoring tool polls SNMP and WMI but does not track remote-access software. The helpdesk has ticket notes but no machine-level action history.

That is how a scoping question turns into a multi-day spreadsheet-joining exercise.

Why these gaps exist

The fragmentation is not an accident — it is lineage. Monitoring platforms grew out of network management: SNMP polling, WMI queries, uptime graphs. RMM grew out of remote-access and screen-sharing tools. Helpdesk grew out of ticketing. Three product categories, three different vendors, three data models, and integrations that are usually overnight API sync jobs which break silently and quietly desync your device inventories.

Audit trails suffer the same fate. The RMM records its remote sessions. The helpdesk records tickets and notes. The monitoring tool records alerts. Nobody records the complete story — alert fired, script executed, remote session opened, ticket resolved — because that story crosses product boundaries.

The real impact on the team and the business

• Time-to-answer during a vendor incident: 6–10 technician hours per batch of clients just for scoping, before a single client notification goes out.
• SLA reporting collapses at the worst possible moment. The IT manager asks: did we respond to every affected client within 4 hours? The helpdesk clock started when someone manually created the ticket — 90 minutes after the alert fired in a different system. The report says yes; the truth is no.
• Technicians burn out on context-switching. The 2 a.m. page says 'Service down on host XYZ' with no context; the on-call tech logs into a separate RMM just to see what the machine is, then a third console to check recent changes.
• The actual risk window stays open. Every hour spent exporting CSVs is an hour not spent verifying and remediating.

How AlertMonitor Solves This

One agent, one inventory, one timeline

AlertMonitor was built on a different premise: monitoring, RMM, helpdesk, patching, and network topology belong in one platform, on one agent. That has a very concrete consequence during a vendor incident like this one — the inventory of everything you can remotely touch IS the inventory of everything you monitor. There is no reconciliation step between a monitoring console and a separate RMM, because there is no separate RMM.

Concretely:

• Script execution across device groups. Select a group — Client A servers, all Windows 11 workstations, every domain controller — pick a saved script, run it. Results land on the monitoring timeline, not in a transient console output you have to screenshot before it disappears.
• Remote sessions from the same console. Open a session directly from an alert, an inventory view, or a ticket. No tab-switching, no second credential set.
• Everything on one timeline. Automated remediations, manual technician sessions, script outputs, alerts, and ticket updates all attach to the same endpoint and client timeline. When a client asks what happened and what you did about it, the answer is one link, not three exports.
• Helpdesk in the same platform. The alert that started the incident, the script that scoped it, and the ticket that closed it share one data model — so SLA reporting is finally accurate, because nothing has to be stitched together after the fact.

Before and after

Practical Steps You Can Take Today

You cannot control your vendors' security posture. You can control how fast you answer 'are we affected?' — and how well documented that answer is. Here is a concrete sweep you can run this week.

1. Inventory remote-access software on every endpoint

The uncomfortable reality of RMM risk is that the RMM you know about is rarely the only remote-access tool on the box. Run this across your Windows fleet:

# Find installed remote-access software on this machine
$tools = @('ScreenConnect','ConnectWise','TeamViewer','AnyDesk','Splashtop','LogMeIn','RustDesk','TightVNC')
$paths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty -Path $paths -ErrorAction SilentlyContinue |
    Where-Object {
        $dn = $_.DisplayName
        $dn -and ($tools | Where-Object { $dn -like ('*' + $_ + '*') })
    } |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate

In AlertMonitor, save this to the Script Library and run it against a device group per client. The consolidated results are stored on each endpoint's timeline — so when a client asks, the answer is attached to the ticket, not buried in a technician's downloads folder.

2. Verify your remote-management services are actually healthy

An incident response that starts with 'is our own tooling even running?' is a bad start. Check it proactively:

# Check whether remote-management related services are running
$services = @('ScreenConnect Client Service','TeamViewer','AnyDesk Service','AlertMonitor Agent')
foreach ($svc in $services) {
    $s = Get-Service -DisplayName $svc -ErrorAction SilentlyContinue
    if ($s) {
        [PSCustomObject]@{
            Service   = $s.DisplayName
            Status    = $s.Status
            StartType = $s.StartType
        }
    }
}

On Linux endpoints, the equivalent check is one line:

systemctl list-units --type=service --state=running | grep -Ei 'ssh|vnc|anydesk|rustdesk|teamviewer'

3. Check patch age on critical servers

Remote-access software with known vulnerabilities is only tolerable if it gets patched fast. Measure how fast 'fast' actually is in your environment:

# Days since the most recent Windows update on this server
$last = Get-HotFix |
    Where-Object { $_.InstalledOn } |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 1

if ($last) {
    [PSCustomObject]@{
        HotFixID        = $last.HotFixID
        InstalledOn     = $last.InstalledOn
        DaysSinceUpdate = [int]((Get-Date) - $last.InstalledOn).TotalDays
    }
}

In AlertMonitor, script results like this feed directly back into monitoring data — a server sitting 60+ days without patches is not a spreadsheet row, it is a visible, alertable condition on the same timeline as everything else about that machine. And when you decide to act, patch management lives in the same platform: schedule the update, watch the result, close the ticket.

4. Reduce your remote-access surface

Every additional screen-sharing tool is another master key that nobody inventoried. When the sweep from step 1 comes back, act on it: uninstall tools nobody claims, standardize on a single managed platform, and document the exceptions per client. Fewer privileged channels means a smaller blast radius the next time a vendor makes the news — and there will be a next time.

The Bottom Line

The numbers in this incident will keep moving — 162 tenants became nearly 1,000, and the 300+ successful sign-ins will take weeks to verify one by one. That verification work is exactly the kind of job that separates teams running one unified platform from teams running four.

When the next vendor incident hits, the IT teams that answer 'are we affected?' in an hour instead of a week will be the ones whose monitoring, RMM, helpdesk, and patching already share one inventory, one timeline, and one console.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources