It manages a thing. It affects a person

The thing and the person

Asset management acts on equipment in a building. Device management acts on an object in somebody's pocket, which they take home, which is present during private moments, and which in many cases they bought.

The practical question in “It manages a thing. It affects a person” is how to make work visible without confusing visibility with certainty. For teams researching employee monitoring software, employee monitoring software can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.

Every enrolment conversation is really about three questions, whatever is said formally: can you read my messages, can you see where I am, can you delete my photographs. Answering those three directly does more than any policy document.

For an independent baseline relevant to “It manages a thing. It affects a person”, the CISA mobile-device security guidance is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

And there is an asymmetry of belief underneath. Employees overestimate what is visible. Administrators sometimes overestimate what they are permitted. The gap between those two misunderstandings is where resistance comes from, and closing it is mostly a communication task rather than a technical one.

Ownership decides everything

The single variable that most determines what is permissible is who bought the hardware.

A corporate device issued for work only permits full management, full wipe and feature restriction. A device the employee bought and enrolled themselves permits considerably less, and increasingly the platforms themselves enforce that rather than leaving it to the employer.

Which means the question "can we do X" has no general answer. It is always "on which devices", and the device record should carry the ownership model so that the answer is available at the moment somebody is about to act.

What you can actually see

On a work profile: device model, operating system version, encryption and passcode state, jailbreak status, work applications installed, compliance state, last check-in.

Not visible: message contents in personal applications, photographs, personal files, browsing history in personal browsers, keystrokes, call contents, passwords. That list is the one to publish, because it addresses what people actually fear.

On a fully enrolled personal device the position is different and worse for the employee — several platforms expose the full application inventory, including personal applications. That reveals health, dating, religion, politics and finance, and in several jurisdictions touches special-category data. If your configuration collects it and you do not need it, stop: it is a configuration change that removes the problem entirely.

The work profile changes the argument

A work profile puts organisational applications and data in a container the employer manages and leaves the rest of the device outside it. The separation is enforced by the operating system.

That distinction is the whole thing. An employer saying "we will not look at your personal data" is asking to be trusted. A platform that does not expose personal data to the management channel is not asking for anything.

It resolves three objections at once: the visibility fear, because the personal side is not exposed by design; the wipe fear, because removal takes the container and cannot reach the rest; and the control fear, because no device-wide policy is applied.

Lead with it rather than with reassurance, and demonstrate removal on a test device in front of a sceptical colleague — it persuades more than any document.

The BYOD bargain

Bring your own device is presented as convenience and is actually an exchange. The organisation avoids purchase, replacement, repair, logistics and disposal. The employee gets one device instead of two, and frequently nothing else.

What the employee gives is less discussed. A work phone can be left in a drawer at the end of the day. A personal phone cannot. BYOD quietly extends the working day for most people who accept it, and no policy acknowledges it.

The concession that costs nothing is a stated position on out-of-hours contact: messages sent outside hours do not expect a reply outside hours, and the work profile can be silenced on a schedule. It addresses the objection people feel and struggle to articulate, and in several jurisdictions something like it is moving from courtesy towards right.

Enrolment fixes the boundary

Enrolment looks like a setup step. It is the decision that determines what the programme can do to a device for the rest of its life, and it cannot easily be changed afterwards.

A device registered with the manufacturer and enrolled at first power on permits the fullest management and cannot be removed by the user. A device the employee enrolled themselves permits less and can usually be unenrolled by them. A work profile sits between: the organisation manages a container and nothing else.

Which makes a point that belongs to procurement rather than to IT: devices bought from an ordinary retailer generally cannot join an automated enrolment programme later. The purchasing channel determines your options years afterwards, and whoever buys hardware is making a management decision without knowing it.

The mismatch to avoid is a personal device enrolled through a corporate route — usually because that route was simpler to configure. It is the technical decision that produces the hardest disputes.

Policy people will accept

One policy per ownership model, one page each. The commonest structural error is a single document covering corporate and personal devices, because what is reasonable on hardware you bought is not reasonable on hardware they bought.

Say what is not done, as well as what is. The list of what the organisation cannot see is the part people read and the part that decides whether the rest is believed, and most policies omit it entirely.

And set requirements proportionate to what you fund. Requiring a current operating system version on a device the organisation issued is reasonable; requiring it on one the employee bought is asking them to spend money.

On passcodes specifically, resist importing a desktop standard. A six-digit code on a device with hardware-backed rate limiting is substantially stronger than it looks, because guessing is throttled by the hardware. Long alphanumeric requirements on a device unlocked a hundred times a day produce exactly the behaviour you would expect, and blocking biometrics usually results in weaker underlying codes — the opposite of the intent.

And failed-attempt wipe is the setting most likely to destroy data by accident. A child, a pocket, a confused moment. On personal devices the data it destroys is not only yours.

What the programme should measure

Most device programmes report how many devices are enrolled, which measures adoption rather than effect.

The number that matters is the gap: devices enrolled against the population that should be. Identity logs usually show it — sign-ins from devices the platform does not know. That figure is the real exposure, and enrolment counts conceal it.

Then compliance by condition rather than overall, because a single condition failing widely is a finding about your policy rather than about everybody's carelessness. Version distribution and the time your estate takes to reach a new release, which describes your actual vulnerability exposure more honestly than any compliance percentage. And devices that have not checked in, which accumulate quietly — replaced hardware, people who left, devices in drawers — and inflate the enrolment count and the compliance rate at the same time.

The one action that cannot be undone

Everything else device management does can be changed back. A wipe cannot, and that asymmetry justifies treating it differently from every other capability.

Selective wipe removes work applications and their data and leaves everything else. Full wipe returns the device to factory state — photographs, messages, notes, anything not backed up elsewhere. On a personal device the second destroys a great deal that does not belong to the organisation.

The controls that belong around it are named individuals rather than a role, selective as the default, the ownership model displayed where the action is issued, and a confirmation that requires typing the identifier. But the strongest control is structural: on personal hardware, use a work profile so that full wipe is unavailable by platform design rather than by rule. Every procedural control depends on somebody being careful at exactly the moment they will not be.

And on a loss report, the first action is not a wipe but revocation — which works immediately, does not require the device, and is reversible when the phone turns up in a coat pocket.

What the core notes deliberately avoid

Product rankings inside the core notes. Vendor comparisons live in separate guides so the operational advice does not depend on a single platform.

No adoption figures, which come from surveys commissioned by the people selling the software.

And no claim that configuration substitutes for the conversation. No setting persuades somebody to enrol a device they own; the work profile makes the ask reasonable, and somebody still has to make it.