Protecting your mobile devices with geo-fencing

Corporate-owned and BYOD handsets and tablets carry real company data — mail, documents, credentials, access tokens. The device is replaceable. What is on it usually is not.

Geo-fencing is one control for that problem. It is a narrow control, and it is worth being precise about what it does, because it is frequently oversold.

What a geo-fence actually is

A geo-fencing site is a circle on the map: a latitude, a longitude and a radius in metres. You define it either by drawing it in the map browser or by entering the coordinates and radius directly. Both routes produce the same record.

There are practical limits worth knowing before you start drawing. A site must have a radius of at least 100 metres, and should not exceed 10 kilometres. That immediately rules out fencing a single room, a ward or a floor. The workable unit is a building, a depot, a campus or a customer site.

Sites are attached to an MDM configuration rather than to individual devices, and devices inherit the sites from the configuration they are assigned to. One configuration can carry several sites, which is how you handle a field team that legitimately moves between six known locations. Change a site’s boundary and the configuration is automatically re-pushed to every device using it.

One caveat that catches people out: once a site has been linked to a configuration, or once a device event has been recorded inside it, the boundary is locked. To change it you delete the site and re-create it. Get the boundaries roughly right the first time.

How a violation is detected

Enrolled devices report their position on sync: a timestamp, a latitude, a longitude, and — importantly — an accuracy figure in metres.

That accuracy figure is used, not ignored. The distance from the device to each of its assigned sites is calculated, the device’s own reported accuracy is subtracted from it, and the device is matched to the nearest site whose radius still covers it. A device sitting near a boundary with a poor GPS fix is given the benefit of the doubt rather than generating a false alarm at three in the morning.

If no assigned site covers the device, that is a violation.

What happens next — and what does not

This is the part the original version of this post got wrong, so it is worth stating plainly.

When a device is found outside all of its assigned sites:

• The device’s compliance status gains a geo-fence violation flag, and its geo-fence compliant indicator flips to false. If that was the only outstanding issue, the device also stops being compliant overall.
• The last position recorded outside the fence is retained — time, latitude, longitude and accuracy.
• The site history is closed off: the platform records an exit time against the site the device was last inside, so you have entry and exit times per device per site rather than a single current state.
• An alert email goes to the recipients configured against that MDM configuration, naming the user, their email address, the device manufacturer and model, and where and when it was last seen outside the fence. If no alert recipients are set on the configuration, no alert is sent — worth checking before you rely on it.

What does not happen is an automatic wipe. Locking the device, wiping it, clearing the password and unenrolling it are all available, and any of them can be issued from the same console that raised the alert — but they are commands a person issues, not consequences that fire on their own. That is a deliberate design decision. A wipe triggered by a GPS glitch is an incident in its own right.

So the honest description is this: geo-fencing gives you detection, evidence and a fast path to a response. It does not give you an automated destruction policy, and you should be sceptical of anything that claims it does.

Where it earns its place

The obvious case is deterrence and recovery. A device that has left its site is flagged within one sync cycle, with a last known position attached. That is materially better than finding out at the end of the week that a tablet is missing and having no idea when or where it went.

The less obvious case is the site history. Entry and exit times per device per site accumulate into a usable record of where equipment has actually been — which is the sort of thing that becomes valuable during an incident review, an insurance claim or an argument about which department lost the kit.

An illustration. A hospital trust issues tablets that are meant to stay on its sites. Fence each hospital campus, assign the sites to the configuration those devices use, and set the alert recipients to the service desk. A tablet that leaves is flagged with a last known position and a time, and the service desk decides whether that is a clinician who took the wrong bag home or something that warrants a remote wipe. Nobody has to notice a gap in a cupboard first.

Note that this works at campus scale, not ward scale. If your actual requirement is “this device must not leave this room”, geo-fencing is the wrong tool and you want a physical control.

Fitting it into the wider picture

Geo-fencing is one flag among several. The same compliance model tracks whether a device is jailbroken or rooted, whether it has blacklisted applications installed, whether its password meets policy, and whether location reporting is even available.

That last one matters more than it sounds. A device can only be geo-fenced if it is reporting location, and the platform records per device whether geo-fencing was available at the last sync, unavailable, or could not be determined. A user who has quietly revoked location permission shows up as a location compliance problem rather than silently dropping out of the scheme. Without that, a geo-fencing programme degrades invisibly.

Device ownership is modelled as corporate or BYOD, and the two are handled separately — you can re-deploy geo-fencing configurations to corporate devices specifically. Location tracking on a personally owned phone is a different conversation with your works council and your data protection officer than it is on a company-issued one, and the tooling should not force you to treat them identically. It does not.

Implementing it

Geo-fencing ships as part of mobile device management in CerteroX ITAM, alongside iOS and Android enrolment, Apple DEP, configuration profiles, application deployment and the device commands described above. The same platform holds your laptops, servers, virtual machines and Unix systems, so a mobile device is a record in the same inventory as everything else rather than a separate island with its own console.

A sensible order of work:

1. Enrol devices and confirm they are actually reporting location. Check the geo-fencing availability status before you build anything on top of it.
2. Define sites at campus or building scale. Confirm the boundaries before you link them, because you cannot edit them afterwards.
3. Set alert recipients on the configuration. An unconfigured recipient list is the single most common reason a geo-fencing deployment produces nothing.
4. Decide, in advance and in writing, who is authorised to issue a wipe and on what evidence. The tooling will not make that decision for you, and you do not want to be making it for the first time at eight on a Friday evening.

To see geo-fencing sites, the compliance flags and the device command set on a populated enrolment, book a demo.