Cyber Asset Management

Coverage and agents

Knowing what assets you have is only half the job — you also need to know which ones nobody is watching. These screens show which of your endpoints are running each required security agent, let you define what "covered" means for different groups of assets, and help you turn the resulting gaps into tracked work.

What it's for

• Find blind spots — the endpoints missing an endpoint-protection or vulnerability agent, ranked by how much risk the gap represents.
• Set the rules — define which tools each group of assets must run, so gaps are measured against your own standard.
• Act on the gaps — package them up, get them approved, and send them to your ticketing or notification tools, then re-check whether they closed.

The screens in it

• Agent Coverage — the endpoint-by-endpoint view of which agents are installed, stale, or missing.
• Coverage Policies — where you define required-agent rules for groups of assets.
• Action Center — where coverage gaps become approved, trackable action packages.

Agent Coverage — the endpoint coverage matrix with per-agent status

Agent Coverage

Agent Coverage shows, for every expected endpoint, which required agents it's running. A row of cards at the top summarizes Expected endpoints, Fully covered, and Missing any required, plus one card per required agent.

An endpoint's status for each agent is one of a few states, explained in a banner: installed, stale (installed but not seen recently), pending identity review (a tool saw it but its identity isn't reconciled yet), or truly missing.

Reading the coverage truth

A Coverage truth panel shows how fresh the numbers are, with a badge reading Fresh, Aging, Stale, or No snapshot, and when they were last captured. Refresh reloads them; administrators can Capture now to take a new snapshot, and a small history chart shows how coverage has trended.

Controls

Control	What it does
Policy mode	Sets which assets count as "expected" — Strict (endpoint inventory), Include high-confidence discovered, or All discovered (audit).
Missing-only	Shows only endpoints missing a required agent.
Missing agent	Filters to endpoints missing one particular agent.
Search	Finds an endpoint by hostname, domain name, or IP.
Required agents	Chips that choose which agents this view treats as required; a note shows when your selection overrides the saved policy, with a Reset to policy link.
Export	Opens the export builder, or downloads a quick CSV or JSON of the current view.
Recalculate	(Administrators.) Previews changes, or applies safe automatic fixes.

The coverage matrix

The main table is the Endpoint coverage matrix. Each row is an endpoint; use the column selector to choose columns such as Endpoint, FQDN, IPv4, OS, Source evidence, Coverage state, and Missing. Status chips (installed, stale, pending, missing) tell you each agent's state at a glance, and a legend explains the colors.

Click a row to expand it into a drilldown that shows the asset's details, why it does or doesn't count as an expected endpoint, an evidence summary, and a per-source evidence table. From here you can also follow a Compare by signal link to investigate a disagreement between sources — see Reconciliation and correlation.

Each row in the per-source evidence table can be Detached (if you can manage CAM connectors) — useful when a vendor record has been matched to the wrong canonical asset. Detaching asks you to confirm Detach source evidence? and requires you to enter a Reason before you can continue. Confirming archives that source's link to the asset and reopens the same source record as a pending identity review, so it can be re-matched (or attached elsewhere) later — the underlying vendor data isn't deleted, it stays available for audit and repair.

AI coverage insights

(If your workspace has AI features enabled.) Click AI insights to generate a short, suggestion-only readout of your current coverage posture: a plain-language summary, the top gap drivers, and recommended actions. It's built from aggregated coverage statistics only — no hostnames leave the server — and it never changes anything by itself; review it like any other suggestion before acting.

Advanced diagnostics

When ManageEngine Endpoint Central is one of your required agents, an Advanced menu appears next to Export with ManageEngine-specific diagnostics:

Action	What it does
Missing-evidence audit (export)	Downloads a CSV comparing endpoints that are hard-missing the agent against ManageEngine's raw inventory, so you can tell "genuinely missing" apart from "evidence exists but didn't match."
Revalidate evidence	Re-checks your existing coverage rows against that raw inventory and reports safe matches, rows that need review, and endpoints not found at all.
Reprocess preview	(Connector managers.) Previews a pending-review repair pass — how many rows would safely attach, need a refresh, or are already resolved — without applying anything.

Workflow: find endpoints missing an agent

1. Set Policy mode to match how strict you want to be — Strict (endpoint inventory) is the tightest.

   Step 1 — choosing the policy mode

2. Turn on Missing-only, and optionally pick one agent in Missing agent.

3. Review the matrix — every row now is a genuine gap. Expand a row to see the evidence behind it.

   Step 3 — an expanded row showing per-source evidence

4. Use Export to hand the list off, or move to the Action Center to package it.

Coverage Policies

A coverage policy is your definition of "good coverage" for a group of assets — for example, Windows servers in finance must run an endpoint-protection agent and a management agent. Coverage Policies is where you create and manage them.

Coverage Policies — the create form and the tool coverage matrix

Summary cards show how many Policies you have, how many are Enabled or Disabled, and the number of Open gaps. Administrators can Evaluate All to re-check every policy against the current inventory.

Creating a policy

(If your workspace has AI features enabled and you can manage policies.) You can start from Draft with AI instead of filling in every field by hand: describe the rule in plain language — for example "All Windows servers in the finance unit must run Sophos and ManageEngine, treat misses as high severity" — and click Draft policy. It fills in the form below from your description, together with its rationale; nothing is saved until you review it and click Create Policy.

