Remote monitoring and management (RMM) software is among the most trusted — and most attacked — tools in the managed services stack. For small and mid-sized businesses with no in-house IT team, the MSP's RMM console is not merely a support tool: it is effectively the entire security perimeter. That single fact turns the security posture of an RMM platform into a board-level concern for every provider touching client infrastructure.
Vendor Acronis has now codified the problem, publishing a framework of eight security controls that MSPs should actively test when evaluating or reviewing an RMM product — converting what is usually a marketing conversation into an evidence-gathering exercise, BleepingComputer reported on 6 October.
The stakes are not theoretical. RMM platforms hold privileged, far-reaching access to customer endpoints, networks and cloud environments, often under a single management plane. Compromise that console and the blast radius is not one client — it is every client the console can reach. That is precisely what happened in the Kaseya VSA incident of July 2021, when a supply-chain compromise of an RMM platform rippled through hundreds of downstream businesses via managed service providers that had deployed it. The precedent stands: RMM is a recognised entry point for attackers targeting the managed services channel, and the controls that gate that channel matter.
The eight controls, grouped into three phases
Acronis frames the checklist around the lifecycle of a security failure — prevention, containment and recovery.
Prevention: stop the compromise before it starts
- Patch management. Does the platform itself receive security updates promptly, and can MSPs enforce patching across tenants on a defined schedule? A product that ships updates slowly, or that leaves agents unmanaged by default, is a liability.
- Privileged access controls. The console holds near-administrative rights everywhere it reaches. Test whether the vendor enforces multi-factor authentication on technician accounts, and whether privilege can be scoped and time-limited rather than all-or-nothing.
- Tenant isolation. Treat this as non-negotiable. Deliberately attempt to reach one client's environment from an account scoped to a different client. If that test succeeds, the platform has an architectural problem — and no compensating controls elsewhere will fully offset a cross-tenant cascade.
Containment: limit what happens after an intrusion
- Logging and monitoring. Can the MSP see who did what, where and when — across every tenant — and receive alerts to anomalous administrative activity?
- Endpoint detection integration. An RMM agent that cannot see or act on malware telemetry leaves providers blind at exactly the moment visibility matters most.
Recovery: get clients back online
- Backup and restore. Test restoration, not just backup. Platforms should support immutable or isolated backups of the management plane itself, not only endpoints.
- Incident response support. When things go wrong, does the vendor provide clear guidance, forensic data and a reachable response process?
- Configuration hardening. Review default settings, administrative templates and deployment baselines — vendor defaults are often far more permissive than the environments they are deployed into.
Why this matters to service providers
The guidance carries weight for MSPs operating across multiple client tenancies, particularly where providers manage everything from endpoints to cloud infrastructure for small businesses that have no security team of their own. The underlying logic applies wherever one console can reach many customers' environments — a pattern familiar to managed services markets worldwide.
The uncomfortable truth underpinning Acronis' framework is the one MSPs already live with: the concentrated privilege that makes RMM software valuable is the same privilege that makes it dangerous. The right controls reduce that risk — they never eliminate it. Testing them properly, and disqualifying vendors that fail the critical ones, is now basic due diligence.
遠端監控及管理（Remote Monitoring and Management，RMM）軟件是 managed services 運作架構中最受信任——同時亦是最常被攻擊——的工具之一。對於沒有內部 IT 團隊的中小企業而言，MSP 的 RMM 主控台不單是支援工具：它事實上就是整個安全防線。單是這一點，已令 RMM 平台的安全狀態成為每個接觸客戶基礎設施的服務供應商必須向管理層層級交代的議題。
供應商 Acronis 現已將此問題系統化，發布八項 MSPs 在評估或覆核 RMM 產品時應主動測試的安全控制措施——把慣常流於市場推廣的對話，轉化為蒐集證據的過程。BleepingComputer 於 10 月 6 日報道。
風險並非純屬理論層面。RMM 平台對客戶終端、網絡及雲端環境擁有廣泛而具特權的存取權限，通常集中於單一管理平面上。一旦該主控台被攻陷，爆炸半徑便不止於單一客戶——而是主控台所能接觸的每一個客戶。2021 年 7 月的 Kaseya VSA 事件正是如此：某 RMM 平台遭到 supply chain 攻擊，透過已部署該平台的 managed service providers 擴散至數百家下游客戶企業。此先例殷鑑不遠：RMM 已被公認為攻擊者入侵 managed services 渠道的入口，而把關該渠道的控制措施至關重要。
八項控制措施，分屬三個階段
Acronis 以安全失效的全生命周期來組織這份清單——預防、遏制及復原。
預防：在失陷開始前予以阻止
- Patch management。 平台本身是否能及時收到安全更新？MSPs 能否強制在既定時間表內為所有 tenant 打 patch？更新推出緩慢、或預設下 agent 不受管理的產品，本身就是一項負債。
- 特權存取控制。 主控台在其所及之處幾乎擁有近乎管理員的權限。測試供應商是否對技術人員帳戶強制實施 multi-factor authentication，以及特權能否按範圍限定及設置時限，而非非黑即白。
- Tenant isolation。 此項目不容妥協。刻意嘗試從一個限定於其他客戶的帳戶，接觸某客戶的環境。若測試成功，即顯示平台存在架構問題——而其他地方的補償性控制措施，無法完全抵銷跨 tenant 級聯失效的風險。
遏制：限制失陷後的影響範圍
- 記錄及監控。 MSPs 能否掌握誰、在何處、何時做了什麼——涵蓋所有 tenant——並就異常管理活動收到警報？
- Endpoint detection 整合。 無法讀取或處理惡意軟件 telemetry 的 RMM agent，會令服務供應商在最需要掌握情況的時刻完全失明。
復原：令客戶重新上線
- 備份及還原。 測試還原功能，而不只是備份功能。平台應支援管理平面本身的不可變（immutable）或隔離備份，而不單是終端備份。
- 事件應變支援。 當情況出錯時，供應商是否會提供清晰指引、取證數據及可接觸的應變流程？
- 配置強化。 檢視預設設定、管理模板及部署基線——供應商的預設設定，往往比實際部署環境寬鬆得多。
這對服務供應商為何重要
此指引對營運多個客戶 tenant 的 MSPs 具有實際意義，尤其是當供應商為本身沒有安全團隊的小型企業，管理由終端至雲端基礎設施的各項事務時。其背後的邏輯同樣適用於任何單一主控台可接觸多個客戶環境的情況——此模式在各地 managed services 市場均屬常見。
Acronis 框架背後的尷尬真相，正是 MSPs 已經習以為常的一點：令 RMM 軟件具有價值的集中式特權，正是令它危險的同一特權。適當的控制措施能降低該風險——但從來不能消除它。認真測試這些控制措施，並剔除未能通過關鍵測試的供應商，現已是最基本的 due diligence。