There is no single act called setting up Defender for Endpoint. There are three separate acts, and most misconfigured deployments come from treating them as one. A device gets onboarded, it gets configured, and it may or may not be enrolled. Each is a different decision, made through a different channel, with a different owner. Until you can say which is which for a given machine, you cannot reason about why its policy did or did not apply.
The three verbs people run together
Onboarding connects the sensor to your tenant. It is the act that makes a device visible to Defender and starts the telemetry flowing, and it says nothing at all about who configures the device or whether Intune manages it. Configuration is the separate act of deciding the settings: antivirus, endpoint detection and response, the firewall, attack surface reduction. Enrollment is the Intune management relationship, and it is the quiet one, because a device’s enrollment state governs the other two. An Intune-enrolled device takes its Defender configuration from Intune and ignores the alternatives. An onboarded but unenrolled device can be configured through a different channel entirely, without ever enrolling. Same sensor, same portal, completely different management path, decided by a verb people rarely separate from the other two.
Two consoles, one store
The most durable myth about this platform is that you must choose between managing Defender in Intune or in the Defender portal, as though they were competing systems. For endpoint security policy, they are not. The endpoint security policies you see in the Defender portal and the ones you see in Intune are two windows onto the same Intune-hosted policy store, and the Defender portal simply renders that store through Intune’s own role-based access. Change a policy in one and it is the same object in the other. There is no synchronization to worry about because there is nothing to synchronize.
The real conflict lives one level down, in channels. A single device should be configured through exactly one of them. An Intune-enrolled machine takes Intune policy. An unenrolled machine you still want centrally hardened takes policy through Defender’s own settings-management channel. A machine managed by Configuration Manager takes Configuration Manager. A domain-joined machine with no cloud management takes Group Policy. The mistake that produces mysterious, non-deterministic results is letting two of those channels touch the same setting on the same box. When that happens the platform does not cleanly pick a winner. The setting lands in a conflict state and is simply not applied the way you intended. A few settings are built to merge, notably antivirus exclusions and firewall rules, but most are not, and no design should lean on merge behavior to rescue a control that ended up with two owners.
So the authority question is never which portal. It is which channel owns this population of devices, and you answer it per population, once, deliberately.
Prevention hands, and automation
The plan split lands hardest here, so it is worth restating in endpoint terms. Plan 1 gives you prevention and a pair of manual hands. You can harden the device with antivirus and attack surface reduction, and when something goes wrong you can manually run a scan, isolate the machine, and stop and quarantine a file. That is real response, but it is you performing it. Plan 2 gives you the machinery: endpoint detection and response, automated investigation that can remediate on its own, live response for operating inside a machine remotely, and automatic containment that fires without an analyst present. If Plan 1 is a well-built lock, Plan 2 is the lock plus the guard who notices the door and closes it.
Nothing owns the device until you decide
Put those ideas together and the design rule for the whole endpoint estate falls out. Onboarding makes a device visible. The channel you choose makes it managed. The plan you hold decides whether managed means prevention or prevention plus response. None of it is automatic, and the platform will happily let you onboard a fleet that nothing is actually configuring. That is precisely the state a surprising number of tenants sit in without realizing it: devices reporting to the portal, green in the inventory, and taking their security configuration from nowhere in particular. A visible device is not a managed device, and the gap between the two is where quiet risk accumulates.
The map ahead
Everything after this is build, and it follows the shape of those decisions. First onboarding, every path a device can take into Defender and when each is the right choice, which absorbs and extends the onboarding walkthrough already in the Intune Deployment Guide. Then the channel that lets you configure devices you deliberately do not enroll. Then the protection engine itself, antivirus and detection and response and the tamper protection that stops an attacker from switching them off. Then attack surface reduction, which the Intune guide introduces as staged enforcement in [5.3.2] and which we take considerably further here. And finally the device risk score and the compliance loop it feeds, which is powerful and, handled carelessly, is also the fastest way to lock your own users out of everything. We start where every device starts, at onboarding.
Defender XDR
‹ Previous: [D 1] Defender XDR: What You Actually Own With E5
Next: [D 2.1] Onboarding Defender for Endpoint: Every Path and When to Use It ›
