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 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 or phone. Devices arrive one of three ways:

• Enrolled by the agent: the machine runs the devguard agent, which registers it and reports posture automatically. This is the normal path for computers.
• Confirmed by the employee: a phone runs no agent, so its owner registers it in the employee portal and answers the two questions a phone can answer, whether it locks itself and whether Find My is on. Registration asks for the phone's name, platform, operating system version and serial number, all required. The answers count as posture, and the owner is asked to confirm them again every 90 days; a phone whose confirmation has lapsed shows as Not reporting like a silent agent. The Deadlines page lists a phone once its confirmation is halfway to lapsing, so there is time to chase the owner; the portal itself sends no reminder.
• 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 checks

A phone answers only Screen lock and Find My, confirmed by its owner; the other checks do not apply to it and never count against it.

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.

Find My and Agent up to date start switched on. An agent installed before the Find My check existed reports nothing for it, and neither does one whose owner has not yet accepted the updated disclosure; until it does, Find My reads Not reported and does not count against the device. The first reading it sends counts like any other. Agent currency never turns the fleet red on release day: each release carries a grace period before an outdated agent counts as a failure.

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 posture-check results, the required/forbidden app results, and which version of the disclosure its owner accepted. 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.

Out of the box this is also a compliance finding: Agent up to date is enforced in the Device policy, so a device stays compliant for 14 days after a release and fails until its agent updates. While the release feed is unreachable the last verdict stands, and a device that has none yet is assumed current, so a feed outage never turns the fleet red. Switch the check off to keep the badge as a nudge only: an out-of-date agent then no longer changes a device's pass/fail verdict. A device added by hand (no agent) is never counted here.

On the machine itself, the agent's window says when a newer version is available and offers to check for updates, downloads it, and asks the employee to restart to install it. Where it cannot update itself it links to the download instead.

The employee portal

Employees never see the fleet. In the employee portal each person sees only the computers they enrolled and the phones they registered: the same 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. A phone is added with Add a phone (name, platform, operating system version and serial number, all required), confirmed again from its detail page when the confirmation is due, and removed by its owner when it goes out of service. 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.

---

Remote lock

A lost or unattended computer can be locked from its detail page. The agent locks the signed-in session the way its owner would from the keyboard: the password unlocks it again, nothing is wiped, no setting changes. This is the only thing an administrator can ask an agent to do, and it is deliberately a first response rather than a control on its own: anyone who knows the password unlocks the machine, so a lost device still needs its access revoked elsewhere. Disk encryption, which the fleet already verifies, is what protects the data.

How a lock travels:

• The request is queued, not pushed. The agent polls for commands every few minutes while the machine is online and reports back what it did, so the request shows as Waiting for the device, then Picked up by the agent, then Locked or Failed.
• A request the agent has not fetched yet can be withdrawn. One nobody fetched within a day is withdrawn automatically: a laptop that resurfaces weeks later must not lock itself over a stale order. One the agent picked up but never reported back on is closed as Failed a day later, so a machine that went offline mid-lock can be locked again.
• Every request and withdrawal is written to the device's History with the administrator's name, and the agent's own window tells the employee, for a day afterwards, when it locked the screen on request.
• Remote lock arrived with a new version of the agent's privacy disclosure. An agent whose owner has not yet accepted that version is handed no commands: the request waits (and is still withdrawn after a day), and the detail page says so. The owner accepts it in the agent's window after the update.

Phones have no agent and cannot be locked from here; their owners use the platform's own Find My service.

---

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 once they turn email on under Account → Notifications, where they also choose how often they hear about comments.