Zero-touch Windows deployment without Autopilot’s Entra tax

At a glance

What this is: This is a guide to zero-touch Windows deployment without Autopilot, showing that provisioning packages can enroll devices into Fleet from first boot while bypassing Entra ID P1 licensing and hardware pre-registration.

Why it matters: It matters because device onboarding is also identity and secret governance: the package carries an enroll secret, enrollment timing changes control points, and the absence of Entra join affects downstream policy enforcement.

By the numbers:

• At Microsoft's list price, that's $84 per person per year that this approach doesn't require.
• For a 500-person company, it's $42,000 a year, spent so that devices can enroll.

Context

Windows zero-touch deployment is a governance problem as much as an IT logistics problem. When a device can be prepared before the first desktop login, control shifts to who owns the enrollment package, the secret inside it, and the point at which device state becomes trusted.

Fleet's guide argues that provisioning packages let organisations avoid a dependency on Entra-based enrollment while still onboarding devices into management. The identity angle is real: the package contains an enroll secret, Windows MDM activates after first sign-in, and the trust boundary is no longer the same as an identity-driven Autopilot flow.

Key questions

Q: What breaks when a Windows provisioning package is used without secret governance?

A: The deployment still works technically, but the trust model fails if the package secret is shared too broadly or reused too long. That turns a convenience workflow into a reusable enrollment path for any device that can obtain the package. The control problem is custody, rotation, and revocation of the package, not the installer itself.

Q: Why do device staging workflows need secrets management as well as endpoint management?

A: Because the package that automates enrollment is itself a credential-bearing artifact. If the secret leaks, the attacker does not need to break Windows setup, only to replay the trusted onboarding flow. That makes issuance, storage, and rotation of the package a core security responsibility, not a back-office detail.

Q: How can security teams tell whether zero-touch Windows onboarding is under control?

A: Look for separated staging paths, unique enroll secrets per path, and evidence that compromised or old packages can be revoked without affecting active fleets. If device onboarding depends on a single long-lived package, the programme is already too brittle. Good control shows up as limited blast radius, not just successful shipping.

Q: When is Autopilot still the better choice than a provisioning package approach?

A: Autopilot remains the better fit when you want Entra-joined devices and already pay for the Microsoft identity stack underneath it. The provisioned-package model is useful when you want zero touch without that per-user cost, but it does not give the same identity-driven enrollment boundary.

Technical breakdown

How Windows provisioning packages replace Autopilot registration

A Windows provisioning package is a .ppkg file that applies settings and installs software during setup, before the user reaches the desktop. In this flow, the package installs Fleet's agent, which enrolls the device once it gets online. That avoids the Autopilot model where the device must already be registered or uploaded by hardware hash before shipment. The technical difference is important: Autopilot ties onboarding to identity and tenant preparation, while provisioning packages tie it to a local setup action on the device.

Practical implication: Treat package creation and handling as a privileged enrollment workflow, not a routine desktop build task.

Why enrollment secrets become the real control point

Because the package carries the enroll secret, the security model depends on protecting that secret outside the device. Fleet notes that partners can use separate enroll secrets and rotate them without affecting other devices, which is the right pattern when multiple fulfilment paths exist. The point is not just that a secret exists, but that it can be reused during device staging if lifecycle controls are weak. In practical terms, package distribution becomes a secrets-management problem as much as an endpoint-management one.

Practical implication: Separate and rotate enrolment secrets by fulfilment path, and limit who can access each package.

What changes when MDM starts after the first sign-in

With this approach, the device enrolls into Fleet early, but Windows MDM completes after the first user sign-in. That means configuration profiles, disk encryption, and OS updates can be queued before policy application is fully active. The operational trade-off is that the device is managed in stages rather than fully governed from the first interaction. Compared with Entra-joined Autopilot flows, this alters when identity assurance, policy enforcement, and user authentication come into alignment.

Practical implication: Align rollout expectations with the delayed MDM activation point and validate what is enforced before first sign-in.

Threat narrative

Attacker objective: Obtain or reuse the enrollment secret to impersonate legitimate device staging and create trust in an enrolled endpoint.

1. Entry occurs when a provisioning package is applied at the first Windows setup screen and installs the enrollment agent before the desktop exists.
2. Credential access occurs through the enroll secret embedded in the package, which can be reused if the package is not protected or rotated.
3. Impact is a newly staged device enrolling into Fleet under the wrong secret or at the wrong time, creating unmanaged trust in the onboarding flow.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Enrollment secrets are the hidden NHI in device staging: once the package carries a reusable secret, the onboarding flow stops being a pure endpoint problem and becomes a machine-identity governance problem. The article shows that zero-touch Windows deployment can bypass Entra-based identity checks, which means the secret itself becomes the trust anchor. Practitioners should govern package secrets like any other NHI credential.

