Installed Is Not the Same as Working
A tool can be installed and still do nothing.
Most monitoring answers one question. Is the tool installed, yes or no? Green check, you’re covered. Red X, go reinstall. It is clean, it is binary, and it is where a surprising amount of risk hides.
Since installed and working are not the same question. A tool can be deployed on every endpoint you expect, show up as present in your RMM, and still be quietly failing to do the one job you are paying it to do.
A story most MSPs will recognize
Here is a pattern that plays out more often than anyone likes to admit.
A client was certain their EDR was deployed everywhere. Their RMM confirmed it. The agent showed installed across every endpoint, so as far as the team was concerned, those machines were protected. Case closed.
Then they started getting flagged that the tool was not checking in on a set of those same assets. The pushback was immediate: It is installed, I can see it right there. The reply was the part that stuck. We are not telling you it is not installed. We are telling you it is not checking in. Then, an audible pause fills the room. Those are two different things.
The tool was there. It just was not working. We can’t expect everything to work the way it is the day it was installed, that’s just not how technology works. Once they dug in and fixed it, a wave of tickets that had been quietly piling up closed out. The experience changed how they ran monitoring from that day forward. The question was no longer “is it installed.” It was “is it connected and actually reporting.”
Installed, configured, working: three different questions
It helps to separate what a green checkmark actually promises from what you assume it promises.
Installed means the software is present on the machine. That is all it means. It does not mean the agent is checking in. It does not mean it is configured correctly. It does not mean it is sending data anywhere that anyone is watching. And it does not mean it is catching what it is supposed to catch.
Each of those is a separate condition, and a tool can pass the first and fail the rest. An EDR agent that stopped checking in after an OS update. A backup that runs on schedule but has been silently failing for six weeks. An email security policy applied to the domain but never extended to a batch of new mailboxes. In every case the dashboard says present. Reality says exposed.
Why the binary view feels safe
RMM and single-tool dashboards are built to answer the binary question, and they answer it well. Installed or not installed. That simplicity is exactly why it feels reassuring, and exactly why it is incomplete.
A yes-or-no view cannot tell you about degradation. It cannot tell you the agent went dark three days ago, because from its point of view the agent is still technically there. It cannot tell you that two tools disagree about the same machine. The binary view is comfortable precisely because it never surfaces the uncomfortable middle, the place where a tool is installed, looks fine, and has stopped doing its job.
That comfort has a name worth being honest about. It is the assumption that deployed equals protected. Most of the time it holds. The trouble is that the times it does not are invisible until something forces them into view.
What it costs when installed is not working
A tool that is installed but not working is in some ways worse than a tool you know is missing, because a known gap gets fixed and an invisible one just sits there waiting to be exploited.
The risk is obvious once you say it out loud: the endpoint everyone believed was covered is the one with no live protection. If an incident lands there, it lands on the machine that was at risk while appearing in compliance. If that client carries financial protection where that control is required for coverage, an unresolved gap on the exact asset that was compromised is precisely the kind of thing that can put a claim in jeopardy… at the worst possible moment.
Every one of those silent failures is generating friction in an MSPs operations:
Tickets that do not quite add up.
Alerts that never fire, because the thing that should fire them is offline.
Teams spend real hours chasing the symptoms of a tool that simply stopped reporting, without ever suspecting the tool itself.
These points represents a quieter cost that is rarely considered.
Monitor connection, not just presence
The shift is not complicated, but it changes everything downstream. Stop monitoring whether tools are installed. Start monitoring whether they are connected and reporting.
That means treating “checking in” as the real signal, not “present.” It means cross-referencing your tools against each other, so when your RMM says a machine exists but your EDR has not heard from it in days, that disagreement surfaces on its own instead of waiting for an incident to reveal it. The gaps that matter almost always live in the space between two tools, and no single tool can see that space.
This is the layer Cork Vantage sits on. Rather than asking each tool whether it is installed, Cork watches whether the tools you already run are actually checking in, and flags the assets where they are not. Not “the agent is missing,” but “the agent is there and has gone quiet.” That is the alert that closes tickets before they become incidents, and it is the difference between a stack you assume is working versus proving that everything is in place as expected.
The question to ask this week
Pick one tool you consider fully deployed across your client base. Now ask a harder question about it. Not “is it installed everywhere,” but “is it checking in and reporting everywhere, today?”
If the answer is a confident yes, backed by something more than a green checkmark, you are in good shape. If the honest answer is “it should be,” that gap is worth finding now, on your terms, rather than during an incident on someone else’s.
Installed is a starting point. Working is the whole game.