Defender for Servers is the security attach that a lot of Arc deployments are really reaching for, and Arc is the vehicle Microsoft built to deliver it onto machines that do not live in Azure. This article deliberately stays on the Arc side of that story, the enablement and the one architectural decision it turns on, and hands the depth of Defender configuration to the dedicated Defender series where it belongs. The decision is whether you reach Defender for Servers through Arc at all, or through a direct path that skips it, and it is more consequential than it first appears.
How the attach works
The mechanics are subscription-shaped. Defender for Servers is enabled at the subscription level, and an Arc-connected machine that lands in that subscription inherits the plan. Defender for Cloud then enables and manages the Defender for Endpoint integration for supported Arc-enabled servers, and the installation path depends on the operating system. Windows Server 2019 and later already carry the sensor, while Windows Server 2016 and 2012 R2 receive it through the unified Defender for Endpoint solution. The plan no longer depends on the Log Analytics agent or the Azure Monitor Agent; it runs on the Defender for Endpoint integration and agentless scanning. That last point matters more than it reads, because a great deal of older guidance still tells you to provision a workspace and an agent for this, and following it now buys you a monitoring bill and no security capability. For an on-premises server this attach is the entire reason to reach for Arc in a security context: it is what makes a machine sitting in your own rack a first-class citizen of a cloud security plan. You can enable the lower plan or disable coverage at the level of an individual machine, but the higher plan is a subscription decision from which you carve out exceptions rather than one you switch on machine by machine. That shape matters for how you organize subscriptions, because the subscription is the unit of security policy here.
What an Arc machine actually gets, and what it does not
Be precise about the value, because the marketing lists features that do not all reach an on-premises machine. The lower plan gives you the Defender for Endpoint sensor, detection and response, and the core vulnerability capabilities. The higher plan adds the premium vulnerability management, file integrity monitoring, operating-system baseline assessment, and a daily allowance of free log ingestion, and those do reach an Arc machine. What does not reach it is the agentless scanning that features so prominently in the Azure story. Agentless disk scanning works by taking snapshots of cloud-hosted disks, and your on-premises server has no cloud-hosted disk to snapshot, so an Arc machine relies entirely on the agent for its vulnerability and malware coverage. Just-in-time access and the network map are Azure-network constructs that likewise do not apply. None of this makes the coverage weak, the agent-based protection is genuinely strong, but you should size expectations to what an Arc machine receives rather than to the full Azure-virtual-machine feature list, or you will promise capabilities the architecture cannot deliver on-premises.
Agentless scanning snapshots a cloud disk your on-premises server does not have. On an Arc machine, the agent is the coverage, not a supplement to it.
The decision the article turns on
Here is the fork. You do not strictly need Arc to bring a non-Azure server into Defender for Servers, because there is a direct onboarding path: a tenant-level connection that binds your Defender for Endpoint tenant to a subscription, after which every Defender-onboarded server appears there for billing and visibility with no Arc agent and no Azure footprint on the machine at all. That sounds like the simpler choice, and for an estate that only wants licensing and alerting it can be. But it comes with a hard ceiling, and the ceiling is the whole decision. Through direct onboarding you get the lower plan’s functionality, and even if you enable the higher plan you receive only the premium vulnerability management on top of it. Everything else the higher plan offers, the baseline assessment, file integrity monitoring, the update assessment, the ingestion allowance, all of it depends on the Azure control-plane presence that only Arc provides. Direct onboarding is Defender visibility without Azure management. Arc is Defender capability with it.
So the decision reduces to a clean question. If all you want is to see these servers in Defender and pay for them cleanly, direct onboarding is lighter and legitimate. If you want the actual Plan 2 capability, or you were going to adopt Arc for management anyway, Arc is the path, and for machines in AWS or Google Cloud the multicloud connectors that deploy Arc for you are how Microsoft expects you to get there. Choose against the capability you actually need, not against the apparent simplicity, because the simpler path quietly forecloses most of the higher plan.
The trap to plan around
One operational hazard deserves a flag even though its depth belongs elsewhere. Onboarding a machine to Defender creates a Defender tenant association, and when a machine is already onboarded to a Defender tenant that differs from the one behind your Arc subscription, you have a cross-tenant conflict that is genuinely painful to unwind and often ends in a support case. This is the classic managed-service-provider and migration trap. The lesson at this level is simply to decide tenancy deliberately before you enable anything at scale, because retrofitting the right tenant across an already-onboarded fleet is far harder than getting it right the first time. The detailed remediation lives in the Defender material, but the planning discipline lives here.
Where the depth lives
This article owns the Arc-side enablement and the Arc-versus-direct decision, and it deliberately stops at the sensor. How you actually configure Defender for Endpoint, tune its policies, and operate its detections is the subject of a whole separate series, and duplicating it here would only produce a thinner version of a story already told well. When you are ready to configure what Arc has attached, that endpoint work is where to go, and the licensing framing that sits underneath all of it is covered there too. Treat this article as the bridge: Arc delivers the sensor, and the Defender series takes it from there.
To the decision that closes the series
With the security attach placed, every major capability Arc brings to a server is now on the table: onboarding, settings, patching, operations, licensing, and security. The final article steps back from the features to the question they all serve, which is not whether Arc works but where it belongs. When does Arc replace the domain management model for a server, when does it not, and how do you tell a machine that should move onto it from one that should stay where it is? That is the decision the whole series has been building toward, and it is next.
Azure Arc
‹ Previous: [ARC 6.1] Build Sheet: ESU Enrollment Through Arc
Next: [ARC 8] The Decision: Arc-Managed vs Domain-Joined ›
