Part 2 named Zero Touch as the enrollment method that actually scales[cite: 3]. Let’s break down what’s actually happening under the hood[cite: 3]. “The device just configures itself” sounds like magic until you see the plumbing — but once you understand it, you’ll actually know how to troubleshoot it when something goes sideways[cite: 3].

The Core Idea: Enrollment Tied to Hardware, Not Users

Every other method from Part 2 requires someone — either an IT admin or the end user — to take an active step on the phone[cite: 3]. They have to scan a code, bump an NFC tag, or download an app[cite: 3]. Zero Touch removes that entire step by tying enrollment directly to the device’s hardware ID (like its IMEI or serial number) the moment it’s purchased[cite: 3]. The phone literally knows it belongs to your organization before anyone even breaks the seal on the box[cite: 3].

How the Reseller Relationship Works

Here’s where people usually trip up: Zero Touch isn’t something you handle entirely inside Google or Microsoft’s consoles[cite: 3]. It requires two main things[cite: 3]:

  • Your device vendor must be an official Zero Touch-enrolled reseller[cite: 3].
  • Your purchase order has to be linked to your organization’s Zero Touch account at the point of sale[cite: 3].

When the reseller ships the hardware, they register its identifiers directly to your account in Google’s Zero Touch Portal[cite: 3]. That’s the secret sauce[cite: 3].

In practical terms, this means:

  • You need to confirm your vendor supports Zero Touch before placing an order, not after the boxes arrive on your desk[cite: 3].
  • Your org needs a Zero Touch Portal account set up, separate from (but connected to) your Intune tenant[cite: 3].
  • Devices bought outside this chain — like a phone bought at a retail store or a used device — won’t show up in Zero Touch[cite: 3]. You’ll still have to enroll those manually, no matter how smooth your Zero Touch setup is for everything else[cite: 3].

What a Provisioning Configuration Actually Controls

Inside the Zero Touch Portal, a provisioning configuration is the blueprint applied the moment a registered phone boots up for the first time[cite: 3]. At a minimum, it defines:

  • The EMM (your Intune tenant) the device needs to register with[cite: 3].
  • Whether the device is set to Fully Managed or COPE (remember, this profile decision from Part 1 happens right here at the hardware level, long before Intune gets involved)[cite: 3].
  • Custom branding or welcoming text displayed during initial setup[cite: 3].
  • Whether a user can escape enrollment via a factory reset[cite: 3]. (By default, a wiped Zero Touch device will just force re-enrollment on its next boot — exactly the anti-tamper behavior you want for company property[cite: 3]).

You can also run multiple configurations under one account, which is super helpful if field staff phones need a different setup than shared front-desk tablets[cite: 3].

Why This Matters Even More for Small Teams

It’s easy to assume Zero Touch is heavy enterprise tech that’s overkill for smaller operations[cite: 3]. In reality, the opposite is true[cite: 3]. If you’re running a lean IT shop, you don’t have hours to sit around manually unboxing and setting up phones one by one[cite: 3]. Zero Touch turns “unbox $\rightarrow$ manually configure $\rightarrow$ ship” into “vendor ships directly to the user, device configures itself on power-on[cite: 3].”

Sure, there’s a small upfront setup: verifying reseller ties, creating your portal account, and building your configurations[cite: 3]. But once that foundation is built, future device orders practically take care of themselves[cite: 3].

Part 4 moves past initial enrollment to focus on what happens once Intune takes over: app management, Managed Google Play, and how app rollouts differ across management profiles[cite: 3].

References