BYOD vs COPE: Choosing a Device Ownership Model You Can Defend

Choosing between bring your own device (BYOD) and corporate-owned, personally enabled (COPE) devices decides how much control you can enforce over the credentials and data on a phone or laptop, and how much privacy you owe the person carrying it. Under BYOD the employee owns the device and the organisation protects only its own apps and data; under COPE the organisation owns and manages the device but lets the user keep a private personal side. The related models, corporate-owned business-only (COBO) and choose your own device (CYOD), sit either side. This guide compares the models on threat model, management architecture, failure modes, controls and cost, then gives decision criteria and a worked scenario. It is for endpoint, identity and privacy leads choosing or revisiting an ownership model. Running a BYOD scheme once chosen is covered in the BYOD Security Programme guide, and management tool scope in MDM vs EMM vs UEM.

Platforms are listed alphabetically (Apple, Google, Microsoft); order is never a ranking.

Key takeaways

• Ownership sets the ceiling of control. On a personal device you can manage only a work container or managed apps; on a company-owned device you can enforce device-wide settings, prevent unenrolment and wipe the whole device.
• COPE is not "BYOD with a free phone". Modern COPE (Android company-owned work profile, Apple devices enrolled through Automated Device Enrollment) keeps personal data private while giving IT device-level policy, which BYOD cannot.
• Tokens decide the risk more than data does. Device-bound session tokens and hardware-backed keys need a device you manage on some platforms, so the most sensitive access usually belongs on COPE or COBO devices.
• Privacy obligations exist under every model. COPE devices still carry personal data; publish what IT can see for each model and do not collect more than the policy says.
• Most organisations need a mix. Choose by role and data tier: BYOD with app protection for broad access, COPE for regulated or privileged roles, COBO or dedicated devices for frontline and single-purpose use.

The four ownership models defined

NCSC's BYOD guidance puts the key point plainly: device management matters more than ownership, and if users agree to full management of their own devices, those devices effectively become corporately issued. In other words, the labels are shorthand for a management scope, and the scope is what security depends on. NIST SP 800-124 Rev. 2 (May 2023) likewise covers both organisation-provided and personally owned deployment scenarios in one lifecycle.

BYOD in depth

Threat model

• Unknown device state: the organisation cannot enforce OS updates, disk encryption settings or which other apps run, only check them at sign-in and block access.
• Data drift into personal apps: copy, paste, save-as and share sheets move corporate data outside the managed boundary unless app protection blocks them.
• Session and token theft: on personal laptops an infostealer captures browser cookies and refresh tokens for every site (ATT&CK T1539 Steal Web Session Cookie, replayed as T1550.004). Phones are less exposed but not immune.
• Weak offboarding: a leaver keeps the hardware; the organisation must rely on selective wipe and token revocation landing correctly.

Architecture in words

Corporate access runs through managed apps or a work container. Conditional access at the identity provider checks the app, platform and compliance signals at sign-in. Data at rest stays inside the app sandbox or work profile, encrypted, and is removed by selective wipe. Google describes the personally-owned work profile as giving the organisation no visibility or access to the personal profile; Apple says User Enrollment lets IT manage the organisation's accounts, settings and information, never the user's personal account, and that only a limited set of payloads and restrictions apply because the user owns the device.

Failure modes

• Bypass through unmanaged clients: users sign in from the native mail app or a personal browser because conditional access only required app protection on some platforms.
• Enrolment refusal: NCSC warns that a scheme that makes work harder or hurts work-life balance pushes staff to shadow IT, which is worse than the risk the controls address.
• Personal laptops treated like phones: app protection works well on iOS and Android but personal desktops need a protected browser or a remote session.

Controls that fit BYOD

App protection policies with copy, paste and save restrictions, minimum OS checks, jailbreak and root detection, conditional access requiring approved apps, short sign-in frequency for unmanaged laptops, and a published visibility statement. The level-by-level settings and rollout are in the BYOD Security Programme guide and the BYOD Policy Template; they are not repeated here.

COPE in depth

Threat model

• Same user, more leverage: the device is owned and enrolled, so the main risks shift to misconfiguration of a powerful console and to personal-side apps sharing the hardware with work data.
• Console as a single point of failure: device-wide control includes device-wide wipe, which is why the management platform itself must be hardened. See the MDM and UEM platform health check.
• Privacy and trust erosion: users may assume IT sees everything and avoid the device, or IT may switch on collection (location, app inventory of personal apps) that the policy never promised.

