Mobile Device Management Policy Template: Corporate Devices, Enrolment and Wipe

A corporate phone or tablet that was never enrolled, can be unenrolled by its user, or is still locked to a former employee's personal account is an unmanaged device the organisation paid for. This template sets the rules for organisation-owned smartphones, tablets and other mobile devices from purchase to disposal: how they are enrolled so management cannot be removed, which management mode each use case gets, the minimum configuration, how compliance gates access, and when and how devices are locked, wiped, reissued and retired. Personally owned devices are out of scope and belong in the BYOD Policy Template. It is written for endpoint, IAM and security teams who need a policy they can adopt with light editing, and it assumes a mobile device management (MDM) or unified endpoint management (UEM) platform is already in place.

How to use this template

• Replace text in square brackets, such as [Organisation], [MDM platform] and [14 days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Decide the management mode for each device category first (section 4.2), because enrolment, privacy commitments and wipe scope all follow from it.
• Keep platform settings (passcode length, update deferral, restriction payloads) in a separate [Mobile configuration standard] so the policy does not need re-approval each time a vendor changes a setting. The NCSC publishes recommended platform configurations that make a useful starting point.
• Read it alongside the Mobile Device Management Security Guide, which covers securing the MDM platform itself, and the Lost or Stolen Device Response Checklist.

1. Purpose

This policy makes sure every mobile device owned by [Organisation] is enrolled in central management before it reaches its user, stays enrolled for its whole life, meets a defined security baseline before it can reach [Organisation] data, and is wiped and released correctly when it is lost, reassigned or retired. It supports the device lifecycle approach in NIST SP 800-124 Rev. 2, which covers deployment, use and disposal of organisation-provided mobile devices.

2. Scope

This policy applies to all smartphones, tablets and other mobile devices purchased, leased or otherwise provided by [Organisation], whoever uses them, including employees, contractors and shared or kiosk use. It applies to every operating system [Organisation] supports, currently [iOS and iPadOS, Android, other].

Out of scope: personally owned devices (see the [BYOD Policy]); laptops and desktops, which are covered by the [Endpoint Security Policy] even where the same UEM platform manages them; and operational technology handhelds governed by [OT security policy], unless listed in Annex A.

3. Roles and responsibilities

4. Policy statements

4.1 Procurement and enrolment

1. Organisation-owned mobile devices must be enrolled through the vendor's automated enrolment programme: Apple Business Manager (or Apple School Manager) Automated Device Enrollment for iOS and iPadOS, Android zero-touch enrolment or Samsung Knox Mobile Enrollment for Android, as listed in the [Mobile configuration standard]. The NCSC strongly recommends that large organisations use zero-touch enrolment programmes for their devices.
2. Procurement must require resellers and carriers to assign new devices to [Organisation]'s programme accounts at the point of sale, so devices enrol automatically at first setup and arrive sealed.
3. Enrolment profiles must prevent the user from removing management. On Apple devices this means supervised enrolment with the option to prevent unenrolment; on Android it means the fully managed or company-owned work profile mode provisioned by zero-touch.
4. Enrolment must enforce the minimum operating system version, so a device below it updates before setup completes.
5. Devices that cannot use an automated programme (for example, purchased outside approved channels) must be enrolled manually by [IT endpoint team] using [QR code, NFC or token enrolment for Android; Apple Configurator for Apple devices], recorded as an exception, and added to the programme account where the vendor allows it.
6. Existing devices should be retrospectively added to the enrolment programme, so a wiped device re-enrols automatically.
7. Devices must not be issued to users until enrolment has completed and the device reports as compliant.

4.2 Management modes

1. Each device category must use one of the management modes below, recorded in Annex A. The mode must be chosen by use case, not by user preference.
2. Where personal use of a corporate device is permitted, the company-owned work profile (Android) or an equivalent separation must be used, and section 4.6 applies.

4.3 Minimum configuration

1. All devices must meet the baseline in the [Mobile configuration standard], which must include at least the controls below.
2. A device passcode of at least [6 digits], with biometric unlock permitted, automatic lock after [5 minutes] of inactivity, and erase or lockout after [10] failed attempts.
3. Device encryption on (enforced by the operating system on current Apple devices; verified by compliance policy on Android).
4. Applications installed only from [the managed app store and approved private apps]; sideloading, unknown sources and developer options disabled.
5. Jailbroken, rooted or integrity-failed devices must be treated as non-compliant (section 4.5).
6. Work email, Wi-Fi, VPN and certificates must be delivered as managed configuration, not set up by hand. Corporate data must not be copied from managed apps to unmanaged apps.
7. Backup of corporate data to personal cloud accounts must be blocked; on fully managed devices, personal accounts and personal cloud backup must be disabled.
8. Mode A devices for privileged users must also meet the [high-risk user profile], which may include platform hardening such as Lockdown Mode or Android Advanced Protection where compatible with business apps.

4.4 Updates and supported platforms

1. Operating system and app updates must be applied automatically and enforced through [MDM platform]. Security updates must be installed within [14 days] of release, and within [72 hours] for updates that fix actively exploited vulnerabilities. The NCSC recommends installing updates ideally within a few days and keeping pre-release testing short.
2. [IT endpoint team] must monitor update status through MDM reporting, because users can defer updates and automatic updates can silently fail.
3. Only device models and operating system versions still receiving security updates from their vendor may be used. Devices must be replaced before the vendor's end of security support, and procurement must consider the vendor's stated support period when buying.

See the Mobile OS Update Management Guide.

4.5 Compliance and access

1. Every enrolled device must be assigned a compliance policy covering at least: minimum OS version, passcode, encryption, integrity (not jailbroken or rooted) and, where a mobile threat defence tool is in use, threat level.
2. The tenant-wide default must treat devices with no compliance policy as non-compliant, and devices that have not reported compliance within [7 days] must be treated as non-compliant.
3. Access to [Organisation] email, collaboration, line-of-business apps and VPN from mobile devices must require a compliant, managed device as a condition in [identity provider].
4. Non-compliant devices must follow the escalation in the table below.

See the Device Trust and Posture Guide and the Conditional Access Guide.

4.6 Privacy and acceptable use

1. Corporate devices are provided for [Organisation] business. Personal use is [not permitted / permitted under Mode B only] and is subject to the [Acceptable Use Policy].
2. [Organisation] will collect only the device data listed in the [mobile privacy notice] needed for security and asset management, such as model, serial number, operating system version, compliance state, installed managed apps and, for Mode A and C devices, the full app inventory.
3. Location data must only be collected when a device is reported lost or stolen, or for Mode C devices where documented in Annex A, and must be approved by [DPO].
4. On Mode B devices [Organisation] must not access the personal profile, personal apps or personal content.
5. Users must be told before issue that a lost, returned or non-compliant device may be wiped, and that personal data on a corporate device may be lost.

4.7 Lost, stolen and compromised devices

1. Users must report a lost or stolen device to [service desk] within [1 hour] of noticing.
2. [IT endpoint team] must put the device into lost mode or lock it, and [IAM team] must revoke the user's sessions and refresh tokens, within [1 hour] of the report.
3. The device must be wiped once recovery is judged unlikely, and no later than [24 hours] after the report. Remote wipe works only when the device is powered on with a data connection, so session revocation must not wait for the wipe to succeed.
4. Suspected compromise (spyware, unknown profiles, integrity failure on a device that previously passed) must go to security operations before any wipe, so they can decide whether forensic capture is needed.
5. Certificates, VPN profiles and any credentials issued to the device, including those used by apps or automation on Mode C devices, must be revoked and reissued.

See the Remote lock and wipe for lost phones and laptops and the Mobile Forensics Guide.

4.8 Reassignment, return and disposal

1. Leavers must return corporate devices on or before their last day. Line managers must confirm recovery; unreturned devices must be locked and then wiped within [5 working days].
2. Before reassignment a device must be fully erased and re-enrolled through the automated programme, never handed on with the previous user's profile.
3. Activation Lock and Android factory reset protection must not be able to lock a corporate device to a personal account. On supervised Apple devices, organisation-linked Activation Lock or the disallowed default must be used, and [MDM platform] must retrieve and store the bypass codes. Apple states these codes are retrievable for up to 15 days after the device is first supervised, so retrieval must be verified at enrolment.
4. When [Organisation] changes MDM platform, Activation Lock bypass codes must be transferred or locks cleared before the old platform is decommissioned.
5. Devices leaving [Organisation] (sale, trade-in, lease return, recycling) must be erased with the platform's secure erase, removed from management, released from the enrolment programme account, and have Activation Lock or factory reset protection cleared. Where data must be unrecoverable with certainty, follow the [Media sanitisation standard], which may require destruction.
6. Disposal must be recorded in the asset register with date, method, and certificate of destruction where a third party is used.

4.9 Management platform and administrators

1. [MDM platform] administrator roles must follow least privilege, use phishing-resistant MFA, and be reviewed every [quarter]. Bulk wipe, bulk retire and script deployment must require a second administrator's approval where the platform supports it.
2. Enrolment programme accounts (Apple Business Manager, zero-touch portal, Knox portal) and the MDM's tokens and push certificates must have named owners, at least two administrators, and renewal dates tracked in [calendar or ticket system]. An expired Apple push certificate or enrolment token stops management of the fleet.

5. Exceptions

Exceptions must be requested through [GRC tool], state the business reason, the compensating controls and an expiry date of no more than [6 months], and be approved by [CISO]. Devices that cannot be enrolled in central management must not access [Organisation] data.

6. Compliance and monitoring

[IT endpoint team] must report the measures below to [Security steering group] [monthly]. Breaches of this policy may lead to loss of device access and action under the [Disciplinary Policy].

7. Review and approval

This policy must be reviewed at least [annually], and after a significant change to [MDM platform], a new device platform, or an incident involving a corporate mobile device.

Owner: [CISO]. Approved by: [Approver]. Version: [1.0]. Date: [date]. Next review: [date].

Implementation guidance

Rolling it out

1. Reconcile first: compare the asset register, carrier and reseller invoices, the enrolment programme accounts and [MDM platform]. Devices in one list but not the others are your unmanaged estate.
2. Fix procurement: link reseller and carrier customer IDs to your programme accounts so new devices arrive pre-assigned. This single change stops most future enrolment gaps.
3. Pilot the profiles: build enrolment and compliance profiles per mode, then test with IT staff, confirming unenrolment is blocked and Activation Lock bypass codes are escrowed.
4. Turn on enforcement in stages: run compliance in report-only mode, fix the common failures (old OS, missing passcode), then switch the tenant default to non-compliant and require compliant devices in [identity provider]. Keep a documented rollback: set the access policy back to report-only if a business-critical app breaks.
5. Migrate legacy devices: wipe and re-enrol older manually enrolled devices through the automated programme during refresh, starting with privileged users.

Decision guidance

• Small organisations: a single mode (A) for all corporate phones, with one compliance policy per platform, is simpler to run and audit than mixing modes.
• Large organisations: use Annex A to map device categories to modes, and make Mode B an explicit opt-in so privacy commitments are clear.
• Corporate device or BYOD: where a role needs certificates, privileged access or regulated data, issue a corporate device rather than stretching BYOD controls. See BYOD vs COPE.

Common failure patterns

• Manual enrolment as the norm: users can remove the management profile, and wiped devices do not re-enrol.
• Compliant by default: leaving the tenant setting that marks devices with no policy as compliant means an unassigned device passes the access check.
• Wipe before revoke: waiting for a remote wipe on a powered-off phone while its tokens stay valid.
• Locked returns: leavers' devices locked to personal Apple Accounts or Google accounts and unusable, because bypass codes were never escrowed.
• Expired certificates: an unowned push certificate or enrolment token expires and the fleet stops checking in.

Framework mapping

Standards and references

• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NCSC: Device Security Guidance, Zero-touch enrolment
• NCSC: Device Security Guidance, Keeping devices and software up to date
• NCSC: Device Security Guidance, Erasing devices
• Apple: Automated Device Enrollment
• Apple: Activation Lock on Apple devices
• Google: Android Enterprise overview, management modes
• Microsoft: Intune device compliance policies

Related NHI Mgmt Group resources: Mobile Device Security Guide, Apple Business Manager Security, Android Enterprise Security Guide, MDM and UEM platform rollout playbook.