A remote monitoring and management (RMM) platform gives whoever controls its console the power to run code on every managed device, so an RMM rollout is the deployment of a fleet-wide privileged channel, not just an IT tooling project. This playbook covers introducing an RMM platform as a product class: requirements and architecture decisions, securing the console before the first agent is enrolled, deploying agents in rings, turning on patching, scripting and remote control, integrations, go-live with rollback, and what to measure afterwards. It is vendor-neutral and based on the joint CISA, NSA, FBI, MS-ISAC and INCD Guide to Securing Remote Access Software, CISA advisory AA23-025A, NIST SP 800-40 Rev. 4 and NIST SP 800-53. It is written for IT operations leads, endpoint engineers and security architects, in-house or at a managed service provider. Governing RMM use and blocking unapproved tools is covered in the RMM Tool Security Guide; product selection is in the RMM Tool Buyer's Guide.
Key takeaways
- Secure the console before the first agent. SSO, phishing-resistant MFA, roles and log forwarding must be live before any device trusts the platform, because every enrolled agent extends the console's reach.
- Design roles around read-only by default. The joint guide recommends "reduced privilege" RMM use for common tasks such as monitoring; script execution and remote control belong to a small, named group.
- Put guardrails on fleet-wide actions. Script approval, scoped targets and re-verification when one account pushes commands to 10 or more devices in an hour turn a single stolen session from a fleet wipe into an alert.
- Deploy agents and patch policies in rings. NIST SP 800-40 Rev. 4 maintenance groups and canary rollouts apply to the agent itself as much as to the patches it delivers.
- Make the approved tool the only tool. Rollout is the moment to allowlist the chosen agent by its tenant and block other remote access software, or the new platform becomes one more channel among many.
Phase 0: requirements and architecture decisions
Settle these decisions before procurement closes. Each changes the attack surface you will operate for years.
| Decision | Options | Security consequence |
|---|---|---|
| Hosting model | Vendor-hosted SaaS console, or self-hosted server | SaaS moves patching of the console to the provider; self-hosted puts an internet-reachable management server and its patch cycle on you. The joint guide asks for internet-facing remote access servers to be patched first. |
| Agent connectivity | Outbound-only agent connections to the console, or inbound listeners on endpoints | Prefer outbound-only on TCP 443 with no listening port on endpoints; document the console domains so they can be allowlisted and everything else blocked. |
| Remote control path | Built-in remote control, approved channel only (VPN or VDI), or a separate remote support tool | AA23-025A recommends authorised RMM be used only over approved channels such as VPNs or virtual desktop interfaces; decide which device groups need direct control at all. |
| Operator model | In-house team, MSP, or both | MSP access is third-party privileged access; contracts must define logging, notification and responsibilities (see Phase 6). |
| Scope | Workstations, servers, network devices, OT-adjacent systems | Keep domain controllers, identity providers, backup servers and log servers out of the general RMM tenant or in a separately administered tier. |
Also record who owns the platform, which change board approves fleet-wide scripts and which assets are excluded and why. The CISA guide's advice to keep log servers, and the ability to delete or alter logs, out of reach of RMM tools is easiest to honour if it is an architecture decision on day one rather than a later exclusion.
Phase 1: securing the console and tenant
- Identity: integrate the console with the workforce identity provider through SAML or OpenID Connect, require phishing-resistant MFA (CIS Safeguards 5.4 and 6.5) and disable local console accounts except one break-glass account held in the PAM vault. See the Privileged Access Management Guide.
- Roles: build at least four roles before inviting users: read-only monitoring, service desk (view and approved remote session), engineer (patch and software policy, approved scripts) and platform administrator (roles, integrations, tenant settings). Map them to identity provider groups so joiners and leavers flow automatically.
- Device scoping: organise devices into sites or groups that match maintenance groups and business units, and grant technicians rights to their groups only. A service desk role should not reach servers.
- Mass action safeguards: enable whatever the platform offers for approval workflows, script signing, target-count limits or step-up authentication on bulk actions. The joint guide recommends re-triggering verification, such as MFA, when an account tries to "push commands to 10 or more devices within an hour".
- Audit logging: forward console audit events (logins, role and policy changes, script runs with content, remote sessions, agent enrolments and removals) to the SIEM before go-live, and test that a script run appears there.
- Configuration baseline: export tenant settings, record them as the approved baseline and track changes under change control (NIST SP 800-53 CM-3 and CM-6).
Hardening detail for the platform itself is in Securing the remote monitoring and management (RMM) tool itself; this playbook covers what to switch on and in what order.
Phase 2: agent deployment in rings
NIST SP 800-40 Rev. 4 organises assets into maintenance groups with shared needs (schedule, testing, outage limits, impact if compromised) and recommends phased rollouts that start with canary assets. Use the same groups for agent deployment, then reuse them for patching.
| Ring | Typical members | Exit criteria before the next ring |
|---|---|---|
| 0: lab | Test virtual machines of each OS build | Agent installs silently, survives reboot, reports inventory, can be removed cleanly |
| 1: IT pilot | IT and security staff devices, 1 to 5 percent of fleet | No conflicts with endpoint detection and response, application control or VPN; audit events reach the SIEM |
| 2: early adopters | Volunteer users across business units and sites | Help desk ticket rate stable; bandwidth at small sites acceptable |
| 3: general workstations | Remaining user devices in waves | Enrolment coverage target met; orphan and duplicate records resolved |
| 4: servers | Non-critical servers, then critical servers per maintenance window | Server owners sign off on remote control and script rights |
- Enrolment secrets: agent installers usually embed a tenant or site enrolment key. Scope keys per site, store them in the deployment tool rather than in shared folders, and rotate them after the rollout ends so a leaked installer cannot enrol attacker devices into your tenant or your devices into theirs.
- Deployment method: push the agent with your existing endpoint management or group policy tooling, signed and hash-checked. Avoid emailing download links to users, the same pattern attackers use in the help desk phishing campaign CISA describes in AA23-025A.
- Endpoint security alignment: add the agent to application control and EDR policy by publisher signature and path. Do not create broad folder exclusions to silence alerts; that is a gift to anyone who later drops a tool alongside it.
- Rollback: keep a tested uninstall package and a way to run it outside the RMM itself, through endpoint management or group policy, in case the platform must be pulled.
Phase 3: patching, scripting and remote control
Turn on capabilities one at a time, each in audit or report-only mode first.
- Inventory and monitoring: enable hardware and software inventory and health monitoring first. It is low risk and gives the asset data needed for CIS Safeguards 1.1 and 2.1.
- Patch policy in report mode: scan and report missing patches per maintenance group for two cycles before approving any deployment. Compare results with your vulnerability scanner.
- Routine patching: follow SP 800-40 Rev. 4: canary assets first, then wider rounds, with a grace period after which installation is forced. Write an emergency patching plan on the same groups at a faster schedule (the publication suggests a canary test of minutes to hours, then deployment in hours or days).
- Script library: start with a reviewed library of vetted scripts owned by named engineers. Require peer review and, where supported, signing for new scripts; block ad hoc scripts against more than a small target set.
- Remote control last: enable interactive sessions only for the roles and device groups that need them, with end-user consent prompts and an on-screen indicator on user devices, and session recording where the platform supports it.
The vulnerability and patch process around the tool is covered in the Patch Management Guide.
Phase 4: making the approved tool the only remote access channel
An RMM rollout that leaves legacy remote access tools in place adds risk rather than replacing it. CISA AA23-025A recommends inventorying remote access tools, using application control to prevent installation and execution of unauthorised RMM software including portable versions, and blocking common RMM ports and protocols at the perimeter. In rollout order:
- Inventory remote access software seen on endpoints and in DNS and proxy logs over at least the last 90 days.
- Allowlist the approved agent by publisher and, where the product supports it, restrict it to your tenant's domains at the proxy or DNS layer, so the same signed agent enrolled to another tenant is blocked.
- Run application control rules for other remote access tools in audit mode for two to four weeks (NHI Mgmt Group recommendation), contacting the owner of each tool that would be blocked.
- Enforce in the same rings as agent deployment; roll a ring back by returning its policy to audit.
- Decommission legacy agents and revoke their console accounts and API keys.
Detection content for unapproved tools is in Detecting RustDesk, MeshCentral and Tactical RMM Abuse and the response steps in the Unauthorised Remote Monitoring and Management Tool Playbook.
Phase 5: integrations and the identities behind them
RMM platforms connect to ticketing and professional services automation, documentation tools, backup consoles and SIEM. Each integration is a non-human identity that can often read device data or trigger actions across the fleet.
- API credentials: one credential per integration, scoped to the minimum (read-only where the integration only reads), with an owner, a vault location and a rotation date. See the Remote monitoring and management (RMM) tool integration security guide.
- Agent service context: agents usually run as SYSTEM or root. Do not add separate domain admin credentials to the platform's credential store for convenience; if credentials must be stored for tasks, use the narrowest account per maintenance group and never reuse administrator credentials across customers or tiers, as the joint guide warns.
- Inbound webhooks and alerts: authenticate them and treat payloads as untrusted input to downstream automation.
Phase 6: go-live, MSP terms and rollback
- Tabletop before go-live: rehearse a hijacked technician account running a script across all devices. The Stryker cyberattack showed a single hijacked admin account in a device management platform wiping tens of thousands of devices; confirm which safeguard in your design would stop or slow that.
- MSP operation: where an MSP runs the platform, the CISA guide says contracts should detail how and when providers notify the customer of an incident, require security event monitoring and visibility into the provider's activity, and make clear which services are and are not included. See the Compromised MSP Playbook.
- Rollback triggers: define them in advance: agent instability above an agreed crash or CPU threshold, conflicts with EDR, or a platform vulnerability with no patch. Rollback means uninstalling through the out-of-band method from Phase 2 and restoring the previous remote support path for the affected ring only.
- Handover to operations: access reviews, script library ownership and patch reporting move into the Remote monitoring and management (RMM) tool day-2 operations runbook.
Decision guidance
- SaaS or self-hosted: choose SaaS unless data residency or air-gapped networks require otherwise; a self-hosted server must sit behind a VPN or identity-aware proxy and be patched on an emergency cycle.
- RMM remote control or separate remote support: one tool is easier to allowlist and monitor; a separate tool can make sense if it gives stronger consent and recording controls for user devices. Do not run both without blocking everything else.
- Small organisations usually receive RMM from an MSP: focus on MFA on the provider's console, contract terms, a named list of provider technicians and egress blocking of other RMM domains. See Choosing an IT Support Provider or MSP Securely.
- Large organisations should tier the platform: a separate tenant or instance, or none at all, for tier 0 assets, and regional device groups with their own technician groups.
Detection and measurement
Watch console audit events for logins from new locations, role changes, new API keys, scripts outside the library, scripts targeting large device counts, agent enrolments to unexpected sites and bulk uninstalls. On endpoints, watch for remote access software not on the allowlist and for the approved agent contacting domains other than your tenant's. Abuse of these platforms maps to ATT&CK T1219 Remote Access Tools and T1072 Software Deployment Tools, and MSP access to T1199 Trusted Relationship.
| Metric | Target or use |
|---|---|
| Agent enrolment coverage | Managed devices with a healthy agent as a share of the asset inventory, per ring |
| Patch compliance by deadline | Share of assets patched within their maintenance plan deadline, split by vulnerability and asset importance as in SP 800-40 Rev. 4 |
| Mean and median time to patch | Tracked separately for routine and emergency plans |
| Bulk actions with recorded approval | Scripts against 10 or more devices with an approval record; target 100 percent |
| Technician accounts with phishing-resistant MFA | Target 100 percent; local accounts limited to break-glass |
| Unapproved remote access tools detected | Should fall to near zero after Phase 4 enforcement |
Common failure patterns
- Agents first, security later: thousands of devices enrolled while the console still has local passwords and every technician is an administrator.
- Enrolment keys in shared installers: a reusable installer on a file share or ticket lets anyone enrol devices into the tenant.
- Allowlisting the product, not the tenant: the same signed agent pointed at an attacker's tenant passes application control.
- Broad EDR exclusions for the agent folder: added to stop pilot alerts and never removed.
- Tier 0 and log servers in the general tenant: one console compromise reaches identity, backup and evidence.
- Legacy tools never removed: the old remote support product stays installed "just in case" and remains an unmonitored path.
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Remote maintenance through the RMM | MA-4 Nonlocal Maintenance, MA-4(1) Logging and Review, AC-17 Remote Access | PR.AA-05 | 6.4, 8.2 |
| Console administration and roles | AC-6(5) Privileged Accounts | PR.AA-05 | 5.4, 6.5 |
| Inventory from agents | CM-8 System Component Inventory | ID.AM-02 | 1.1, 2.1 |
| Patching | SI-2 Flaw Remediation | PR.PS-02 | 7.3, 7.4 |
| Blocking other remote tools | CM-7(5) Authorized Software, Allow-by-exception | PR.PS-02 | 2.5 |
| Console and session logging | AU-2 Event Logging, AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-03, DE.CM-09 | 8.2, 8.11 |
| Tenant configuration | CM-3 Configuration Change Control, CM-6 Configuration Settings | PR.PS-01 | 4.1 |
ISO/IEC 27001:2022 Annex A controls that apply include A.8.8 Management of technical vulnerabilities, A.8.2 Privileged access rights, A.8.15 Logging and A.5.19 Information security in supplier relationships for MSP-operated platforms.
Practitioner checklist
- Record hosting, connectivity, remote control path, operator model and excluded asset tiers before purchase.
- Connect the console to SSO with phishing-resistant MFA and keep one vaulted break-glass account.
- Create read-only, service desk, engineer and administrator roles scoped to device groups.
- Enable bulk action approval or step-up for 10 or more devices and a reviewed script library.
- Forward console audit logs to the SIEM and test them before enrolling agents.
- Deploy agents in rings with site-scoped enrolment keys, then rotate the keys.
- Run patch policy in report mode for two cycles, then canary and phased deployment with forced installation after a grace period.
- Allowlist the agent by tenant, audit and then block other remote access software.
- Vault integration API keys with owners and rotation dates.
- Tabletop a hijacked technician account before go-live and hand over to the operations runbook.
Standards and references
- CISA, NSA, FBI, MS-ISAC and INCD: Guide to Securing Remote Access Software
- CISA: AA23-025A Protecting Against Malicious Use of Remote Monitoring and Management Software
- NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CIS: Critical Security Controls v8.1
- MITRE ATT&CK: T1219 Remote Access Tools
- MITRE ATT&CK: T1072 Software Deployment Tools
Related NHI Mgmt Group resources: Remote monitoring and management (RMM) tool migration playbook · Remote monitoring and management (RMM) tool health check · If your remote monitoring and management (RMM) tool is compromised · Cybersecurity for MSPs and MSSPs Guide