{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/secure-rmm-remote-access-software/", "item": { "id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "slug": "secure-rmm-remote-access-software", "url": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software.md", "json": "https://update.dsesecurity.com/api/v1/posts/secure-rmm-remote-access-software/" }, "title": "Secure RMM and remote-access software before attackers use it", "summary": "Remote monitoring and access tools need explicit authorization, strong identity controls, restricted paths, independent logging, provider accountability, and tested containment.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 446, "potentially_affected": "Organizations, MSP customers, SaaS customers, IT administrators, service providers, and software teams that deploy or permit remote administration and support tools.", "dse_recommendation": "Inventory and allowlist tools, remove unauthorized access, harden approved paths, keep logs outside RMM control, define provider obligations, and exercise revocation and containment.", "primary_source": { "name": "CISA and partners: Guide to Securing Remote Access Software", "url": "https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software", "published_on": "2023-06-06", "authority": "Cybersecurity and Infrastructure Security Agency" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "
\n

Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.

\n\n

What the joint guide establishes

\n

Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.

\n

Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.

\n

The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.

\n\n

Establish an authorized remote-access inventory

\n

DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.

\n
    \n
  1. Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.
    2. \n
  2. Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.
    3. \n
  3. Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.
    4. \n
  4. Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.
    5. \n
  5. Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.
    6. \n
\n\n

Make the provider boundary explicit

\n

DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.

\n

Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.

\n\n

Applicability and limits

\n

The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.

\n\n

Official reference

\n

Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.

\n
", "content_text": "Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.\n\n What the joint guide establishes\n Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.\n Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.\n The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.\n\n Establish an authorized remote-access inventory\n DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.\n \n Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.\n Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.\n Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.\n Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.\n Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.\n \n\n Make the provider boundary explicit\n DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.\n Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.\n\n Applicability and limits\n The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.\n\n Official reference\n Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.", "content_markdown": "Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.\n\n## What the joint guide establishes\n\nSource fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.\n\nSource fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.\n\nThe agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.\n\n## Establish an authorized remote-access inventory\n\nDSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.\n\n- Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.\n\n- Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.\n\n- Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.\n\n- Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.\n\n- Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.\n\n## Make the provider boundary explicit\n\nDSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.\n\nExercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.\n\n## Applicability and limits\n\nThe guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.\n\n## Official reference\n\n[Guide to Securing Remote Access Software](https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software) — role-specific recommendations for organizations, customers, administrators, providers, and developers." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo.png" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "url": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-07-19" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Secure RMM and remote-access software before attackers use it", "item": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/#article", "identifier": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "url": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "headline": "Secure RMM and remote-access software before attackers use it", "description": "Remote monitoring and access tools need explicit authorization, strong identity controls, restricted paths, independent logging, provider…", "abstract": "Remote monitoring and access tools need explicit authorization, strong identity controls, restricted paths, independent logging, provider accountability, and tested containment.", "articleBody": "Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.\n\n What the joint guide establishes\n Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.\n Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.\n The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.\n\n Establish an authorized remote-access inventory\n DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.\n \n Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.\n Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.\n Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.\n Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.\n Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.\n \n\n Make the provider boundary explicit\n DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.\n Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.\n\n Applicability and limits\n The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.\n\n Official reference\n Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.", "datePublished": "2026-07-19T21:27:10+00:00", "dateModified": "2026-07-19T21:27:10+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@id": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": "https://update.dsesecurity.com/assets/dse-updates-share.png", "articleSection": [ "Cybersecurity", "IT", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "IT", "Networks & Infrastructure", "Checklist", "Advisory priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 446, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "CISA and partners: Guide to Securing Remote Access Software", "url": "https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software", "datePublished": "2023-06-06" } } ] } }