Architecture in words

The device is enrolled from first boot through a zero-touch or automated enrolment service, so the user cannot skip or remove management. On Android, Google describes the company-owned work profile as full management of work apps, data and settings plus many device-wide policies, such as Wi-Fi configuration and blocking USB file transfer, with the ability to restrict the personal profile (for example disallowing certain apps), while personal apps, data and usage are not visible to the organisation. On Apple devices, Automated Device Enrollment lets the organisation use all Apple-defined payloads and restrictions, require a minimum OS version, require FileVault on macOS 14 or later, hold the device in Setup Assistant until critical configuration is applied and, with "Prevent unenrollment", stop the user removing management on a supervised device. Personal use then happens in the personal profile on Android or alongside managed apps and accounts on Apple devices.

Failure modes

• Treating COPE as COBO: collecting personal-side data because the technology allows device-level visibility, then facing an employee complaint or regulator question.
• Enrolment gaps: devices bought outside the reseller channel never appear in the zero-touch or automated enrolment service, so they arrive unmanaged and are later "enrolled" in a weaker personal mode.
• Personal space blind spots: Microsoft's documentation notes that Intune treats Android 15 private space as a personal profile and does not manage it, so a COPE design must not assume every space on the device is in scope.
• Cost surprises: hardware refresh, loss and repair, carrier contracts and support all move to the organisation.

Controls that fit COPE

• Zero-touch or automated enrolment only: assign every purchased device to the enrolment service through the reseller so management cannot be skipped.
• Device-wide baselines: passcode, encryption, OS update deferral limits, USB data restrictions and factory reset protection.
• Personal-side restrictions kept minimal: block only apps that create a clear risk, and write each restriction into the user notice.
• Hardware-backed device identity: issue device certificates into the managed keystore and use compliance state in conditional access.

Platform modes side by side

Each platform vendor names its own modes; this table maps them to the ownership models. Settings and availability change, so confirm against the linked vendor documentation.

Availability: Apple's Automated Device Enrollment uses Apple Business or Apple School Manager with a device management service. Android Enterprise modes need a Google Mobile Services Android build that supports Android Enterprise in the user's country or region. Microsoft notes that the afw#setup and NFC enrolment methods for corporate-owned work profile work only on Android 8 to 10, not Android 11 and later. For deeper platform settings see the iOS and iPadOS Enterprise Security Guide, the Android Enterprise Security Guide and the Microsoft Intune Guide.

Control versus privacy: what each model lets you do

Owning the hardware does not remove data protection duties: monitoring of workers still needs a lawful basis, transparency and proportionality whoever owns the device. The privacy boundary design work, including UK ICO guidance, is covered in the BYOD Security Programme guide.

Credential and token exposure on devices

The question that most often decides the model is not "where is the data" but "where do the credentials live and can they be lifted". A phone or laptop carries refresh tokens, session cookies, platform SSO credentials, passkeys, VPN and Wi-Fi certificates and, for technical staff, SSH keys and API tokens.

• Device-bound tokens need a managed device on some platforms. Microsoft's Conditional Access token protection binds sign-in session tokens to the device so a stolen token cannot be replayed elsewhere. Microsoft documents it as generally available for native Exchange Online, SharePoint Online and Teams clients on Windows, iOS and iPadOS, and macOS, but on iOS, iPadOS and macOS it requires MDM-managed devices with the Microsoft Enterprise SSO plug-in (or Platform SSO on macOS). Windows devices can be Entra joined, hybrid joined or registered. That makes it a COPE or COBO control on Apple devices.
• Browser sessions can be bound to hardware too. Google Chrome's Device Bound Session Credentials generate a key pair at login, store the private key in secure hardware such as a TPM when available, and require proof of that key to refresh short-lived cookies, so a copied cookie cannot keep the session alive elsewhere. Google notes it falls back to normal behaviour on devices without secure key storage, and that malware present at registration might still extract the key. It works on any device running a supporting browser, so it helps on BYOD laptops, but it depends on each site adopting it.
• Hardware-backed keys and attestation: certificates and passkeys stored in the device's secure hardware resist copying under every model, but only a managed device lets you require attestation and revoke the device identity centrally. See the Device Trust vs User Authentication guide.
• Non-human credentials stay off personal devices. API keys, service account secrets, cloud access keys and SSH keys used by automation should never sit on a BYOD device; where engineers need them on a mobile or laptop, use a COPE or COBO device with managed secret storage. See the Infostealer Logs and Session Token Abuse Guide.

