Approving a remote support product does not establish who is authorized to use it on your computers. A legitimate application can connect a device to an unauthorized operator. A useful approval therefore identifies the software, the organization or account controlling it, the covered devices, and the work that access permits.
For IT directors and MSPs, this is a practical distinction when reviewing an unfamiliar support session or a newly discovered remote management tool. The question is whether this particular access belongs to your approved support arrangement.
Why the product name is incomplete evidence
Remote monitoring and management, or RMM, software helps administrators maintain devices and provide support. Those capabilities also make it useful to attackers. MITRE ATT&CK describes adversaries using legitimate desktop support software to control systems, including software that application control may already allow.
A real product name, familiar icon, or successful malware scan cannot identify the person controlling the other end. Even finding the same product in your approved-software inventory leaves an important question: does this instance connect to the management service your organization authorized?
The CISA, NSA, and MS-ISAC advisory on malicious RMM use, revised January 26, 2023, describes legitimate remote-access programs configured to connect to an attacker's server. That historical example illustrates a continuing control question; it is not a claim that your organization is affected by that campaign.
Define the approved support relationship
Our recommendation is to keep a short approval record that connects each support deployment to its business owner. Record the authorized provider or internal team, the relevant management account or server, the devices it may reach, and the functions it may perform. Identify who can approve changes and who can terminate access.
Make unattended access explicit. A one-time troubleshooting session and an agent that remains available for future administration create different operating commitments. Agree on the applicable duration, administrative privileges, and review date. Where the product supports a tenant or organization identifier, record it and establish how administrators will verify it.
This applies the distinction in NIST's Zero Trust Architecture: authentication and authorization are separate functions performed before access to a resource is established. Recognizing the software does not complete either decision for its remote operator.
A support request puts the distinction to work
Consider a hypothetical employee who receives a message asking them to run a familiar remote support application to resolve an urgent problem. The company uses that product, but the message supplies a new download link and directs the employee to an unfamiliar support session.
The employee should use the established help-desk channel to verify the request before proceeding. The help desk can check whether the request corresponds to an authorized ticket and whether the proposed connection belongs to its approved service. The product's familiarity is useful context, but the support relationship still needs verification.
If the employee has already granted access, capture what they can safely report: the request, time, device, session details, and actions observed. Escalate through the incident process. Avoid treating an unexpected tool as automatically harmless or deleting it before responders have considered the evidence and containment needs. This is a planning example, not a customer incident.
Check execution and delegated trust
An installed-software list can miss activity. The CISA advisory describes portable remote-access executables that ran in a user's context without a full installation or administrator privileges. It recommends reviewing execution evidence and applying controls to unauthorized portable versions as well as installers.
NIST's application allowlisting guidance explains how execution controls restrict which applications and components may run. Apply that decision deliberately to support tools. Ask what an approval actually covers and how policy changes are reviewed.
Also examine what a trusted management tool may launch. Network Box USA's WhiteCloud service page lists automatic trust of child processes launched by approved RMM tools among its capabilities. Discuss how that capability is configured in your deployment, which tools receive that trust, and how their administration is protected. The published capability does not establish a particular customer's settings or prove that a remote session is authorized.
Give monitoring the approval context
Provide responders with the approved deployment record so they can evaluate unexpected execution, a new controlling service, or an unexplained support session. Agree which endpoint, management-console, and connection records are available. If those records cannot identify the operator or controlling account, document that visibility gap.
Network Box USA's NBX Managed Detection and Response combines monitoring, investigation, escalation, and response guidance within the agreed service scope. Contact our team to discuss how application approval, remote-support ownership, and monitoring evidence fit together in your environment.