The Tool That Fixes Can Also Break

The capability that makes this software valuable is, described neutrally, the capability an attacker would most want. That is not alarmism; it is a description.

The recommendations in “The Tool That Fixes Can Also Break” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing the full explanation can use time and project records to see where operational effort accumulates, without treating activity data as a substitute for technical evidence or direct discussion with technicians.

For an independent operational benchmark, compare the local practice with NIST Cybersecurity Framework; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What the platform grants

Execution of arbitrary code on every managed machine.

At the highest privilege level available.

Across every client, from one console.

Usually without the user noticing.

No other tool a service provider operates concentrates that much reach.

Why this matters more than it used to

Service providers are an efficient route to many organisations at once, which has not escaped notice.

Attacks against this category of tooling have occurred repeatedly in recent years, as a class, with consequences reaching the providers' clients rather than the providers alone.

Naming the pattern is enough; the specific incidents date quickly and the lesson does not.

The three routes in

Compromise of the vendor, which reaches every customer of that platform.

Compromise of your console: credentials, session, or an administrator's machine.

Misuse by somebody with legitimate access.

Each has its own note, and the controls differ.

What makes it worse here than in internal IT

The blast radius crosses organisational boundaries.

An internal IT compromise affects one organisation. A provider compromise affects everybody they serve, and those clients did not choose your security posture.

That asymmetry is the ethical weight of this business, and it belongs in how the platform is run rather than in a policy document.

What follows practically

The RMM deserves stronger controls than anything else you operate: authentication, access separation, logging, and a plan for compromise.

Those are the next several notes.

None is exotic and most providers have implemented some and not all.

The conversation with clients

They are exposed through you and most do not know it.

Being able to describe your controls — authentication, who has access, what is logged, what happens if the vendor is breached — is increasingly asked for and rarely prepared.

Write it once, a page, and it serves sales, audit and incident response.

Not overcorrecting

The answer is not to stop using the tool, which would make the service impossible.

It is to run it as the privileged system it is, rather than as an operational convenience.

The difference is mostly discipline rather than spend.

What to check

How many people can execute code across all your clients?

Is your RMM protected more strongly than your email?

Could you describe your controls to a client who asked?

And is there a plan for the platform being compromised?

The point

An internal compromise affects one organisation; a provider compromise affects everybody they serve, and those clients did not choose your security posture..

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.