RMM Tool Buyer's Guide: Evaluation Criteria That Matter

A remote monitoring and management (RMM) platform can run any command on every endpoint it manages, which makes the platform itself one of the most powerful identities in your estate. Buying one is therefore a security decision as much as an IT operations decision. This vendor-neutral guide sets out the requirements to define, the evaluation criteria that separate a safe platform from a risky one, the questions to put to suppliers, the red flags, and how to run a proof of concept. It is for IT operations leads, security architects, managed service providers and procurement teams. It does not name or rank products. How to govern and harden an RMM you already run is covered in the RMM Tool Security Guide.

Key takeaways

Judge the control plane first. Administrator authentication, role scoping and tamper-resistant audit logs matter more than the length of the feature list.
Least privilege must be possible. Look for read-only and reduced-privilege modes so routine monitoring does not run with full administrative rights, as the joint US and Israeli government Guide to Securing Remote Access Software recommends.
Mass actions need guard rails. Scripts and commands pushed to many devices at once should support approval workflows and alerts.
Your security team must be able to see it. Exportable logs, a documented API and agent signing let you allowlist the approved tool and detect everything else.
Secure by design is a buying criterion. Ask about MFA by default, SSO at no extra cost, log retention, vulnerability disclosure and patching, as CISA's Secure by Demand guide suggests.

Define requirements

Write requirements before talking to suppliers. Cover these areas:

Estate: operating systems, servers versus workstations, mobile, network devices, OT or clinical devices, number of endpoints and sites.
Operating model: in-house IT, a managed service provider, or both. MSPs need strong tenant separation between customers.
Functions: monitoring and alerting, patching, scripting and automation, software deployment, remote session, asset inventory, ticketing integration.
Deployment: vendor-hosted SaaS, self-hosted, or hybrid; data residency; connectivity from restricted networks.
Identity: SSO with your identity provider, phishing-resistant MFA, role model, just-in-time access, and how agents and API clients authenticate.
Security operations: log export to your SIEM, alerting on risky actions, integration with endpoint detection and response, and whether your SOC can see technician activity.
Compliance: sector rules, contractual obligations to customers, and evidence you need for audits.

Also decide which existing remote access tools the new platform will replace, so the purchase reduces the number of approved tools rather than adding one. CISA, NSA and MS-ISAC advisory AA23-025A recommends auditing which remote access tools are in use and which are authorised.

Evaluation criteria

Area	What good looks like	Suggested weight
Administrator authentication	SSO via SAML or OIDC, MFA enforced for every technician with phishing-resistant options, no shared logins, conditional access support	High
Authorisation and scoping	Granular roles, scoping by site, device group or customer, read-only and reduced-privilege modes, just-in-time elevation	High
Mass action controls	Approval workflow or second person for scripts targeting many devices, script signing or library control, rate limits, alerts on bulk actions	High
Audit logging	Every login, session, script, file transfer and configuration change logged with technician identity; logs hard to delete or alter; export to SIEM by API or syslog; retention you can set	High
Remote session security	End-user consent and notification options, session recording, idle timeouts, clipboard and file transfer controls	Medium
Agent security	Signed agents and updates, tamper protection, agent-to-server mutual authentication, outbound-only connectivity, uninstall protection	High
Tenant separation (MSPs)	Strict logical separation between customers, per-customer credentials, no cross-customer scripts by default	High for MSPs
API and integrations	Scoped API keys or OAuth clients, key expiry and rotation, per-integration permissions, API activity logged	Medium
Supplier security practice	Public vulnerability disclosure policy, timely advisories, SBOM on request, automatic updates for hosted and agent components, independent assurance reports	Medium
Operations fit	Patching coverage, scripting languages, reporting, ticketing integration, scale and performance	Medium

The weights are an NHI Mgmt Group suggestion; adjust them to your risk. A platform that scores well on operations but poorly on the four high-weight security areas should not proceed.

Questions to ask vendors

Is MFA enforced for all technician accounts by default, and which phishing-resistant methods are supported?
Is SSO with our identity provider included in the standard licence?
Can we create read-only and reduced-privilege roles, and scope technicians to device groups, sites or customers?
Can scripts or commands targeting more than a set number of devices require approval by a second person?
Which events are logged, how long are they kept at no extra cost, and can a tenant administrator delete or alter them?
How do we stream logs to our SIEM, and in what format?
How are agents authenticated to the service, and how are agent binaries and updates signed?
Which agent publisher, certificate or hash details can we use to allowlist the agent and block other remote tools?
For MSP use, how is customer data separated, and can a technician account ever act across customers without explicit assignment?
How are API keys scoped, can they expire, and is their use logged?
Do you publish a vulnerability disclosure policy and security advisories, and how quickly do hosted components receive fixes?
Can you provide an SBOM and recent independent assurance reports?
How do you monitor for abuse of free trials and unauthorised use of your software?
What happens to our data and agents at contract end, and how are agents removed?

Red flags

MFA or SSO available only on a premium tier, or MFA optional for technicians.
Single all-powerful administrator role with no read-only or scoped roles.
Audit logs that tenant administrators can delete, short fixed retention, or no export.
No way to require approval for mass scripting or bulk deployment.
Unsigned agents, or agents that listen for inbound connections from the internet.
Shared technician accounts encouraged in documentation or onboarding.
No public vulnerability disclosure policy or security advisories page.
For MSPs, customer separation that relies only on naming conventions.

Where identity fits

An RMM platform concentrates several non-human identities: the agents on every endpoint, the service accounts or local system context they run as, API keys used by ticketing and automation, and the platform's own administrative tokens. The Guide to Securing Remote Access Software recommends treating MSP accounts as privileged, avoiding admin credential reuse across customers and keeping log servers out of reach of RMM tools. Evaluate how each of these identities is created, scoped, rotated and revoked, and include them in your privileged access and secrets programmes. See the GDAP and MSP Delegated Admin Access Guide.

Proof of concept

Set up identity first: connect SSO, enforce MFA and build at least three roles (read-only, technician scoped to one group, administrator). Confirm each role can do only what it should.
Test mass action controls: attempt to push a harmless script to a test group above your approval threshold and confirm the approval workflow and alert fire.
Check the audit trail: perform logins, sessions, file transfers and configuration changes, then confirm each appears in the log with technician identity and reaches your SIEM.
Try to tamper: as a tenant administrator, attempt to delete or alter logs and to uninstall an agent without authorisation. Record results.
Validate allowlisting: allowlist the agent by publisher or hash in your application control and confirm unapproved remote tools are blocked on pilot endpoints.
Exercise API security: create a scoped API key for one integration, confirm it cannot reach other functions, rotate it and confirm the old key fails.
Measure operations fit: patch success rates, script reliability and technician experience on a pilot group of a few hundred endpoints.
Plan exit: confirm agent removal and data export work before you sign.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

RMM Tool Buyer’s Guide: Evaluation Criteria That Matter