Five jobs to judge endpoint security on your own machines before buying

The demonstration runs on a clean laptop with one browser tab open and a fast connection. Yours runs on a four-year-old machine with forty tabs, a video call in progress, and a bookkeeper who cannot lose ten minutes at month end.

Judge the category by what it does on that machine on a Tuesday afternoon, because that is where it will live.

Nothing below names a product or a price. It sets out what a tool in this category has to do, how to find out whether a candidate does it on your own hardware, and which parts of the sales material are describing the test rather than the product.

What to take away

The five jobs

Stop what is already known to be bad. The baseline, and every product does it. The built-in protection in current operating systems does it too, which is why this is the least useful thing to compare.

Notice behavior that is unusual for that machine. A document that starts encrypting files, a mail client that spawns a command shell, a login tool that reads memory it has no reason to read. This is where products differ, and it is also where they generate the false alarms you will spend time on.

Tell a person, in a way that person will see. An alert that goes to a dashboard nobody opens is a log entry. Ask where alerts go outside office hours and who is expected to act.

Let you cut a machine off without wiping it. Isolation from the network while keeping the evidence is the single most useful response feature for a small business, because it buys time for the sequence described in incident response without destroying what you need to understand what happened.

Keep an honest inventory. Which machines have the agent, which have it switched off, which have not reported in for a fortnight, and which are running an operating system version the vendor no longer protects. A tool that cannot answer those questions leaves you guessing about your own fleet.

The United States National Institute of Standards and Technology describes prevention and handling for desktops and laptops in its guide to malware incident prevention and handling. It is long, and the useful part for a buyer is that it separates prevention, detection and response as distinct jobs, which is exactly the separation that marketing blurs.

What to test, and on which machines

Run the trial on three machines you already own, one at a time, and test on one device before the rest.

The tired laptop. The oldest machine in daily use. Install the agent, use the machine normally for a week, and ask its owner whether anything got slower. Their answer matters more than any benchmark.

The laptop that is rarely connected. A field machine that sees the office network once a month. Watch how the agent updates itself, whether it keeps protecting the machine while offline, and whether the console shows it as missing or merely quiet.

A machine where the user is an administrator. Try to remove the agent as that user. If it comes off without a console-side approval, anything that gains that user's rights can remove it too. Then check the same thing from the console: a departing employee's device should be something you can lock, not just something you can watch.

Then run four exercises on the trial fleet:

Keeping the operating system and browser patched is a separate job the agent does not do for you, and the same institute's patch management planning guide is a fair statement of why that job comes first. Verify that your candidate at least reports which machines are behind, since the fundamentals in endpoint security depend on it.

What the sales material leaves out

Two further things go unsaid: the console needs a human, and that human's hours are the real cost. best security foundations software 2027 argues this for security purchases in general.

The product is only as reliable as the account that administers it, so the console login deserves the strongest factor you use anywhere, as identity and access notes.

Deciding

List the five jobs. Add a column for each candidate and one for the protection you already have. Fill it from your own tests, not the brochure. If built-in protection plus a working backup already covers a job, say so honestly.

Then note what the paid product adds. Ask whether anyone in the business will read its output.

Common questions

Is the built-in protection enough?

For many small businesses with patched machines, non-administrator daily accounts, and a tested backup, it handles the first job well and the second partly.

It stops at the third and fourth: it will not tell a person, and it will not let you isolate a machine remotely. Whether those gaps matter depends on whether anyone would be watching.

How long should a trial last?

Long enough to include a patch cycle, a machine going offline and coming back, and at least one alert that turns out to be nothing. Two working weeks is usually the minimum for those three things to happen naturally.

What if the trial produces no alerts at all?

Either the fleet is quiet or the product is. Use the benign test file to tell the difference, and treat silence you cannot explain as a finding in itself.

Does this reduce the risk from phishing?

Only after the click. The controls that act before it are compared in phishing defense, and endpoint tooling is what limits the damage when those fail.