Choose Your Own Device (CYOD) is an IT provisioning model where employees select a device from a pre-approved list. The organisation still controls the supported hardware, operating system versions, enrolment settings, and mobile device management or endpoint security policies, while reducing the support burden of fully unmanaged personal devices.
What CYOD Means in Practice
Choose Your Own Device is a controlled mobility and endpoint model, not an open bring your own device programme. The organisation sets the approved device catalogue and the security baseline, then lets employees choose within those bounds.
The value of CYOD is that it gives users some choice without surrendering platform control. That matters because device standardisation makes support, patching, and security policy enforcement far more predictable than a fully ad hoc fleet.
How CYOD Changes Endpoint Security
CYOD usually sits between corporate-owned managed devices and BYOD. The security posture still depends on managed enrolment, enforced settings, and the ability to apply conditional access, compliance checks, and remote response where a device falls out of policy.
Because the hardware and operating system choices are pre-approved, security teams can reduce variation in encryption support, telemetry quality, patch cadence, and endpoint protection coverage. That makes it easier to set a single policy standard for device health and to keep unsupported configurations out of the estate.
For mobile fleets, NHIMG’s Mobile Device Security Guide is a useful companion for the control layers that typically underpin a CYOD programme.
Where CYOD Is Different from BYOD and COBO
CYOD is often chosen when an organisation wants a compromise between employee preference and tight operational control. Compared with BYOD, it gives the business stronger authority over the enrolment flow, managed apps, and wipe options. Compared with fully corporate-owned models, it can improve user satisfaction without abandoning security standards.
The practical distinction is governance. In CYOD, the organisation must define what is genuinely optional, what is mandatory, and how exceptions are handled. If those boundaries are vague, CYOD can drift into a pseudo-BYOD model where support expectations rise but control assumptions stay too optimistic.
That governance layer is why NHIMG’s BYOD Policy Template is still relevant, because the same questions about enrolment tiers, data separation, and offboarding often determine whether CYOD works cleanly in practice.
Operational Use Cases and Control Design
CYOD works best where the organisation can predefine a small set of models that are compatible with identity, endpoint protection, and collaboration tooling. The catalogue should be narrow enough to support standardised configuration, but broad enough to avoid a single-device bottleneck for the user base.
Most CYOD decisions are really control-design decisions: which devices are eligible, whether work profiles or containerisation are required, what local data can be stored, and whether loss or reassignment triggers selective wipe. Those choices determine how much residual risk the organisation accepts if a device is lost, stolen, or leaves compliance.
For baseline hardening and mobile policy design, CIS Benchmarks provide a practical reference point for aligning device settings to a known secure configuration.
Risk and Threat Considerations
CYOD reduces the chaos of unmanaged endpoints, but it can still fail if the approved device list is too broad or if security policy is weaker than the user experience promise. The main exposure is that a partially standardised fleet can create a false sense of control while leaving sensitive data on devices that are lost, stolen, or not properly enrolled.
Failure mechanism: weak enrolment, inconsistent policy enforcement, or a mismatch between approved hardware and required security features can leave endpoints outside the intended control set, especially where cached tokens, local data, or unmanaged apps remain on the device.
Impact: attackers or careless users can exploit the gap through device loss, session reuse, or policy bypass, leading to data exposure, account compromise, or a supportable but insecure fleet that is harder to detect and remediate than a fully managed one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | CYOD depends on knowing which approved devices exist and are in use. |
| Recommendation — Maintain an accurate device inventory and remove unsupported endpoints from the CYOD catalogue. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | CYOD device access still relies on strong user authentication to controlled services. |
| IA-3 — Device Identification and Authentication | CYOD often relies on recognised, enrolled devices as part of trust decisions. | |
| CM-6 — Configuration Settings | CYOD security is defined by enforced baseline settings across approved device types. | |
| Recommendation — Require strong user authentication before granting access from CYOD devices. Authenticate enrolled devices before allowing them onto managed resources. Standardise and enforce secure configuration settings for every approved CYOD model. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | CYOD requires asset visibility over the approved device estate and related ownership. |
| A.8.1 — User endpoint devices | CYOD is fundamentally an endpoint-device control model with managed configuration expectations. | |
| Recommendation — Keep the approved CYOD device estate inventoried and attributable to owners. Apply defined endpoint controls to all CYOD devices and verify they remain enforced. | ||
Practitioner Guidance
Governance implication: CYOD needs a clearly owned policy for catalogue approval, security baselines, and exception handling. The programme should define which operating systems, device classes, and enrollment modes are allowed, then tie those choices to enforcement rather than to user preference alone.
What to watch for: the most common failure is policy drift, where the approved list expands faster than security can validate it. If the model starts supporting many variants, the operational benefits of CYOD erode and the environment begins to resemble unmanaged diversity with a managed label.
Related resources from NHI Mgmt Group
- How should security teams choose between PKCE and device flow for CLIs?
- How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
- How should teams govern autonomous agents that can choose their own tools and timing?
- What breaks when an AI system can choose tools and actions on its own?