Devices

Overview

The Devices module is where you track every company computer and prove it meets your security baseline. A small agent installed on each machine reports its security posture on a regular schedule, and devguard turns those reports into a compliance verdict you can attach to controls and hand to an auditor.

Three things work together:

• Devices is the fleet inventory: what each machine is, who uses it, and whether it is compliant right now.
• Device policy is the security baseline: which of the six posture checks you enforce, and the thresholds that decide each one.
• App policy lists the apps every device must have installed, and the ones it must not.

The agent measures each device against your Device policy and App policy and reports the result. You never configure anything on the machine itself. The policy lives here, and the agent picks it up on its next check-in.

---

Devices

Each device is one company computer. Devices arrive one of two ways:

• Enrolled by the agent: the machine runs the devguard agent, which registers it and reports posture automatically. This is the normal path.
• Added by hand: you record a machine manually (for an asset register), but with no agent it reports no posture and stays Not monitored.

Device fields

Fields the agent reports (OS version, serial number, model) are read-only: they are facts about the machine, not something you edit.

Device identifier

Every device carries a short identifier prefixed MDM- (for example MDM-042). Use it to refer to a specific machine in an audit trail or a support conversation.

Compliance status

A device's status is derived on every read from its last check-in and your policy. Nothing is stored, so it is always current. There is deliberately no fuzzy "at risk" middle state: every check is binary, and the only nuance a device carries is why it is not compliant.

Because the agent reports hourly, a machine that has been silent for seven days almost certainly has a stopped agent. That is worth investigating, which is why it surfaces as Not reporting rather than staying quietly compliant.

---

Device policy

The Device policy is your security baseline: it decides which posture checks a device must pass to count as compliant, and the exact thresholds each one applies. It is a single policy per organization: set it once, and every device is measured against it.

The six checks

Enforce or drop each check

Each check has a switch. A disabled check is not evaluated and never counts toward a device being compliant; its result reads as Not required rather than a failure. Enforce the checks that map to your obligations; leave the rest off.

Thresholds

Three checks carry a threshold you tune to your policy:

• Screen lock: the maximum idle time before the screen must lock (in minutes).
• Password policy: the minimum password length.
• Operating system up to date: how strict OS currency is:
  • Major and minor versions: the machine must be fully patched; a pending point release counts as out of date.
  • Major versions only: the machine must be on a current major release, but a pending minor/point update is allowed (available, not required).

Changes take effect on each device's next check-in (within the hour). You never reship the agent to change a threshold.

Note: Operating-system currency is decided on the server, not on the device: the agent reports its version and devguard compares it against a baseline table it can update centrally. The other five checks are decided locally by the agent using the thresholds above.

Last check-in

The policy also sets how long a device may stay silent before that silence itself becomes a finding. Pick a window (1, 7, 14 or 30 days) and a device that has not checked in within it shows as Not reporting and stops counting as compliant, in the fleet, in the evidence figures and in the device report. Pick never and a device keeps its last known posture however long it stays quiet; the last check-in time remains visible on every surface so the age of that posture is never hidden.

---

App policy

The App policy names the apps that must be installed and the ones that must not, and every device reports against them. It is two simple lists, not a rule builder:

• Required apps: every device must have these installed (a password manager, an EDR agent).
• Forbidden apps: no device may have these installed (a banned file-sharing tool, unlicensed software).

Matching

Each entry tells the agent how to look for the app:

Each entry can also carry an optional remediation note shown to the employee, explaining what to install or remove.

Note: The agent only answers whether these specific apps are present. It never uploads a list of everything installed on the machine; the inventory stays on the device.

---

Enrollment & the agent

Devices join the fleet by running the devguard agent. On first launch it walks the user through a short disclosure of exactly what it reports, then enrolls the machine against your organization.

• What it reports: machine vitals (name, hostname, OS version, serial, model), the six posture-check results, and the required/forbidden app results. Nothing else.
• How often: hourly. Each check-in also fetches the latest Device policy and App policy, so an admin's edit reaches every machine within the hour.
• Authentication: the agent authenticates with an API key scoped to your organization; it can only report into an organization the enrolling user actually belongs to.

Keeping the agent current

The agent updates itself where the platform allows it (Windows, and signed macOS and Linux AppImage builds): it checks for a new version daily and installs on quit. Where it can't apply an update in place (an unsigned macOS build, or a .deb owned by your package manager), it shows the employee a "newer agent available" prompt instead.

devguard compares each device's reported agent version against the latest published one and surfaces a device that has fallen behind in two places:

• an Outdated agent badge on the device's detail page, and
• an Outdated agent count on the fleet overview.

This is a nudge to keep the fleet current, not a compliance failure: an out-of-date agent never changes a device's pass/fail verdict, and a device added by hand (no agent) is never counted here.

The employee portal

Employees never see the fleet. In the employee portal each person sees only the computers they enrolled: the same six checks with the result in plain language, the steps to fix a failing one, and the apps your App policy requires or forbids. Enrolling from the agent lands there too, so a member with the Employee role can install the agent and consent without ever reaching the admin app. The section can be switched off under Settings → Employee portal.

Revoking an agent from a device's detail page stops it reporting. A machine that comes back (a check-in after being archived) is automatically un-archived: a returned laptop should not stay hidden from the fleet or the compliance denominator.

---

Evidence

Devices can be linked to controls and attached as evidence: a compliant fleet is proof for controls about endpoint security, encryption at rest, and malware protection. Link a device to a control from its detail page, or attach it wherever the control expects endpoint evidence, so the auditor sees a live posture verdict rather than a screenshot.

---

Tasks

Each device's detail view has a Tasks tab for the work a machine generates: chasing a missed check-in, scheduling disk encryption, returning hardware at the end of a lease. Use Add task and it is attached to the device automatically. These tasks appear in the central Tasks worklist and, with a deadline, on the Roadmap.

---

Comments

Every device's detail view has a Comments tab for discussing it in place, so the context around a machine (why it is exempt, when it is being replaced) stays attached to the device instead of living in a chat thread nobody can find later.

Write a comment with light formatting (bold, italic, underline, lists), reply to any comment (replies cannot be nested further), and edit or delete your own. Deleting a comment that has replies leaves a placeholder so the conversation still reads in order.

Type @ to mention a colleague. They are notified in the app and by email, and can adjust how often they hear about comments under Settings → Notifications.