Skip to content

Security

Antivirus is everywhere and the console has been silent for months

The company pays for protection on every workstation. The console shows that some agents have not checked in for six months. This is not a rare case.

6 min read · checked: August 2026

The question “do you have antivirus” always gets a yes. The question “how many workstations reported this week” rarely gets an answer, because nobody looks at the console while nothing is happening.

And that is the only number that matters. A licence bought for thirty seats does not protect thirty machines — it protects as many as actually have a working, reporting agent.

Why agents stop reporting

None of these reasons is exotic:

A new machine with no agent. Somebody issued a laptop, set it up, handed it over. The agent was to be installed later.

An agent installed but not linked to the console. The installation went through, the organisation key was never entered, the machine protects itself “locally” and nobody knows about it.

A broken installation after a system update. It happens and gives no message visible to the user.

Switched off by a user with administrator rights because “it was slowing things down”. That one closes together with removing local administrator rights.

A machine that no longer exists. Also relevant — it inflates the seat count and makes counting the real ones harder.

Checking it in fifteen minutes

Open the console and answer four questions:

  1. How many machines reported in the last seven days?
  2. How many machines are in the console but have not checked in for over thirty days?
  3. How many workstations does the company have? Compare with the first number — the difference is your list to explain.
  4. Does any machine have real-time protection disabled or out-of-date signatures?

The gap between the third and the first is usually larger than anyone assumes. This is not an accusation of negligence — it is the natural result of nobody being obliged to look.

The second problem: monitor-only mode

A separate matter, equally common. The tool was deployed in a mode where it detects and reports but does not block — so as not to stop anything at the start. And there it stayed.

Formally there is protection. In reality there are notifications nobody reads.

Getting out of that state is simpler than it looks but takes one working session:

  1. Review the detections from the last few weeks of monitor-only operation.
  2. Establish which of them concern things genuinely used in the company — usually a handful of items, not dozens.
  3. Add exceptions for those, documented: what, why, who decided.
  4. Only then switch to blocking.

Step three matters most. An undocumented exception is, a year later, an exception nobody dares remove because nobody knows what it was for.

The one alert worth switching on

Consoles can notify about everything, and that is exactly why they end up notifying about nothing useful — within a week a mailbox rule moves it all to a folder.

Switch on one alert: a drop in coverage. A notification when the number of reporting machines falls below a threshold, or when one stops checking in for more than a few days.

That single notification catches every cause on the list above and arrives rarely, so it gets read.

Why this matters more than the choice of product

Conversations about endpoint protection usually revolve around which product detects more. Differences between serious products are real, but far smaller than the difference between a protected machine and one that dropped out of the console six months ago.

A machine without a reporting agent is in practice a machine with no protection — regardless of how good the product on the invoice is.

← All notes

NEXT STEP

Describe the problem.
You get a straight answer.

No specification required. A few sentences about your company and what currently does not work is enough to start.

Go to contact