Onboarding is the smallest of the three verbs and the one most often mistaken for the whole job. It connects the sensor to your tenant and does nothing else. It does not enroll the device in Intune, it does not decide who configures Defender, and on its own it protects nothing. What onboarding actually buys you is visibility, plus a channel decision you should make deliberately, once, for each population of devices. This is the map of those paths and the reasoning for choosing one over another.
One act, several doors
There is no single correct way to onboard, only a correct way for a given population. For a modern Windows estate the door is Intune, where the endpoint detection and response policy carries the onboarding package pulled automatically from the Defender connector, so the same act that manages the device also lights up the sensor. For domain-joined machines with no cloud management there is Group Policy. For a handful of devices, a lab, a one-off, a proof of concept, there is the local script, which Microsoft caps at ten for a reason: it is not a deployment method, it is a convenience. An estate already run by Configuration Manager onboards through Configuration Manager or tenant-attach, keeping the sensor on the same rails as everything else. Servers reached through Defender for Cloud onboard themselves when the plan is enabled. Mobile devices come in through the Defender app. And devices you deliberately choose not to enroll in Intune come in through Security Settings Management, which is its own article because it is its own decision.
Underneath most of these sits one piece of software. The unified agent now covers Windows Server from 2012 R2 through 2025, Linux, and macOS from the same sensor, which means the old mental model of a different agent per platform is gone. There is a dedicated script for non-persistent VDI, because a pooled image needs to onboard without baking a device identity into the gold image. But the common case is simpler than the option list makes it look: pick the population, pick the door that already owns that population, and the sensor follows.
The choice hiding inside onboarding
The reason to slow down here is that the path you onboard through tends to imply the channel that will configure. Onboard through Intune and Intune expects to own the settings. Onboard a domain-joined server through Group Policy and Group Policy is the natural place its configuration lives. This is the same rule the previous article put at the center of the whole platform: one channel per population, chosen deliberately. Onboarding is where you first commit to it. The failure mode is onboarding a fleet through one path and then reaching for a second channel to configure it, which is how a device ends up with two owners and a setting stuck in a conflict state that neither owner intended. Decide who manages the population before you decide how it gets onboarded, and the two decisions stop fighting.
Streamlined connectivity, and why it is a choice rather than a default
Onboarding a device also means letting it reach the service, and Microsoft has quietly made that far less painful. The older model required allow-listing a long, sprawling list of service URLs on every egress point. Streamlined connectivity collapses that to a small set of consolidated endpoints and Azure service tags. It is worth being precise about its status, because the wording matters: streamlined is an explicit selection in the connectivity-type dropdown at onboarding, and Microsoft positions it as the recommended path, not the automatic one. The legacy URLs are not being deprecated, so nothing is forcing your hand. For any new onboarding I choose streamlined and save the firewall archaeology. The single caveat is that a device still dependent on the old Microsoft Monitoring Agent cannot use it, which turns out to matter less every quarter.
The legacy tail is shorter than it was
For years the awkward part of any Defender rollout was the down-level estate, the machines that could only report through the Microsoft Monitoring Agent. That agent retired in 2024, and the modern sensor has been steadily reaching backward to replace it. It now covers Server 2012 R2 and 2016, and as of 2026 it reaches Windows 7 SP1 and Server 2008 R2 as well, deployed through the same tooling as everything else. Windows 8.1 is the last operating system still tied to the old agent. The practical consequence is the one that matters for design: almost nothing forces you onto the legacy path anymore, which means almost everything you onboard can take streamlined connectivity and behave like a first-class citizen instead of a special case.
The deployment tool for everything in between
Between the ten-device local script and a full Intune or Group Policy rollout there is a real gap, and Microsoft’s answer to it matured in 2026. The enhanced deployment tool now bundles the onboarding package into a single executable, supports deployment keys so the package is not a loose blob to be minded, and lets you set an expiry on it. If you are standing up devices at scale without an existing management channel to ride, or you are onboarding a segment ahead of the management design catching up to it, this is the current tool rather than a folder of scripts. It does not change what onboarding means. It changes how many machines you can onboard before the effort becomes its own project.
Servers and regions, the two things you set once
Two decisions here carry further than the moment you make them. The first is licensing: servers are never covered by the per-user plans, as the suite anchor laid out, so onboarding a server presupposes a server entitlement through Defender for Cloud or a standalone server license. Onboard the machine without the license and you have a sensor reporting into a plan that does not cover it, which is a quiet way to build a posture on sand. The second is the data-storage region, chosen when the tenant is first provisioned and effectively immutable afterward without a support engagement. It governs where your telemetry lives for the life of the tenant. Neither is a setting you tune later, so both deserve a deliberate decision the first time rather than a default accepted in passing.
What onboarding leaves undone
An onboarded device is visible. It is not managed, and it is not configured. It sits in the inventory, green, reporting telemetry, and taking its security settings from whatever channel you point at it next, or from nothing at all. That gap between visible and managed is exactly where the previous article said quiet risk accumulates, and closing it is the work of the rest of this block. The immediate next question is the one that catches people off guard: how do you configure a device you have deliberately decided not to enroll in Intune? That is Security Settings Management, and it is where we go next.
Defender XDR
‹ Previous: [D 2] Defender for Endpoint: The Endpoint Control Plane
Next: [D 2.1.1] Onboarding Defender for Endpoint: The Build ›
