Dedicated vs Fully Managed Android Devices: What Is the Difference?

The Short Answer

In Android Enterprise, a fully managed device and a dedicated device are both corporate-owned and both provisioned so that the device policy controller (DPC) is set as device owner. Device owner is the part that matters: the organization controls the whole device rather than a work container placed beside personal use. The difference between the two is intent, not privilege. Fully managed describes a work-only device issued to a named person, who signs in and works inside a set of organization-controlled apps. A dedicated device — the mode still widely referred to by its older label COSU, corporate-owned single-use — is that same fully managed device narrowed to one task or a tight set of tasks, usually unattended, shared or customer-facing. So a dedicated device is always fully managed; a fully managed device is not always dedicated. A work profile is the third shape and a materially different one: there the DPC is profile owner, control stops at the work container, and the personal side of the device stays outside organization policy. Google’s Android Management API documentation treats these as separate management modes, and the distinction that actually binds is the ownership one: whether the device is provisioned into device owner or into a work profile is fixed by the enrollment route and cannot be changed afterwards from a console. Within device owner, the fully managed and dedicated shapes are a policy question rather than a provisioning one, which is why the mode change costs described later in this guide differ so sharply. This guide keeps to that terminology so that a mode written into a purchase specification means the same thing to the EMM administrator, the app team and the approver signing the order.

What Fully Managed Means

A fully managed device is corporate-owned hardware on which the management platform acts as device owner and the organization sets policy across the entire device. The familiar picture is a work phone or tablet issued to an employee: the user signs in, reaches a set of work apps published through managed Google Play, and finds that settings, networking and app installation follow organization policy rather than personal preference. Device owner is the widest standard scope Android Enterprise offers without touching firmware — it typically covers silent app install and removal, permission grants for managed apps, restrictions on adding accounts or sideloading, Wi-Fi and certificate configuration, system update policy and remote lock or wipe. The precise set of controls available on a given handset is OEM-, Android-version- and EMM-dependent, so we describe these devices as policy-controlled and centrally managed and confirm the specific controls on the target hardware rather than quoting a feature list from a console menu.

• Corporate-owned device enrolled with the DPC as device owner
• Whole-device policy rather than a separate work container
• A user account with access to organization-controlled work apps
• Personal use restricted according to organization policy
• Control scope varies by OEM, Android build and EMM — confirmed per model

What a Dedicated Device Means

A dedicated device is a fully managed device locked to a defined purpose, usually without a named user attached to it. The pattern fits kiosks, customer-facing terminals, shared shift devices and frontline tools that run one task or a tight set of tasks all day. Because dedicated is a subset of fully managed, it inherits the same device-owner control and then narrows the runtime down to its job, normally through lock task mode: the DPC declares which packages may be pinned, and — on supported builds — which system features such as the status bar, home button, overview and notifications remain reachable while the device is locked. Google’s guidance for dedicated devices and lock task mode sets out what the platform exposes; an EMM then surfaces some subset of it. Two practical consequences follow. First, a dedicated device is often userless — no Google account is signed in, and apps arrive through the EMM rather than a user-initiated download. Second, the strength of the lock-down is a property of the policy and the launcher, not of the mode name, which is why the same mode can produce a hard single-app kiosk or a gentle four-app shift device. These configurations are configurable for MDM/EMM and restricted to their intended use, with the behavior confirmed on the chosen hardware before a batch is approved.

• Single-purpose or tightly scoped task set
• Often userless, shared, unattended or customer-facing
• Lock task mode pins the approved packages and trims system UI
• A locked-down subset of the fully managed mode, not a separate privilege level

Where the Work Profile Sits — and Why Personal Use Changes the Answer