Zero-touch deployment without registration shifts risk from hardware inventory to lifecycle control: Autopilot depends on prior device registration, while provisioning packages can work on any supported Windows device at first setup. That removes a supply-chain dependency, but it also removes one upstream control point. The result is a narrower operational workflow with a broader need for lifecycle assurance over who can create, hold, and revoke enrollment artifacts.

MDM timing changes the security boundary: if Windows MDM activates after first sign-in, then the device is present in management before it is fully governed by all intended policies. That gap is not a failure of endpoint management, but a timing assumption that many onboarding programs make too casually. Practitioners should treat first-sign-in as a control milestone, not a convenience detail.

Fleet's example reinforces a broader NHI pattern in IT operations: when a workflow uses an embedded secret to automate trust, the governance challenge moves upstream to issuance, rotation, and separation of duties. This is the same structural issue that appears in service accounts and API keys, only expressed through device onboarding. The practical conclusion is to inventory and control enrollment secrets with the same rigor as production credentials.

Cost avoidance can mask control debt: removing a per-user licensing requirement may simplify procurement, but it does not remove the trust design choices embedded in the deployment model. The article makes clear that organisations still need to answer who stages devices, who can see the package, and how the secret is rotated when compromise is suspected. Zero touch only works safely when the secret lifecycle is explicit.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Enrollment packages create a machine-identity governance problem, not just an IT workflow. Once a provisioning package carries the enroll secret, the security boundary moves to custody, rotation, and revocation of that artifact. That is the same pattern seen in other non-human identity flows: trust is created by a secret, not by the device itself.

Provisioning-package onboarding narrows one dependency while widening another: it removes the Autopilot registration step, but it requires tighter control of fulfilment paths and first-sign-in policy timing. That means device teams should measure not only whether devices ship, but whether onboarding artifacts are segregated, rotated, and recoverable.

Enrolment secrets deserve the same discipline as any other NHI credential. If a package can be handed to a reseller, stored on USB, or reused across shipments, it needs inventory, ownership, and revocation rules. Practitioners should fold these artifacts into identity and access governance rather than leaving them inside endpoint build process runbooks.

For practitioners

• Define who can create enrolment packages Restrict package creation to a small operational group and treat the resulting .ppkg file as a privileged onboarding artifact.
• Use separate enroll secrets for each fulfilment path Issue distinct secrets for partner staging and in-house imaging so one compromised package does not affect every onboarding route.
• Rotate package secrets on handoff or suspicion Replace the secret immediately if a package leaves controlled custody, and retire old secrets before the next shipping cycle.
• Validate what is enforced before first sign-in Test which configuration profiles, encryption settings, and update policies apply before Windows MDM finishes its post-login enrollment.

Key takeaways

• Zero-touch Windows deployment can work without Autopilot, but the trade-off is that the onboarding package becomes a privileged credential-bearing artifact.
• Fleet's article shows that registration-free onboarding reduces one supply-chain dependency while creating a stronger need for secret custody and rotation.
• Practitioners should govern provisioning packages like non-human identities: inventory them, separate them by fulfilment path, and revoke them when custody changes.

Key terms

• Provisioning Package: A Windows provisioning package is a setup-time bundle of settings, installers, and credentials that configures a device before the user reaches the desktop. In this context, it becomes a privileged onboarding artifact because it can establish trust and trigger enrollment without a normal interactive login.
• Enroll Secret: An enroll secret is the credential embedded in an onboarding package that authorises a device to join a management system. If it is exposed, reused, or shared too broadly, it can turn a convenience workflow into an unauthorised enrollment path.
• Zero-Touch Deployment: Zero-touch deployment is a provisioning model where credentials or devices are prepared before they reach the user, so IT does not need to manually process each item. In identity programmes, it shortens onboarding, reduces shipping complexity, and helps enforce consistent setup and policy from the first use.
• MDM Enrollment: MDM enrollment is the step where a device becomes manageable by a mobile or endpoint management platform. Timing matters because some policy controls activate before enrollment completes, while others only apply after user sign-in and final synchronisation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a common control language for the credential-bearing workflows that now sit inside device onboarding and automation.