Corporate identifiers pass the enrolment check — then the device shows as "personal" anyway
You uploaded manufacturer, model and serial for your Windows fleet, blocked personally owned devices, and Intune still labels known-corporate machines as personal — while Windows Home laptops you never bought keep turning up enrolled. Both behaviours are by design, and both are fixable once you know which mechanism does what.
The problem
Two symptoms usually arrive together, and they hit any Intune administrator tightening up BYOD or rolling out the Windows corporate identifiers feature:
- Ownership looks wrong. You added corporate identifiers — a CSV of manufacturer, model and serial number, in the
Manufacturer,Model,SerialNumberformat Peter van der Woude walks through in his write-up — so Intune can recognise your hardware. A device on that list enrols, and the admin centre shows its ownership as Personal. That is not a mistake in your CSV: Microsoft lists it as a known issue in the corporate-identifiers documentation. In Microsoft's words, when a matching device enrols, "Microsoft Intune treats it as a corporate device for the enrollment restriction evaluation, but then after that the device appears as a personal device in the admin center." - Devices you never bought appear in Intune. Personal machines — including Windows Home editions, which you cannot meaningfully manage — show up enrolled, despite a device platform restriction that blocks personally owned Windows devices. These typically arrive via app-initiated flows: a user signs into Outlook, Teams or Edge with their work account and accepts the "Allow my organization to manage my device" prompt.
The confusion is understandable, because on iOS and macOS registering a serial number genuinely does mark the device corporate. On Windows, it does not work that way.
Why it happens
Intune has two separate mechanisms here, and corporate identifiers only feed one of them:
- The enrolment-restriction check — a gate evaluated once, at enrolment time. When you block personally owned Windows devices, Intune checks whether the incoming enrolment is authorised as corporate. A Windows corporate identifier match counts as corporate for this check only.
- The device-ownership attribute — the Corporate/Personal label you see in the admin centre. For Windows, this is stamped according to how the device enrolled, not whether it matched an identifier.
Per Microsoft's documentation, only these Windows enrolment methods are authorised as corporate when the personal-device block is on:
- Windows Autopilot
- GPO enrolment, or automatic enrolment from Configuration Manager for co-management
- A bulk provisioning package
- Enrolment by a device enrolment manager (DEM) account
Everything user-driven — Add work account from Settings, Company Portal, MDM-only enrolment, or a Microsoft 365 app sign-in where the user ticks "Allow my organization to manage my device" — is classed as personal. An identifier match can let the enrolment through the gate, but the ownership attribute is still derived from the (personal) enrolment channel. Hence: corporate at the gate, personal in the console.
The second symptom has a nastier root cause. App-initiated enrolments (recorded in the audit log as DeviceEnrollmentType 14) historically were not consistently governed by the personal-device block at all: the automatic MDM enrolment scope permitted any device that completed Entra registration to enrol, ownership was not always accurately detected on that path, and there was no supported way to suppress the management-consent prompt. That is how Windows Home devices slipped into tenants that had "blocked" personal enrolment — documented in detail on tbone.se.
Microsoft is explicit about the limits of the whole mechanism. From the Intune enrolment-restrictions documentation:
"Enrollment restrictions are not security features. Compromised devices can misrepresent their character. These restrictions are a best-effort barrier for non-malicious users."
In other words: treat enrolment restrictions as hygiene, not as a security control.
The fix
You can close both gaps today, in this order:
- Close the app-initiated loophole. Enable the setting Disable MDM enrollment when adding work or school account on Windows (public preview as of February 2026) under Devices > Enrollment > Automatic Enrollment in the Intune admin centre. It decouples Entra registration from MDM enrolment: users still get SSO and Conditional Access from adding their work account, but the enrolment ride-along stops. Via Graph, PATCH the MDM policy with
isMdmEnrollmentDuringRegistrationDisabled: true. - Keep the personally owned Windows block on under Devices > Device onboarding > Enrollment > Device platform restriction — it remains a useful barrier for non-malicious users, which is most of them.
- Make Autopilot registration your corporate-ownership signal. Register corporate hardware in Windows Autopilot (hardware-hash import, or OEM/reseller registration at purchase). Autopilot is both an authorised-corporate enrolment method and the path that stamps ownership as Corporate from first boot — it is the one signal that survives past the enrolment gate. If you use Autopilot device preparation, keep your corporate identifiers uploaded too: as Peter van der Woude notes, "only devices matching those added identifiers will be defined as corporate-owned. All other devices will be defined as personal-owned."
- Clean up what already slipped in. In All devices, filter on ownership = Personal and review against your asset records; the audit log's
DeviceEnrollmentType 14identifies app-initiated arrivals. For genuinely corporate machines, correct the label under Properties > Device ownership (this changes what data Intune collects and what actions admins can take, so do it deliberately). For genuinely personal devices — especially Home editions — retire and delete the Intune record, and consider whether the cleanest end state is re-provisioning real corporate hardware through Autopilot. - Put your actual security control elsewhere. Because enrolment restrictions are best-effort, enforce access with Conditional Access requiring a compliant device. A machine that sneaks into enrolment but never satisfies compliance still cannot reach corporate data — that is the layer that holds when the gate does not.
How Decolla handles it
Honestly: no product can make Windows corporate identifiers apply after enrolment, and Decolla does not change how Intune evaluates ownership — that logic is Microsoft's, evaluated once at enrolment time. Decolla also does not hunt down rogue personal enrolments already in your tenant; the clean-up steps above are yours to run.
What Decolla does is build on the one path this article identifies as the clean corporate-ownership signal: Windows Autopilot. Decolla provisions Windows devices zero-touch over your own Intune and Autopilot tenant, so every device it provisions arrives through the authorised-corporate route — correctly stamped, never in the ambiguous "matched an identifier but enrolled personally" state. You pick from a curated catalogue of 260+ items across 21 sections, Decolla produces a written, itemised plan — delivery method and reversibility class stated per item, with anything irreversible flagged — you approve it before anything runs, and deployment then proceeds unattended in your tenant. If something needs undoing, Decolla rolls back its own changes per item. Its Library of pre-built, industry-tested policies and scripts includes built-in hardening, applied through the same plan-first, approve-first flow.
Decolla is pre-launch; you can join the waitlist at decolla.app.
Sources
- Microsoft Learn — Add corporate identifiers to Microsoft Intune (known issues and limitations)
- Peter van der Woude — Understanding corporate identifiers for Windows devices
- tbone.se — The unexpected enrollment: how personal Windows Home devices slipped into Intune and how you can finally block them
- Microsoft Learn — Overview of enrollment restrictions in Microsoft Intune
- Microsoft Tech Community — New Windows corporate device identifier feature with Microsoft Intune
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access