Decision criteria

Small and large organisations: a small organisation usually runs BYOD with app protection for everyone and buys COPE devices only for the handful of people with admin or finance approval rights. A large organisation tiers by role, adds CYOD catalogues for COPE to keep the hardware estate supportable, and keeps COBO or dedicated devices for frontline staff.

Worked scenario: a professional services firm of 2,000 staff

1. Starting point: everyone uses personal phones with app protection; partners and IT admins also use them for privileged approvals and admin portals.
2. Problem found: a review shows admin sessions on personal iPhones cannot use device-bound tokens because those require MDM-managed Apple devices, and two admins keep cloud CLI tokens on personal laptops.
3. Decision: keep BYOD with app protection for 1,850 consultants (email, Teams, document apps). Move 120 partners, finance approvers and IT admins to COPE phones through automated enrolment, with token protection enforced for their sessions. Give 30 reception and facilities staff dedicated shared devices.
4. Privacy: publish a COPE visibility statement (work profile or managed accounts only, no personal app inventory, location off) and update the DPIA.
5. Credentials: remove cloud CLI tokens from personal laptops; admins use COPE laptops with managed secret storage and privileged access workstations for console work.
6. Result to measure: zero privileged sign-ins from unmanaged devices within one quarter, with no fall in consultant enrolment.

Moving between models

1. Map roles to models: use the decision table to assign each role group a model and a data ceiling.
2. Measure today: pull sign-in logs by device management state, platform and app to see who actually uses what.
3. Prepare procurement and enrolment: link reseller accounts to the automated or zero-touch enrolment service before buying COPE devices.
4. Pilot in report-only: build conditional access rules requiring a compliant or managed device for the target roles in report-only mode, and pilot COPE devices with one team.
5. Cut over by ring: issue devices, enforce the rule per group, then selectively wipe and revoke tokens on the old personal devices for those apps.
6. Roll back: keep a time-limited exclusion group so a user whose COPE device fails can return to app-protected BYOD access while it is fixed.

Detection and measurement

• Sign-ins by management state: privileged and regulated-app sign-ins from unmanaged or personally-owned devices (target zero for COPE-only roles).
• Enrolment integrity: company-owned devices not enrolled through the automated or zero-touch service, and devices that report personally-owned enrolment despite company ownership.
• Token replay signals: token protection failures and sign-ins from a new device using an existing session.
• Leaver completion: time from HR leaver event to device return or selective wipe plus token revocation.
• Enrolment and satisfaction: BYOD enrolment rate and support tickets, to catch drift to shadow IT.

Common failure patterns

• Choosing by cost alone: a BYOD-only policy saves hardware money but leaves privileged sessions on devices where tokens cannot be bound.
• Full management of personal devices: it fails on enrolment rates and privacy, and NCSC notes such devices have effectively become corporate anyway.
• COPE without a privacy notice: owning the hardware does not remove monitoring obligations.
• Company devices enrolled as personal: devices bought outside the reseller channel end up in BYOD modes and lose device-wide controls.
• Machine secrets on phones and personal laptops: API keys and SSH keys travel to devices that infostealers target. See the Infostealer Threat Guide.

Framework mapping

Practitioner checklist

• Assign every role group an ownership model and a data ceiling.
• Require a managed or compliant device for privileged and regulated access.
• Enrol all company-owned devices through the automated or zero-touch service only.
• Publish a visibility statement for each model, COPE included, and keep collection within it.
• Use device-bound tokens where your identity provider and platform support them.
• Keep API keys, SSH keys and service account secrets off personal devices.
• Make leaver runbooks cover wipe and token revocation for every model.
• Review the model mix yearly against sign-in data and incidents.

Standards and references

• NIST: SP 800-124 Rev. 2 Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NCSC: Bring Your Own Device guidance
• Google: Device Bound Session Credentials
• Apple: Automated Device Enrollment and device management
• Apple: User Enrollment and device management
• Google: Android Enterprise overview
• Microsoft: Set up Intune enrolment for Android Enterprise corporate-owned work profile devices
• Microsoft: Token protection in Conditional Access

Related NHI Mgmt Group resources: BYOD Security Programme · MDM vs EMM vs UEM · Mobile Device Security Guide · Conditional Access Guide