I'm trying to design two controls for corporate Windows PCs: first, only company-owned devices should be allowed to join Microsoft Entra ID; second, OOBE through Windows Autopilot should be the only approved way to enroll a corporate device into Intune. Is there a reliable way to enforce both? Blocking Entra join for everyone is not practical because Autopilot needs it during deployment. I'm also concerned that an existing corporate device—or a device restored from an image and therefore skipping OOBE—could still enroll through Company Portal. Are there configuration or Conditional Access approaches that can close those gaps?
4 Answers
Some organizations require a Temporary Access Pass for the authentication and enrollment flow, with only designated engineers allowed to issue one. That lets staff supervise the OOBE enrollment process instead of allowing users to enroll arbitrary devices. Give the pass enough lifetime or uses to survive an Autopilot failure and retry.
Intune enrollment restrictions can block personal Windows devices, but that alone does not prove that a device came through Autopilot or prevent every form of enrollment. Entra join and Intune enrollment are separate controls, so the restriction needs to be combined with identity and enrollment policies.
That’s the limitation I’m running into: personal-device blocking is already enabled, but it doesn’t establish that a corporate PC used Autopilot or stop an already-imaged machine from using Company Portal.
There is no single setting that makes Entra join inherently prove that a PC is corporate or guarantees that enrollment happened through OOBE. Autopilot registration, enrollment restrictions, Conditional Access, tightly controlled TAP issuance, and limiting user enrollment together can make the approved path the only practical one. However, someone with sufficient local control can restore an image and attempt another enrollment path, so these settings are better viewed as access controls than absolute proof of deployment history.
A practical approach is to restrict enrollment and device addition so that users cannot freely enroll devices, then have administrators add or approve machines as they are deployed. Autopilot can enroll a device without a user through self-deployment, which helps keep the approved deployment path controlled.
This improves governance, but it is not a strong anti-bypass mechanism. A device that has been reimaged or restored may still need additional controls before it can be trusted.
A TAP-based Conditional Access policy can make the process much more controlled, but it still depends on carefully limiting who can issue TAPs and where they can be used.