The two corporate-owned modes are frequently compared against a third posture that behaves nothing like them. On an employee-owned device, the work profile makes the DPC profile owner of a managed container: work apps, work accounts and work data live inside it, the organization can wipe that container, and everything outside it — the launcher, personal apps, the camera roll, the device’s factory-reset behavior — remains the owner’s. That is a deliberate design, not a gap to be worked around. It also means an employee-owned posture cannot deliver whole-device control, cannot pin the device into a kiosk, and cannot be converted into one without wiping the hardware. When a project brief says "we want kiosk behavior but staff also use the phones personally", that is the point where the specification has to be settled rather than deferred. Android Enterprise does offer a corporate-owned device with a work profile — the arrangement often shortened to COPE — where provisioning still passes through device owner and a work profile is then created on top. From Android 11 onward the personal side of that arrangement is intentionally protected: the administrator does not receive an inventory of personal apps, and device-wide power is bounded to asset-management style controls such as system update policy, device identifiers, factory-reset protection and a defined subset of restrictions. The exact set is Android-version- and EMM-dependent and must be checked against what the approver believes was agreed. For deployments where the whole device belongs to the task, fully managed or dedicated is the honest answer; where employees genuinely need personal use on company hardware, the company-owned work profile is the mode to specify, and the acceptance conversation shifts to which controls survive the privacy boundary. Our managed and controlled Android device programs start from that decision rather than assuming it.

• Work profile on an employee-owned device: profile owner, container only, no whole-device control
• Company-owned work profile (COPE): device owner provisioning, then a work profile with a protected personal side
• Fully managed and dedicated: work-only hardware, whole-device policy
• A kiosk cannot be built on an employee-owned work profile

Policy and User-Experience Differences

The two corporate-owned modes diverge most in what the person standing in front of the device experiences. A fully managed employee device usually keeps a recognizable home screen and a multi-app environment behind a user sign-in, with settings pruned rather than removed. A dedicated device leans on lock task mode to pin a single app or a small managed launcher, suppress the exits and hide most of the system UI, so that a member of the public or an operator between shifts cannot wander out of the task. Whether a dedicated device shows one app or several is a policy decision, not a property of the mode. The layer that delivers the visible lock-down — a managed launcher, the EMM’s own kiosk policy, or lock task mode driven directly by the DPC — is a separate choice again, and one worth making explicitly: custom launcher vs kiosk mode vs MDM covers that layer decision in full. We treat the exact lock-down as configurable and subject to validation on the target device, because system UI behavior around notifications, dialogs, accessibility prompts and OEM overlays is where kiosk escape paths are usually found.

• Fully managed: user sign-in, multi-app, pruned but visible settings
• Dedicated: lock task mode pinning one app or a small launcher
• Dedicated devices can be single-app or multi-app by policy
• The launcher/kiosk delivery layer is a separate decision from the mode

Enrollment Routes That Reach Device Owner

Both corporate-owned modes are provisioned into device owner through the same Android Enterprise routes and are differentiated afterwards by the policy the EMM applies. That is the single most useful mechanical fact on this page: how the device leaves the setup wizard fixes whether it is device owner at all, and only a narrow window exists in which device owner can be set. In practice the route must run on a device in a factory-reset or out-of-box state, before a personal account is added and before setup completes — which is why enrollment is a staging-bench activity rather than something a field user does after unboxing at their desk. Zero-touch enrollment is the route that scales, but it is a supply-chain condition before it is a technical one: eligible devices must be purchased through an authorized zero-touch reseller and registered to your account, with a configuration assigned before first boot. A QR code presented at the setup wizard is the common manual alternative and the usual staging route for tranches; NFC and the DPC identifier typed into the setup wizard remain valid on supported builds but suit small numbers or specific OEM situations. Each route carries prerequisites that fail quietly at staging rather than loudly at scoping — network at the welcome screen, the correct reseller account, a genuinely clean device. The route comparison in Android device provisioning methods goes deeper into the entry methods themselves; the table below reads them through the lens of which management modes they can reach and how they tend to break.

What Changing the Mode Later Actually Costs

Not every change of mind is expensive; the trick is knowing which ones are. Moving between fully managed and dedicated is normally a policy change: the device is already device owner, so tightening a fleet into lock task mode, adding a managed launcher, or releasing a terminal back into a multi-app configuration is a policy push and a restart of the app, not a return to the bench. Moving in or out of a work-profile posture is a different order of work. Device owner can only be established during the provisioning window described above, so a device sitting in a personally owned work profile cannot be promoted to fully managed; it has to be factory reset and re-provisioned through a device-owner route. The same applies in reverse and between the corporate-owned variants: switching a shipped fleet from fully managed to a company-owned work profile, or the other way round, means a clean state per unit. At program scale the cost is not the reset itself but the logistics around it — collecting devices from sites, re-staging them, re-recording serials and IMEIs, and re-running acceptance on the changed baseline. That is why the management mode belongs in the build specification before the first batch is staged, and why an evaluation sample and a pilot tranche of twenty to a hundred units are the right place to discover that the mode was wrong, rather than after the full program has shipped. Programs of this kind are quoted from around 500 units upward, so a mode error found in the field is a mistake measured in device-touches across the whole fleet.

