RMM security · 11 minute read
The security checklist to use before trusting an RMM
RMM software is privileged by design. A serious evaluation should test identity, isolation, authorization, evidence, failure, and removal—not just whether the dashboard is easy to use.
Ten questions to answer with evidence
Ask every vendor the same questions. Then verify the answers on authorized, non-production systems before expanding the pilot.
1. Does every installation have its own identity?
Ask whether each agent receives distinct, revocable credentials or whether installers depend on a shared embedded secret. Test revocation on one device without breaking the rest of the pilot.
Pass condition: A unique identity is visible, can be revoked independently, and cannot be reused to enroll another endpoint.
2. Where is tenant isolation enforced?
Filtering in the browser is not an authorization boundary. Confirm that backend queries, object relationships, search, reports, remote access, and bulk actions all recheck tenant ownership.
Pass condition: A technician cannot view, search for, report on, or target another tenant—even through a saved URL or modified request.
3. Can technician authority be split by action?
Look for separate permissions around inventory, remote access, scripts, files, patching, reports, policies, users, and billing. A generic administrator role is too broad for everyday work.
Pass condition: A limited technician can complete the assigned workflow and is denied unrelated privileged actions.
4. Are strong authentication and session controls available?
Verify multifactor authentication, recovery, active-session visibility, revocation, invitation expiry, and what happens after a role or account is disabled.
Pass condition: Pilot technicians use MFA, old sessions can be revoked, and disabled access stops working promptly.
5. Is privileged work bound, signed, and short-lived?
Administrative work should carry the intended device, authorization context, issue time, expiry, replay protection, and integrity evidence. The endpoint—not only the server—should reject invalid work.
Pass condition: Altered, expired, replayed, or wrongly targeted work is rejected and remains visible as a failed security event.
6. Can the audit trail reconstruct an action?
A useful record answers who acted, what was targeted, when it happened, where it came from, and how it ended. Test success, denial, expiry, and endpoint failure.
Pass condition: An investigator can reconstruct each test without relying on browser history or a technician's memory.
7. Is collected endpoint data documented and necessary?
List every inventory, health, identity, network, user, job, and support field the product receives. Map each field to a purpose, retention rule, and customer agreement.
Pass condition: The data inventory matches observed behavior and excludes credentials or content the service does not need.
8. Are external providers and data flows identifiable?
Remote access, payments, email, infrastructure, analytics, and support chat may introduce additional processors. Record what each provider receives and how access is removed.
Pass condition: The pilot owner can draw the data path and name each provider involved in the tested workflow.
9. What happens during outage, compromise, or operator error?
Disconnect an endpoint, stop a noncritical agent service, expire a test credential, and revoke a technician. Distinguish offline, delayed, blocked, failed, and completed work.
Pass condition: Failure is explicit, queued work cannot silently become unsafe, and recovery does not grant broader access.
10. Can you prove the exit path?
Test local and remote uninstall, device revocation, technician removal, session closure, export, retention, and deletion requests. Check the endpoint for remaining services, tasks, files, certificates, and access paths.
Pass condition: Privileged access is removed, retained records are understood, and the organization can leave without an unexplained control path.
A compact pilot scorecard
| Control | Pass condition | Evidence |
|---|---|---|
| Device identity | Distinct and revocable | Enrollment and revocation test |
| Tenant boundary | No cross-tenant visibility or action | Negative permission tests |
| Authentication | MFA enabled; sessions controllable | Settings and revocation result |
| Authorization | Least-privilege role works | Role matrix and denied actions |
| Job integrity | Wrong, expired, or altered work fails | Job and endpoint result |
| Auditability | Actor, target, time, source, result | Audit export or screenshots |
| Data handling | Documented and necessary | Data-flow worksheet |
| Exit | Agent and access fully removed | Completed removal checklist |
Verify Nizlo with the same standard
Use the checklist against a real Windows-first RMM.
Qualified MSP and IT operators can test Nizlo for 14 days without a credit card. Treat every Nizlo-specific statement as a vendor disclosure and verify it during the pilot.