Every audit eventually reaches the laptops. The auditor wants to know that the devices your staff use to reach customer data meet a standard: encrypted, locked when idle, protected by a firewall, kept up to date. The question for the team is how to show it.
There are two broad approaches. Mobile device management (MDM) enrolls each device into central control and enforces settings on it. A lightweight endpoint agent runs on the device and reports whether it meets the standard, without taking control. Both can satisfy an auditor. They differ in cost, intrusiveness, and what happens when a device falls out of line.
This article covers what each approach does, what auditors actually need from endpoints, how the two compare, when each is the right choice, how to combine them, and the privacy questions personal devices raise.
What each one does
MDM is a management channel built into the operating system. Once a device is enrolled, an administrator can push configuration profiles, require encryption, set password and lock rules, install or remove applications, and lock or wipe the device remotely. Settings are enforced: the user cannot turn them off.
A lightweight endpoint agent is an application the user installs. It reads the device's security settings and reports them to a central service: whether the disk is encrypted, whether screen lock is on, whether the firewall is enabled, what OS version is running. It typically does not change settings. Some agents prompt the user to fix a failing check, but the fix is the user's to make.
The core difference is preventive versus detective. MDM prevents a device from drifting out of compliance. An agent detects drift and relies on a process to correct it.
What auditors need from endpoints
Frameworks set the outcome and leave the mechanism to you. ISO 27001:2022 Annex A 8.1 covers user endpoint devices, and Annex A 8.7 covers protection against malware. SOC 2 reaches endpoints through CC6.1, CC6.7, which covers information moved or removed, and CC6.8, which covers preventing or detecting malicious software. None of them says "use MDM".
What an auditor will look for is:
An endpoint standard. A written baseline: encryption, screen lock timeout, firewall, OS update policy, anti-malware where your policy requires it.
A complete device population. Every device used to access in-scope systems, reconciled against your staff list.
Per-device status against the standard, from a system rather than from self-attestation, dated.
Handling of failures. What happens when a device falls out of line, and evidence that it happened.
Either approach can produce items two and three. The difference shows up in item four. With MDM, failures are rare because settings are enforced. With an agent, failures happen and you need to show they were followed up. Full-disk encryption on every laptop walks through the encryption part of this standard in detail.
How they compare
| MDM | Lightweight agent | |
|---|---|---|
| Control type | Preventive: enforces settings | Detective: reports settings |
| Setup effort | Enrollment, profiles, ongoing administration | Install and connect |
| Device ownership | Best suited to company-owned devices | Works on company and personal devices |
| User experience | Settings locked; some users find it intrusive | Prompts or reminders; user stays in control |
| Remote lock and wipe | Yes | Usually no |
| Operating systems | Strong on major desktop and mobile platforms; Linux support varies | Often broad, including Linux |
| Failure handling | Rare drift; enforcement does the work | Needs a follow-up process with deadlines |
| Evidence | Compliance reports from the management console | Per-device posture reports from the agent |
The table is a generalization. Individual products vary, and some agents can enforce settings while some MDM deployments are configured only to report. Decide based on which behavior you need, not on the label.
When MDM is the right answer
MDM earns its overhead when:
Devices are company-owned and you can require enrollment as a condition of use.
You handle regulated data on endpoints, such as ePHI, and need to be able to wipe a lost device and show you could.
Your staff are mostly non-technical, so relying on them to fix settings produces a long tail of failures.
You need to distribute or block software, not only check settings.
The team is large enough that chasing individual failures by hand costs more than administering enforcement.
When an agent is enough
A reporting agent is often the right starting point when:
The team is small and mostly engineers who will fix a failing check when asked.
Some staff use personal devices, where full device management is disproportionate.
Contractors need access on their own hardware.
Engineers run Linux, where MDM coverage is thinner.
The honest concession is that a detective control is only as good as its follow-up. If the agent reports a device without encryption and nothing happens for a month, the evidence shows a control that detects and does not correct. Define the response in your endpoint policy: a notification, a deadline measured in days, then restricted access to company systems until the device passes. Keep the record of each step.
Running both
Many organizations end up with a combination:
MDM on company-owned laptops, enforcing the standard.
An agent on personal devices, contractor devices, and Linux machines, reporting against the same standard.
One endpoint policy that defines the standard once and says which mechanism applies to which device class.
What the auditor needs is one complete population with one status per device, whichever mechanism produced it. If MDM and the agent report in different places, reconcile them into a single list before the audit, not during it.
Moving from one approach to the other is common as companies grow. A team that starts with a reporting agent often adds MDM when it reaches the point where chasing failures by hand takes real time, or when a customer contract requires remote wipe. If you expect that move, write the endpoint standard so it describes outcomes, such as "disk encrypted" and "screen locks after five minutes idle", rather than a mechanism. The standard then survives the change of tooling, and so does the comparability of your evidence across periods.
The same reasoning applies to OS updates. Whether they are enforced or reported, the evidence pattern described in patch management evidence applies: dated, recurring snapshots across the period.
Privacy and personal devices
Full MDM on a personal phone or laptop can give the company visibility and control far beyond what it needs, including the ability to wipe personal data. That is a reasonable concern for staff, and in some countries employee representatives must be consulted before monitoring tools are introduced. Check local requirements before rolling out device management to personal hardware.
Mitigations include work-profile or user-enrollment modes that limit management to company data, or a reporting agent that reads security settings only. Whatever you choose, write down what the company can and cannot see on a personal device, and tell staff before they enroll. For ISO 27001, that documentation supports Annex A 8.1, and it also helps with your obligations around personal data.
How TrustLynce helps
The TrustLynce device agent is a lightweight endpoint agent that reports encryption, firewall, screen lock, and patching status. Failing devices are routed to their owners through continuous monitoring, with each check dated, so the follow-up record exists alongside the detection.