Choosing an RMM without believing the feature matrix

Feature matrices in this category are close to worthless, and everyone involved quietly knows it. Any vendor can answer yes to almost any row, because the rows are written loosely enough that yes is defensible. "Remote access" covers a full session manager and a screenshot tool. "Patch management" covers a governed programme and a button that runs the operating system updater.

The questions that actually differentiate products are architectural, operational and commercial, and they do not appear on comparison sheets because they are difficult to answer in a cell.

Ask about connectivity direction

Does the agent connect outbound to the platform, or does something connect inward to the endpoint — directly, or through an on-premises relay?

This is the single most consequential difference and it is rarely volunteered. Outbound-only means no listening service on managed machines, no inbound firewall rules, no exposure created by a change made for an unrelated reason, and no VPN needed to reach a segregated network. If there is a relay or appliance, you have just acquired a piece of infrastructure: ask what it exposes, where it must sit, and who patches it. It will still be there in five years.

Ask what the platform can cause to happen

Enumerate, precisely, what an operator can make happen on an endpoint. This is a capability question and a security question simultaneously, and the two pull against each other.

A fixed action surface — scan, install, uninstall, remediate, open a session — is bounded and analysable. You can reason about the consequences of a console compromise because you can list them. An arbitrary-code surface is more capable and unbounded: a platform that lets operators run authored PowerShell across endpoints is, architecturally, a remote code execution capability across your entire estate, by design.

That may well be the right trade for you. But it should be a decision. If you are evaluating a tool with scripting, ask specifically what stands between a compromised console session and code executing on a production server, and treat "role-based access control" as the start of the answer rather than all of it.

Ask what happens to history

How long is health history, patch history and audit data retained? Does retention differ by type? What happens to an endpoint's history when the machine leaves management?

This is invisible during an evaluation and decisive during an audit. Evidence you cannot produce for the period in question is not evidence, and a platform retaining ninety days cannot support an assessment covering a year regardless of how the reporting looks in a demo.

While you are there: is an asset a distinct record from an endpoint? If they are the same thing, rebuilding a machine restarts its history, and the platform can only ever tell you what happened since the current OS install.

Ask the gaps question

The highest-yield question in any evaluation is: what is on your roadmap that a prospect might reasonably assume already exists?

A vendor who answers specifically has given you something you can plan around. A vendor who deflects has also told you something, and you will find out what during implementation instead.

We will answer it for ourselves, since it would be poor form to recommend the question and dodge it. AegisOne has no threshold alerting or escalation engine, no synthetic or outside-in service checks, no script library or automation scheduler, no software or package deployment, and no SAML or OIDC single sign-on. Remote screen access is beta, with multi-monitor handling and the end-user consent flow unfinished. If any of those are load-bearing for you, plan around them rather than around a roadmap date.

Ask whether the API can do what the console does

Every platform in this category sits inside a toolchain. The practical question is whether the API exposes the same surface the console uses or a reduced subset covering reads but not operations.

A full API is what lets you compensate for gaps. Teams needing paging from a platform without an alerting engine poll the API from the alerting system they already run and evaluate conditions there — which many prefer anyway, because on-call routing, suppression and escalation stay in one place rather than being duplicated per tool. That arrangement only works if the data and the operations are reachable programmatically.

Then test it properly

Do not evaluate in a clean lab. Deploy into your most awkward environment: the segregated network, the site with the terrible link, the machines behind a proxy that inspects traffic. That is where architectural differences become visible and where a product that demonstrated beautifully either holds up or does not.

Run it for at least a month. Most problems in this category are not visible in week one — they appear in week six, once history has accumulated and connections have been dropped and re-established a few hundred times.

Give it to the technicians who will live in it daily, not only to the person signing. People who use a console every day notice things in week three that no demonstration reveals, and their verdict is a better predictor of whether the purchase works out than any matrix.

And ask the gaps question twice, weeks apart, to different people at the vendor. Consistency there tells you more about how a company operates than any answer to a feature question does.