Device Inventory and Results

Overview

When Fencer discovers devices through your Iru (Kandji) integration, each device becomes a tracked asset with rich metadata. This page explains the fields available on a device asset, how endpoint findings are grouped into vulnerabilities, how to interpret scan results, and how endpoint findings flow into your organization’s vulnerability management workflow.

Device asset fields

Each device discovered through Iru is stored with the following fields:

Identity and hardware

Device name — the friendly hostname or display name of the device as reported by Iru.
Model — the device hardware model (e.g., MacBook Pro 14-inch).
Serial number — the unique hardware serial number used to identify the device across scans.

Platform and OS

Platform — the operating system family reported by Iru.
OS version — the detected operating system version string (e.g., 14.4.1).

MDM and management

MDM enrolled — whether the device is actively enrolled in Iru MDM (Enrolled or Not enrolled). Devices that lose enrollment continue to appear in inventory but may not receive updated vulnerability data.
Last check-in — when the device last checked in to MDM. Devices that have not checked in for 30 or more days are marked Stale.
Last synced — when Fencer last synced the device from Iru.

Security

Security agent — whether the Iru security agent (used for vulnerability detection) is Installed on the device. Devices without the security agent cannot have vulnerabilities reported by Iru and will show no findings even if outdated software is present.

Hardening posture

The device’s overview also shows its posture as reported by Iru — Disk encryption, Firewall, Screen lock, OS up to date, and Blueprint (compliance with its assigned Iru blueprint) — each as Yes, No, Warning, or Unknown. The same signals are available as optional columns on the Endpoints list.

How findings are grouped

Iru reports one detection per CVE per installed file. Fencer groups the detections for the same file path on the same device into a single vulnerability that lists every CVE found at that path.

This means:

The same application at the same path on two different devices creates two separate vulnerabilities (one per device).
The same application installed at two different paths on the same device also creates two separate vulnerabilities.
Several CVEs affecting the same path on the same device are combined into one vulnerability.
Re-running a scan on the same device for a finding already in the pipeline updates the existing vulnerability rather than creating a duplicate.

Some detections are left out to keep the list actionable: software found in test fixtures or temporary directories is skipped, and Low and Medium CVEs are only reported when an upstream fix is available (High and Critical CVEs are always reported).

If you turn on Unpatched vulnerabilities (“Defer vulnerabilities without an upstream patch”) in Settings > Organization, a new endpoint vulnerability for which no upstream fix exists is deferred automatically, and comes back as soon as a fix becomes available.

Scan result fields

Each vulnerability produced by an endpoint scan includes the following fields:

Software identification

Application name — the name of the outdated software detected (e.g., Google Chrome, OpenSSL, Python).
Application version — the installed version at the time of scanning.
File path — the path on the device where the vulnerable software binary or package is installed (e.g., /Applications/Google Chrome.app). Operating system findings have no path.

Vulnerability details

CVEs — the Common Vulnerabilities and Exposures identifiers found at that path (e.g., CVE-2024-1234).
Severity — the highest severity among those CVEs.
Fix availability — whether an upstream fix is available. When no update is available, the remediation suggests removing the application.

Device context

Device name — the name of the device where the vulnerability was found.
Serial number — the device’s hardware serial number.
Model — the device hardware model.
OS version — the operating system version at the time of the scan.
Blueprint — the Iru blueprint assigned to the device.

The device’s Software & Patch Status tab lists the same findings with their Severity, Finding, Path, CVEs, and Fix status (Fix available, No fix, or Unknown).

Severity mapping

Fencer uses the severity Iru reports for each CVE — Critical, High, Medium, or Low — and gives each vulnerability the highest severity among the CVEs at its path. Findings in package manager caches are capped at Low, because cached packages are not directly installed.

Vulnerability types and title format

Each vulnerability is classified by where the software lives on the device:

Type	Paths
Operating system out of date	Operating system components and findings without a path
Application out of date	`/Applications/`, `.app` bundles, and `Program Files`
Developer tool out of date	Homebrew and `/usr/local/`
Outdated dependency in package manager cache	Package manager caches
Endpoint software out of date	Everything else

Each vulnerability title follows the format:

“{app_name} {version} has known vulnerabilities”

For example: “Google Chrome 120.0.6099.62 has known vulnerabilities”. This makes it easy to identify which specific software installation needs attention, especially when the same application is installed at multiple paths.

Integration with the vulnerability dashboard

Endpoint findings appear in the same vulnerability management pipeline as code, cloud, application, and SaaS findings. From the Vulnerabilities page you can:

Filter by asset type — select Endpoint to see only endpoint findings.
Filter by device — narrow results to a specific device asset.
Filter by severity, CVE, or status — standard pipeline filters apply.
Assign owners — assign a team member responsible for remediating the finding.
Change status — move findings through your triage workflow, or ignore or defer them.
Create tickets — push findings to Jira or Linear directly from the vulnerability detail page.

Scan trigger types

Trigger	Description
Manual User	Triggered by clicking Run scan or Scan All on the Endpoints page
Scheduled	Triggered automatically, daily or weekly depending on your plan, and for the first scan after you connect Iru

Examples

Reviewing a device’s vulnerabilities

You notice a device named “alice-mbp” has 12 vulnerabilities. Click the device row on the Endpoints page to open its detail page. The Scans tab shows the most recent scan completed 2 hours ago and found 3 Critical and 9 High findings. The Vulnerabilities tab lists them sorted by severity. The top finding shows “OpenSSL 3.0.2 has known vulnerabilities” at path /usr/local/lib with CVE-2023-0286 (High). You assign it to your security team lead and start triage.

Identifying devices with the most critical findings

From the Vulnerabilities page, filter by severity Critical and asset type Endpoint. Sort the results by asset name to see which devices appear most frequently. Devices that show up repeatedly are candidates for prioritized patching or blueprint enforcement updates in Iru.

Troubleshooting

Device shows no vulnerabilities despite outdated software — Verify the Iru security agent is installed and active. Devices without the security agent will not have vulnerability data reported by Iru, even if software is outdated. Low and Medium CVEs without an available fix are not reported.
Several vulnerabilities for the same application on the same device — This happens when the vulnerable software is installed at multiple file paths. Each path produces a separate vulnerability.
Device inventory not updating — Ensure your Iru integration is connected and that the API token has the Devices → Device list permission. Click Scan All to force a re-sync of the device list.
OS version or model showing as outdated — Device metadata is refreshed when devices are synced. Click Scan All to pull the latest device information from Iru.