HomeKb › Corporate identifiers show personal
Knowledge base · Windows

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:

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:

  1. 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.
  2. 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:

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:

  1. 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.
  2. 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.
  3. 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."
  4. Clean up what already slipped in. In All devices, filter on ownership = Personal and review against your asset records; the audit log's DeviceEnrollmentType 14 identifies 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.
  5. 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

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