Securing the RMM Itself

The platform is the highest-value target in your estate. These are the controls worth having, ordered by what they prevent.

The control described in “Securing the RMM Itself” also consumes technician time before, during and after each maintenance window. A provider evaluating long-term time tracking software can record that operational effort by client and work item, making verification and follow-up visible without confusing a timesheet with proof that a patch succeeded.

For an independent operational benchmark, compare the local practice with CISA guidance on patches and updates; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

Authentication

Strong multi-factor for every account, without exception for convenience.

Phishing-resistant factors where the platform supports them, because the common attack is a convincing prompt rather than a password guess.

No shared accounts.

This is the single highest-value control and the one most often partially implemented.

Access separation

Not everybody needs everything.

Read-only for people who look at dashboards. Single-client scope for technicians who serve one. Full scope for a named few.

Its own note covers separating monitoring from administration, which is the structural version of this.

Administrator machine hygiene

The console is only as secure as the machine it is accessed from.

Which means your own technicians' machines are part of the perimeter: patched, protected, and not shared.

A compromised technician laptop is a compromised console, and this is the route most often overlooked.

Network restriction

Where the platform allows it: restrict console access by address or require a managed connection.

It will not stop everything and it removes the broad, untargeted attempts entirely.

Logging and review

Who logged in, from where, what they ran, what they accessed.

Exported somewhere the platform cannot alter, if possible.

And reviewed — a log nobody reads is evidence after the fact rather than a control.

Alerting on the platform itself

New administrator account created.

Permission escalation.

Script run at multi-client scope.

Login from an unusual location.

These are low-volume, high-signal alerts and they are frequently not configured.

Vendor-side settings

Review the platform's own security options at least annually; they change.

Several platforms have added controls after incidents that existing customers must enable manually.

Being on an older configuration is the common position, and nobody is prompted to fix it.

Offboarding staff

Immediate removal, including any secondary access.

Verified rather than assumed.

And credential rotation for anything shared, which should not exist but does.

What to check

Is multi-factor enforced on every console account?

Are technicians' own machines treated as part of the perimeter?

Do you alert on new administrator accounts?

And when did you last review the platform's own security settings?

The point

The console is only as secure as the machine it is accessed from, which makes your own technicians' laptops part of the perimeter..

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.