Defender for servers: licences, Arc and billing

Content reviewed: 29 October 2026

The company has Microsoft 365 E5, a Defender sensor is running on its server and the device appears in the security portal. Does this prove correct server licensing? No. The user licence, technical server connection and protection billing are three separate elements that an administrator must reconcile.

Microsoft 365 E5 does not replace a server entitlement. Possible server protection routes include Defender for Business servers, standalone Defender for Endpoint for servers and consumption-based Defender for Servers Plan 1 or Plan 2 in Defender for Cloud. Selection depends on environment size, required capabilities and onboarding route. Installing the sensor does not make that choice for you.

Similar names, different offers

First distinguish user-device protection from server operating system environments. Microsoft's official licensing FAQ explicitly separates user licences from server protection. It also explains that standalone server SKUs are not assigned to servers in Microsoft 365 admin centre in the same way as user licences.

The distinction between the standalone Endpoint server SKU and consumption-based plans is covered by Microsoft Defender Licensing Guidance. Defender for Servers P1 is not client Defender for Endpoint P1. The server P1 offer includes the endpoint protection associated with its server offering; the P1 name alone is not a reliable shorthand for identical capabilities across products.

Why E5 and five devices per user are insufficient

A server accessed by a licensed employee does not thereby become that employee's client device. Inventory the server environment and its entitlement. The number of RDS users and the identity of its administrator do not replace the server licence.

The Business route has particularly concrete limits. Microsoft Defender Product Terms require a separate Defender for Business servers licence for each OSE, up to 60 such licences per customer. A general Defender for Business user entitlement does not cover server OSEs. These terms are for MCA; verify the applicable version for another agreement.

In practice, this means counting virtualisation too. A physical virtualisation host and several Windows Server VMs do not automatically form one protected server instance. The inventory of operating environments actually onboarded must support both purchasing and subsequent checks.

Azure Arc and Direct onboarding serve different purposes

Azure Arc connects a supported non-Azure server to Azure management. Direct onboarding associates an eligible server already reporting to Defender for Endpoint with Defender for Servers and a selected Azure subscription. They are not interchangeable installation buttons.

The current Direct onboarding procedure has an important scope: the setting applies to existing and future eligible non-Azure servers onboarded to Defender for Endpoint in the same Entra tenant. It cannot select individual servers or restrict enablement to a pilot group. The operation itself also does not install the endpoint agent.

Example: a two-server pilot can affect the whole estate

Consider an organisation with 18 eligible non-Azure servers already reporting to MDE. An administrator wants to test billing for two and enables Direct onboarding, believing this selects a pilot. Selecting the billing subscription does not, however, limit the affected population to those two machines.

The difference between intention and scope is 16 servers. This is not a bill calculation: the amount depends on the plan, state and contract route. It is a reason to assess impact before enablement. An endpoint-policy pilot is not the same test as a tenant-wide connection pilot.

Prepare the full affected inventory, including servers with existing Arc connections or another licensing route. Record who approves the billing change. Then choose a supported test architecture whose real scope matches the approved intention.

P2 requires capability-specific checks

Plan 2 adds capabilities for server and cloud environments. The Defender for Servers matrix does not mean every feature works on every server, in every cloud and through every connection method.

Direct onboarding provides P1 and only a subset of P2 capabilities. Determine Arc requirements for the actual function. Likewise, Arc registration does not prove healthy endpoint detection. Test both layers separately.

Deployment scope matters too: P1 can be enabled at resource level; P2 is enabled at subscription level, with resource exclusions available. This distinction matters if a small part of the environment requires another plan. A subscription switch is not a harmless single-server change.

Two billing mistakes with different causes

The first is overlap between purchased standalone Defender for Endpoint for servers and consumption-based Defender for Servers. The Defender for Servers FAQ describes requesting a billing adjustment through support. Recognition of the existing entitlement is not automatic and takes effect on approval, not retrospectively. Do not extend this procedure to every different licence containing the Defender name without checking eligibility.

The second mistake confuses VM states. An Azure VM in the Stopped state retains allocated hardware; the FAQ lists it as billable under the described model. Deallocated is different. Shutting down Windows from inside the VM therefore does not itself prove that the corresponding protection cost has stopped.

Check duplicate records separately. Two records do not necessarily represent two physical servers or two billed items. Compare identifiers, connection paths and agent currency; investigate correlation and billing data if they disagree. Removing a record cosmetically does not correct licensing or security state.

Assess the Business tenant before ordering

An organisation with up to 300 users and fewer servers can consider the Business server add-on. That does not settle the choice: required capabilities, contractual availability and the supported tenant mode still matter. The Business FAQ notes that adding Defender for Cloud does not change the simplified Defender for Business configuration experience.

The sources are not fully aligned here. The licensing FAQ describes restrictions on mixed server licensing and does not assume an ordinary consumption offer for a Business tenant. The Business FAQ describes interoperability with Defender for Cloud while retaining the Business experience. We do not interpret this as an entitlement to any arbitrary mix. Obtain written confirmation of the specific server SKUs, tenant and capabilities before changing the configuration; a general marketing overview does not resolve this discrepancy. Client licensing is addressed separately in Defender for Business versus Defender for Endpoint P2.

A working inventory for purchasing and invoice checks

The following table is an editorial model. It contains no customer prices and does not assume one purchasing route is always cheapest.

The total is 18 OSEs, not 18 E5 user licences. Compare the verified count with standalone server entitlements or the Defender for Cloud population. Pricing additionally needs rates, the time profile and any approved overlap adjustment. A monthly cost comparison without those inputs would mislead.

For every server, record a stable identifier, OS, owner, location, onboarding path, plan, entitlement source, billing subscription and last review date. This links the security inventory to the invoice. A list containing only hostnames and Defender yes/no cannot explain what was ordered and what is being billed.

What changes on 1 November 2026

A further change is announced as of publication. Microsoft release notes specify 1 November 2026: productivity and desktop client devices cease being billed as servers in P1, while server identification becomes more granular in both P1 and P2. Online machines are to be checked several times per hour, with deployed machines counted separately even when they share an Arc ID from a golden image.

For P1, the announcement also distinguishes Windows servers from Linux and other non-Windows servers: billing for the latter is tied to MDE agent deployment under the described rules. For Windows in a connected environment, manual sensor installation alone is not the deciding signal. Add OS classification and the actual number of cloned instances to the November review. A changed billed count does not necessarily mean new licences were just purchased.

Checks after the change

1. Reconcile the complete affected population with the original inventory, including servers outside the original intention.
2. Check endpoint telemetry and the Defender for Cloud plan separately. A historical device record is not proof of active protection.
3. Test the specific capabilities that justified the plan. Record the environment and technical prerequisites.
4. Compare entitlement records with billed resources and address any overlap through support. Retain the adjustment approval date.
5. Repeat the review when VMs are created, plans change and contracts renew. Keep ownership and budget allocation current.

The new Cloud security experience in the Defender portal is in public preview and uses Defender Workload Units (DWUs) for migrated subscriptions. Establish the pricing experience before comparing invoices. Build an appropriate budget for a different billing model. When handing over work, document the plan and change scope, rather than merely a button location.