Security Tool Deployed, Coverage Unknown
- Category
- Visibility & Logging
- Published
- Sep 19, 2026
- Updated
- Sep 21, 2026
The Failure
A security control is considered deployed because its console shows agents, events, or a coverage rate. Nobody, however, compares that population against an independent source describing what should actually be protected.
The organization knows it sees 487 assets. It does not know it should be seeing 512.
Gaps accumulate over time: new equipment never onboarded, a machine restored from an old image, a broken or uninstalled agent, a forgotten server, a rarely connected device, an acquired subsidiary, a system temporarily excluded and never reintegrated. The product works fine. It's the coverage that lies by omission.
Why It Matters
A security console generally cannot show what it doesn't know about. During an incident, that absence is easily misread as an absence of malicious activity.
Uncovered assets become the best places to maintain access, stage tools, or relaunch an attack. They also distort scope: a search run across "all visible endpoints" can produce a conclusion that is technically accurate and operationally wrong.
The problem isn't limited to EDR. It applies equally to logging, vulnerability management, backup, patch management, and any other control whose own console serves as proof of its coverage.
How to Identify It
- Ask for two independently produced numbers: how many assets should be covered, and how many actually are.
- Reconcile the console against at least one other source: inventory, directory, management platform, hypervisors, network data, procurement, or backups.
- Look for agents that are silent, disabled, outdated, in error, or not seen within a defined period.
- Sample the categories that are easy to overlook: servers, powered-off virtual machines, remote endpoints, executive devices, lab equipment, and legacy systems.
- Check whether an alert fires when an expected asset stops communicating. If the only way to find the gap is to manually open the console, the pattern is present.
Fix Before the Incident
- Designate an authoritative source for each asset population and define acceptable discrepancy thresholds.
- Automate reconciliation between the expected inventory and security consoles; alert on missing assets just as much as on detected threats.
- Assign an owner and a remediation deadline for failing or silent agents.
- Build control installation and verification into asset onboarding, restoration, and decommissioning processes.
- Measure coverage by critical population, not just an overall percentage that can hide the three servers you specifically couldn't afford to forget.
If You’re Already in an Incident
- Do not treat the compromised or incomplete console's inventory as the incident scope.
- Build a consolidated list from multiple sources and mark each asset as covered, uncovered, or unknown.
- Prioritize unknown, silent, and unprotected assets for collection, indicator hunting, and, depending on risk, isolation.
- Explicitly log coverage limitations in every investigative conclusion. "No indicators found" only has value if you specify where it was actually possible to look.
- Extend the hunt to restored, dormant, or offline systems before declaring containment complete.
Related Controls
- CIS Controls v8 — 1.1, 1.2, 1.4, 1.5
- CIS Controls v8 — 8.1
- NIST CSF 2.0 — ID.AM-01, ID.AM-02, ID.AM-08
- NIST CSF 2.0 — DE.CM-09
- ISO 27001:2022 — A.5.9
- ISO 27001:2022 — A.8.15, A.8.16