Who is allowed to remote into your network?

Remote monitoring and management (RMM) software lets an IT provider or internal team reach a device to patch it, troubleshoot it, or pull a file. It is normal, useful, and present on most business networks. The question worth asking is not whether RMM software is in use, but which specific tools are authorized, who approved each one, and what would stop an unapproved one from running.

CISA, the NSA, and MS-ISAC issued a joint advisory in 2023 on the malicious use of legitimate RMM software, warning that attackers had been observed downloading and running tools like ScreenConnect and AnyDesk to gain remote access without needing to write custom malware. CISA’s advisory recommends organizations “implement application controls to manage and control execution of software, including allowlisting RMM programs,” and states that “application controls should prevent both installation and execution of portable versions of unauthorized RMM software.” A follow-on guide from CISA, the NSA, the FBI, MS-ISAC, and Israel’s INCD repeats the recommendation and adds that organizations should audit remote access software on their networks “to identify currently used and/or authorized RMM software” and block RMM ports and protocols at the network perimeter for anything not authorized. These are standing recommendations from federal cybersecurity agencies, not a claim that any particular reader has been targeted.

Current events illustrate why the guidance holds up rather than proving any one reader is exposed. CISA added a ConnectWise ScreenConnect vulnerability, CVE-2026-84869, to its Known Exploited Vulnerabilities catalog on September 11, 2026, after confirming active exploitation. A vulnerability in one widely deployed RMM product is a reason to know which RMM tools are running in your environment and to have a way to react quickly when one of them needs an emergency patch, not evidence that this specific product is the risk to focus on.

The gap is not having a tool, it is not knowing the list

An organization rarely chose to run every RMM tool present on its network. A provider installs one to do their job. A past vendor leaves one behind. A trial goes unremoved. Each addition is reasonable on its own. The result, unmanaged, is a set of tools with remote access to your systems that nobody currently owns, reviews, or can name in full.

An allowlist reverses that default. Instead of asking “is this RMM tool bad,” it asks “is this RMM tool on the approved list, and if not, why does it have access.” The second question is answerable with a record. The first usually is not, without already knowing what you are looking for.

Default-deny changes what happens when you are wrong

An allowlist without enforcement is a document. Application control that defaults to deny means software not on the list does not run at all, including a new RMM tool an attacker installs. This does not require knowing that a specific tool is malicious in advance. It only requires knowing what is supposed to be there.

The tradeoff is real: a default-deny policy needs upkeep as legitimate software changes, and a poorly maintained list can block work that should be allowed. That operational cost is a reason to scope the policy to what your organization can actually maintain, not a reason to skip the inventory question underneath it.

A short inventory, not a new platform

Building this does not require new software. It requires answers your provider should already be able to produce:

• Which RMM tools currently have access to any device on your network?
• Who approved each one, and when?
• Is each one still in active, expected use, or left over from a past engagement?
• What would happen if an unapproved remote-access tool were installed today, would anything block or flag it?

If the honest answer to the last question is “we would not know,” that is the gap to close before evaluating any specific product or vulnerability.

Bring the inventory to a provider conversation

Our five questions to ask your IT provider covers ongoing provider accountability more broadly; this is the version specific to remote access. Ask for the current list of authorized remote-access tools, not a description of the provider’s general practices. Ask what happens when the list changes; add a tool, and who signs off; remove one, and who confirms it is fully gone, not just uninstalled from the machines someone remembered to check.

This is not a recommendation for a specific product or vendor change. It is a recommendation to be able to answer, in writing, which tools are allowed to remote into your network and what stops the rest.