Fill in the Create policy form:

1. Give the policy a Name.
2. Narrow which assets it applies to with OS family, Entity class, and an optional Business unit, and choose whether it covers Expected endpoints only.
3. Choose the Required sources — the agents an asset in scope must run.
4. Set a Severity for the gap, and optionally map it to a compliance Framework and Controls (either typed in, or picked from the built-in Control catalog).
5. Click Create Policy.

Freshness defaults

Agent evidence freshness defaults sets the workspace-wide rule for how recently an agent must have reported before its evidence counts as installed:

• Default window (days) — leave blank for no freshness gate, or set a number of days; evidence older than that is no longer "installed."
• Missing last-seen — how to treat evidence with no last-seen date at all: Pending review, Treat as missing, or Count as installed.
• Per-agent windows — override the default window for individual agents (for example, a shorter window for an EDR agent than for a management agent).

Individual policies can carry their own exception to this default: use Override in the Tool Coverage Matrix (below) to set a freshness window and a Missing last-seen behavior for just that policy, using the same three options above.

A separate Fleet KPI segmentation setting lets you exclude mobile devices (Android, iOS, iPadOS) from endpoint-agent coverage KPIs and gaps — they stay visible everywhere else as CAM assets, they just don't count against your endpoint-agent numbers by default.

The tool coverage matrix and gap drilldown

The Tool Coverage Matrix table lists each policy with its severity, required tools, latest result, and row actions to Run (evaluate just that policy), Enable / Disable, set a coverage default, Override its freshness window, or Delete it. Beneath it, the Gap Drilldown table lists the individual assets failing a policy — which policy, which tools are missing, and when it was evaluated — and you can Export it to CSV.

Gap Drilldown and its export are capped at 100 rows

The Gap Drilldown table — and the CSV you get from its Export button — show only the first 100 gap rows, with no further pages. The Open gaps summary card above the matrix always reflects the true, uncapped count, so it can read higher than what you see (or export) below it. If Open gaps is above 100, don't treat the Gap Drilldown export as a complete list for a compliance report — narrow it by running one policy at a time, or pull the full set from Asset inventory instead.

Action Center

The Action Center turns coverage gaps into tracked work. You bundle a set of gaps into an action package, get it approved, dispatch it to your notification or ticketing tools, and later re-check whether the gaps actually closed.

Action Center — packages, their status, and the detail pane

Summary cards show Loaded packages, Draft packages, Still open, and Closed. Package top gaps builds a package from the current highest-priority gaps. A package can also be Approved (on its way to dispatch) or Cancelled — use the Status filter above the table to find packages in any state; only Draft, Still open, and Closed have their own summary card.

Action workflows

The Action workflows panel lets you save a repeatable recipe for selecting and packaging gaps. In the Workflow builder you set:

Field	What it does
Workflow name	A label for the saved recipe.
Preferred action	Notify subscribers, Webhook, Jira ticket, or ServiceNow ticket — the dispatch target used once a package built from this workflow is approved.
Max items	The most gaps a single run will package.
Required agents	Optional override of which agents count as required for this workflow, instead of following the current coverage policy.
Ranking window	How many of the current highest-risk gaps to consider before selecting the top items — raise it to look further down the risk-ranked list.
Minimum items	The workflow only creates a package if at least this many matching gaps are found.
Due in hours	Optional — sets the new package's due date this many hours out.
Due-soon warning	How many hours before the due date the package's SLA turns due soon.

Workflows can run on a schedule you set — every weekday, daily, weekly, monthly, or a custom cadence with a timezone — or only when you run them by hand. A run history records each run and its steps.

Working a package

Select a package to open its detail pane, which lays out the package's path — Package → Approval → Dispatch. The typical flow is:

1. Click Package top gaps (or run a workflow) to create a package.

2. Select it in the table to open the detail pane.

3. Click Approve — nothing is sent to an external tool until the package is approved.

   Approving a package before dispatch

4. Check Dispatch readiness, then dispatch with Notify, Webhook, Jira, or ServiceNow.

5. After the work is done, click Re-check to see whether the gaps closed. The package moves to Closed, or stays Still open if gaps remain. A dispatch log records every external attempt.

If a package is no longer worth acting on, click Cancel at any point before it closes — even after it's been approved or dispatched. A cancelled package stays in the list and keeps its history for reference, but no further re-check or dispatch happens against it.

Approval is a sequencing step, not a separate reviewer

Dispatch is genuinely blocked until a package is approved, but approving and dispatching only require the same Action Center access as creating the package in the first place — there's no built-in requirement that a different person approve a package than the one who created it. Use Approve as a deliberate "this is ready to go out" checkpoint in your own process, not as an independent second sign-off; if you need a hard separation of duties, enforce it through your own team's process rather than relying on this screen alone.

Due dates and SLA

A package can carry a Due date and an SLA status so remediation with a deadline doesn't get lost. The SLA status is one of: not set, on track, due soon, overdue, or closed (once the package itself is closed). Set an initial due time from a workflow's Due in hours and Due-soon warning fields, or click Refresh SLA on an individual package to recompute its status against the current time.

Related pages

• Asset inventory
• Reconciliation and correlation
• Notifications
• Remediation