Shared gate phone or personal Android? A device-security plan for UK gate teams

Choose the operating model before choosing the handset

A security company may want one Android phone to stay at each gate. A premises operator may prefer guards to use their own devices. Both arrangements can record vehicles, but they create different responsibilities for updates, photographs, account access and a missing phone. Buying a handset without settling those responsibilities leaves the most important decisions to whoever starts the next shift.

This guide focuses on the device carrying the gate workflow, rather than repeating a general permissions or shift-handover policy. The primary sources below were checked on 18 October 2026. The gate-specific acceptance tests are practical recommendations, not a claim that any device or configuration is automatically secure.

Priority Service advertises Android vehicle capture, registration checking, permits, supervisor approvals and time-stamped IN and OUT records. Its published descriptions do not promise mobile-device management, remote wiping, kiosk mode or Android Work Profile integration. Those are separate deployment questions to test and agree.

Decide who owns, maintains and recovers the phone

For a fixed gatehouse, an organisation-owned handset is a sensible starting point to evaluate: the organisation can assign maintenance, keep the device on site and provide a known replacement. That is an operational recommendation, not a guarantee of better security. A company phone left unlocked beside a public-facing window remains poorly controlled.

Write down the device owner, asset reference, assigned gate, support contact and person authorised to change its settings. Agree who pays for connectivity, replaces a broken charger and checks that security updates still arrive. For a guarding contractor, establish whether the client or contractor owns each responsibility; the uniform worn by the user does not settle ownership.

If personal phones are allowed, define eligibility, work-data separation, support boundaries and what happens when a guard declines, changes phone or leaves. Provide an alternative route for doing the job. Do not make a personal Google account the only recovery route for an organisation-owned handset.

Separate possession of the handset from identity in the app

A shared physical phone does not require one shared application identity. Priority Service's published demonstration describes each guard signing in with their own account. Test that arrangement using two fictional guard accounts on the same intended device, rather than demonstrating everything through an administrator login.

Have the first guard complete a fictional movement and follow the agreed sign-out procedure. Then have the second guard sign in, check the displayed site and gate, and record another movement. Ask an authorised administrator to confirm which guard is associated with each record. If attribution is unclear, resolve it before live deployment.

The device unlock code is a different control from the app password. NCSC device guidance recommends a six-digit PIN or strong password and different credentials for different devices. Set an appropriate automatic lock and test it in the actual workflow. Do not keep app passwords on a label beside the screen or leave an administrator session ready for every relief guard.

Check support life as well as camera performance

A usable camera is only one purchasing test. NCSC advice on second-hand devices warns against models with no remaining manufacturer support, or support close to ending. Check the exact model's support position with its manufacturer, including any refurbished phones already held by the business. A working screen is not evidence of ongoing security support.

Google explains that Android version, security update status and Google Play system update status can be checked in Settings, and that update schedules vary by manufacturer, device and operator. Record those checks at acceptance. Do not assume two phones bearing the same Android branding receive updates for the same period.

Assign a maintenance window and an owner for checking failed updates. After a relevant update, run a short fictional capture, registration correction, IN and OUT test. Confirm the agreed app installation and update route with the supplier; do not install a replacement package forwarded through an unverified message just because it claims to fix a camera problem.

Treat Android management options as separate technology

Google describes a Work Profile as a way to separate work apps and data from personal apps and data. That can be relevant when evaluating personal-phone use, but it is not something to assume the gate app creates. Ask your IT provider how enrolment, support and removal would operate on the devices you intend to use.

For organisation-owned equipment, Android Enterprise dedicated-device management can restrict a device to selected applications. Google's documentation also describes management controls such as remote lock and wipe. These capabilities depend on the chosen management arrangement; they are not advertised Priority Service subscription features.

Test the complete configuration, including the camera, any required browser, connectivity and support route. A restriction that prevents vehicle photography or blocks the approved sign-in process defeats the deployment. Avoid accepting a generic statement that a management product 'supports Android' as proof that your particular gate workflow works within its policies.

Find out where photographs and reports actually go

Do not assume a photograph exists only in the vehicle record because it was captured from an app. During a controlled test, use fictional material and check the handset's gallery, downloads, sharing options and configured backup services. Ask the supplier which local files, caches or permissions matter for the actual installation. Record what is observed and what remains unconfirmed.

Set a clear rule against copying live gate photographs into personal messaging, email or cloud storage. If an authorised person needs a copy for an operational purpose, use the organisation's approved process. For reports downloaded through web administration, check the destination and who can open the file; an application permission does not govern every copy created afterwards.

Inspect lock-screen previews and the view from the public side of the counter. A locked phone may still display information through notifications, depending on configuration. Use the least revealing settings that allow the task to work, and keep the device in a controlled place when it is not being used.

Prepare a lost-device response that works without that phone

Give staff a reporting contact they can reach independently of the missing handset. The initial report should identify the device, when it was last seen, whether it was believed to be locked, which work accounts were active and what information might have been accessible. A missing device is both an equipment problem and a potential information incident.

Google's Find Hub guidance lists prerequisites for securing or erasing a device remotely, including power and connectivity. Its erase guidance also warns that SD cards may not be erased. If your organisation uses that service, or an enterprise management alternative, establish authorised access and limitations in advance. A button labelled erase is not proof that a particular lost phone has received the instruction.

Have the responsible administrator check what account or session containment the application actually supports, alongside device-level action. Refer possible personal-data exposure promptly to the organisation's privacy lead. The ICO requires a risk assessment; reportable breaches must be notified without undue delay and, where feasible, within 72 hours of awareness. High-risk cases also require notification to affected people without undue delay. Do not wait for a phone to reappear before escalating.

Protect recovery access and retire devices deliberately

The person authorised to manage a phone needs a recovery route that survives its loss. NCSC account guidance recommends passkeys where available, or strong unique passwords with two-step verification, and recognises the need to consider backup methods. Apply those principles to the business accounts managing devices. Do not store the only recovery method on the handset it is meant to recover.

These are account-management recommendations, not claims that Priority Service supports passkeys or any particular second factor. Confirm the actual authentication and recovery options for each service separately. Keep privileged recovery information away from the shared gate workspace and assign a deputy who can follow the approved process.

Before selling, returning or reallocating a device, identify information that must be preserved, remove work access through the appropriate service controls and follow the manufacturer's erasure instructions. NCSC second-hand-device guidance recommends checking backups and recovery dependencies before resetting. Do not treat deleting a shortcut or removing an app icon as proof that all work information has gone.

Rehearse the failure before accepting the deployment

Use a fictional exercise: a relief guard takes over a warehouse gate, finds the usual phone missing and is offered an old spare. No real loss or customer case is implied. The supervisor should be able to identify the missing asset, contact the response owner and establish whether the spare meets the agreed update and configuration requirements.

Pass the exercise only when the team can explain who contains access, who assesses possible exposure and how recording continues under the site's authorised fallback. On the spare, prove that the relief guard uses their own app identity, reaches the correct gate and can complete a fictional visit. A charged battery alone is not acceptance.

Review the published app features at https://priorityservice.co.uk/#features and the setup arrangements at https://priorityservice.co.uk/setup-and-training. Request a demonstration at https://priorityservice.co.uk/#demo with the intended handset model and management policy. Ask to test shared use, sign-out, camera access and replacement-device setup. Buy a workflow your team can control, not merely a phone on which the first screen opens.

Vehicle logging for your operation

Explore the workflow, plans and demo options for your team.

Explore gatehouse management software