By Yair Knijn · June 4, 2025

The SOC manager who thought silence meant safe, while offline laptops ran on stale policy for weeks

A security operations manager I worked with ran a clean board: zero open endpoint alerts for eleven days straight, and he read that as the program finally settling in. What it actually meant was that forty-odd laptops had stopped checking in, and a dead agent files no tickets. The quiet was not coverage. It was agents running on whatever policy they last received.

The wrong assumption was that absence of alerts maps to absence of problems. Quiet can mean nothing happened, or it can mean nothing is being seen, and a dashboard that only renders what reports in cannot tell those apart. He was reading a survivorship-biased view of his fleet.

Why "no alerts" is not "no problem" for endpoint agents

An alert feed is a list of machines that successfully phoned home. Every endpoint that cannot reach the console drops off it silently, which inverts what quiet means. And the ones most likely to go dark, roaming laptops, a VLAN that lost its egress route, a machine where someone stopped the service, are the ones you want eyes on. A capable attacker treats neutralizing endpoint protection as an early step, so the first sign is often a green board.

The countermeasure is old and dull and works: alert on the absence of expected telemetry, not only on suspicious events. If a host that reported hourly for a year goes silent, treat that silence as the finding. An agent_health_drop deserves the same urgency as a malware detonation; it can be the same incident.

Offline enforcement: policy and feeds that work without the console

The deeper failure is that "cannot reach the console" too often collapses into "stops enforcing." If blocking logic lives server-side and the agent only proxies decisions upward, a captive portal or a flaky uplink leaves the endpoint wide open. So the agent must cache its category policy and threat feeds locally and keep applying them with no live link. The trade is freshness, and stale is fine while it stays bounded and visible: a feed four hours old still blocks yesterday's URLhaus hosts; one three weeks old and silently assumed current is the real failure.

Detecting agent staleness and last-check-in drift

You cannot manage drift you do not measure, so make two clocks first-class. One is last check-in: when did this agent last reach the console. The other is policy age: which categories and feeds is it enforcing now. They fail differently: an agent can check in perfectly while running a stale ruleset after a feed refresh quietly failed.

• Last check-in past a threshold (say 48 hours) flags a possibly-dark agent.
• Policy or feed version lag behind the published version flags an agent enforcing old rules while still reporting.
• Reconciliation on reconnect means a dark agent, on return, reports what it missed rather than pretending the gap never happened.

Building a "show me the dark agents" view first

Two populations make this urgent: roaming laptops that drift off the network by design, and low-connectivity sites, a clinic, a depot, a factory floor, that never had a reliable path home. A program that only works for always-online desktops has a hole under its most exposed users.

The view that matters is the inverse of the alert feed: every agent that has not reported recently or is lagging on policy, ranked by how long it has been dark. Stand it up before a NIS2 or ISO 27001 audit asks you to evidence continuous coverage, because "we had no alerts" is not an answer an assessor accepts once they grasp that a dead agent is silent by design.

ClearScreen is built around that inversion. Each agent caches its category policy and signed feeds and keeps enforcing offline, while last check-in and policy age surface per policy group, so a tenant sees which endpoints have gone quiet and how stale. See how the enforcement and health model handles the offline case.