• Fully managed ↔ dedicated: normally a policy change, no re-enrollment
• Work profile → fully managed: factory reset and re-provisioning, per unit
• Fully managed ↔ company-owned work profile: clean state required per unit
• Field re-staging costs logistics, not licences — decide the mode in the build spec

What a Factory Reset Does to the Mode

Management mode is not a property that survives a wipe on its own. A factory reset returns the hardware to an unprovisioned out-of-box state, and whether it comes back managed depends entirely on the route it was enrolled through. A zero-touch device is the exception that makes the difference visible: because the assignment lives in the zero-touch console against the hardware identifier, a reset device that reaches the network during setup is offered its configuration again and re-provisions itself. A device enrolled by QR code, NFC or DPC identifier has no such memory — after a reset it is an ordinary retail device until somebody repeats the route on a bench. Policy can reduce the odds of an unplanned reset: device owner can restrict a user from performing a factory reset from settings, and factory-reset protection can require an approved account afterwards, though recovery-key combinations and OEM service tools behave differently across vendors and must be checked on the exact model rather than assumed. For a deployment this becomes an acceptance question rather than a trivia question. The sample should be reset deliberately and brought back, the expected end state recorded, and the recovery instruction written down for whoever will hold the devices — because on a dedicated fleet the difference between "resets itself back into the kiosk" and "arrives at a site as a blank consumer phone" is the difference between a support ticket and a truck roll.

• A reset removes device owner; the mode is not stored in the hardware
• Zero-touch re-offers the configuration at the next setup with network present
• QR, NFC and DPC-identifier routes require a repeat on the bench
• Reset restrictions and factory-reset protection are OEM- and model-dependent

Use-Case Decision Matrix

Choosing between the modes comes down to who holds the device, what it does all day, and whether anyone needs it for anything else. A field worker who needs several work apps, a sign-in and a familiar home screen points toward fully managed; a kiosk, an inspection terminal, a classroom set or a shared retail terminal points toward a dedicated configuration; a device that must also serve personal use points away from both and toward a company-owned work profile. Many programs run more than one mode — managed handsets for staff alongside dedicated terminals for the public-facing task — and there is no penalty for that provided each group has its own policy set, its own sample and its own acceptance record. The matrix below is indicative rather than prescriptive; the right mode for your hardware, apps and markets is set during scoping and then proven on the sample.

Writing the Mode into the Sample, the Matrix and the Batch

A management mode chosen in a meeting is an opinion; a management mode reproduced on a bench is a baseline. In a rollout the decision has to survive into three artifacts. The version-controlled sample proves that the exact model, regional SKU and firmware build reaches the intended mode from a clean state through the intended route, and that the policy behaves as described once it gets there — including after a reboot and after the agreed reset scenario. The acceptance matrix records that as pass, fail or conditional rows tied to versions rather than to a device in someone’s drawer: mode reached, route used, lock task packages and features, permitted settings, escape paths tested, post-reset end state, and the known limitations that stay open. Batch staging then reproduces the accepted state per unit and records what was reproduced — serial, IMEI, enrollment confirmation, policy version and the QA check against the reference sample — with a stop rule when a unit deviates. That progression is exactly the distinction drawn in MDM-ready vs rollout-ready Android devices: a device visible in a console has demonstrated management capability, while a device approved for a batch has demonstrated a reproducible state. Mode selection is one of the earliest inputs into that chain and one of the most expensive to revisit, which is why it belongs in the device customization scope before hardware is ordered rather than after it lands. Share the target device or form factor, the app, the EMM, the required controls, the target countries and the quantity range, and the feasibility review will identify which mode the requirement actually needs, which enrollment route the supply chain can support, and what the sample has to prove before a batch is approved.