As security strategies continue to pivot toward cloud adoption and the rapid acceleration of AI, priorities have shifted accordingly toward cloud security and, especially, identity. That focus is well‑justified, since attackers increasingly get the most leverage from compromising identities and cloud control planes, not just individual devices. But it doesn’t remove the need to secure devices and the systems that execute business workloads.
Device security still matters, and next to endpoints, servers remain one of the most critical and frequently targeted attack surfaces, particularly in the age of AI‑driven threats. For most organizations, server protection is where workload protection with Microsoft Defender for Cloud begins; and it’s also where confusion quickly sets in. Organizations are generally knowledgeable about protecting traditional endpoints: if you have Microsoft 365 E3 (ME3) or Microsoft 365 E5 (ME5), you deploy Microsoft Defender for Endpoint Plan 1 or Plan 2 and move on. Protecting servers, however, is more complicated; and, put bluntly, many organizations misunderstand how it works.
Servers disrupt the mental model entirely: Those same licenses don’t apply, deployment assumptions change, and teams are suddenly faced with questions about separate server licensing just to be able to run Defender properly. In many organizations, this is further complicated by the fact that endpoint and server responsibilities often sit with different teams, creating additional communication and ownership gaps right when clarity is most needed. Add the decision between Defender for Servers Plan 1 versus Plan 2, and the realization that SQL workloads operate under a separate protection model to this complexity, and what you once expected to be a straightforward endpoint strategy quickly becomes far less intuitive.
This post focuses on unpacking that intricacy, specifically around server and SQL protection, to help organizations understand:
At its core licensing, Microsoft security tends to feel straightforward, until servers enter the picture. With ME3 or ME5, organizations license Microsoft Defender for Endpoint on a per‑user basis, receiving up to five device entitlements per user that can be applied to desktops, laptops, mobile devices, tablets, and certain eIoT endpoints. For traditional endpoints, this model works well: deploy Defender for Endpoint Plan 1 or Plan 2, correlate with other XDR signals, and move on. Servers, however, re explicitly excluded from this licensing model.
While it is technically possible to install Defender for Endpoint on a server with the M365 entitlements, servers are not properly licensed in this model. This can result in antivirus‑only coverage, severely limits response actions and investigation capabilities, and is discouraged from a licensing perspective.
To properly protect servers, Microsoft requires organizations to use Defender for Servers, which is part of Defender for Cloud. Defender for Servers provides the supported path for deploying and managing Defender for Endpoint on server workloads. Defender for Server also comes in Plan 1 or Plan 2 – both of which include Defender for Endpoint Plan 2.
If this has left you confused, you’re in good company. There are many plans, product types, and feature differences that make server protection harder to understand, and we often need to take a moment to go over them with our customers.
To better grasp what each license entitles and the decision criteria that should be used, we need to look at the broader Defender for Cloud context.
Defender for Servers fits into the broader Microsoft Defender for Cloud strategy, which is fundamentally different from traditional endpoint security. Defender for Cloud is designed as a cloud security platform, combining workload protection and posture management, rather than acting as an extension of endpoint management or Intune. Within this model, servers are treated as cloud-managed resources regardless of where they run, including Azure, on‑premises, or other clouds, and are onboarded and managed through Azure Arc, not Intune. This enables consistent visibility and control across hybrid and multi-cloud environments, but it also introduces a different operational model that many teams are not initially prepared for.
This strategy uses the foundational workload protection and visibility across the Defender for Cloud solution families, including Defender for Servers, Defender for Databases, Defender for Containers, Defender for Storage, and others, alongside Cloud Security Posture Management (CSPM) capabilities that exist in both foundational and advanced tiers. Together, these services are designed to enable centralized visibility across all workloads, incorporating vulnerability management, threat detection, and configuration assessment into a single platform. With the continued integration of Defender for Cloud into the Microsoft Defender portal, this vision becomes more tangible as cloud assets now appear alongside endpoints in the unified asset inventory, while alerts and incidents from cloud workloads correlate directly within XDR.
The result is a more cohesive operational experience, where security teams, cloud teams, and other stakeholders can work from a shared view of risk and activity, rather than operating in disconnected tools or data sets.
Regardless of how Defender for Servers fits into the broader Defender for Cloud strategy, this is where most organizations get stuck: what is purchased, and how does it get enabled?
The first step is understanding that Defender for Cloud is not a traditional license you assign in the Microsoft 365 admin portal; it’s a service that is enabled and scoped through the Azure portal. While ongoing security operations and investigations can take place in both the Microsoft Defender portal and Azure, the service itself, including what gets protected and how it’s configured, is driven from Azure. Once enabled, organizations select the appropriate protection plan at the subscription or resource level, choosing between Defender for Servers Plan 1 or Plan 2. From there, everything else flows.
At its core, the difference between Plan 1 and Plan 2 is not just feature-based - it’s about how much visibility an organization needs, how long it needs to retain that data, and whether it must meet compliance or audit requirements. Plan 1 provides strong EDR telemetry such as process execution, file activity, network connections, and logon events, which is often sufficient for detection and response use cases. However, it still operates within the Defender for Endpoint telemetry model, meaning limited retention and less granular access to native operating system logs.
Plan 2 fundamentally changes that model by introducing the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs), enabling the collection of native OS-level logs such as Windows Security Events, Linux audit logs, firewall logs, and optional Sysmon data into Log Analytics and Microsoft Sentinel.
This is where capabilities like File Integrity Monitoring (FIM), extended log retention, and audit-grade evidence collection come into play. These are requirements that surface immediately in compliance frameworks where organizations must demonstrate historical activity, track changes to critical files, and reconstruct events over time. Plan 2 does not replace Defender for Endpoint telemetry. Instead, it extends it by making more of that underlying activity visible, retained, and available for deeper investigation and audit scenarios. It’s visible context versus correlated context.
This distinction becomes even more critical for database servers. A SQL server typically requires both Defender for Servers and Defender for SQL, with Defender for Servers protecting the host and providing OS-level visibility, while Defender for SQL delivers database-specific detections and vulnerability insights. In most cases, Plan 2 is the right fit for these systems because it aligns with both security depth and compliance-driven logging needs, whereas Plan 1 is better suited for lower-risk workloads where EDR-level visibility is sufficient.
workloads and aligning protection to actual risk and requirements across both compliance and business priorities. Not all workloads are created equal, and organizations need to evaluate:
Defender for Cloud accelerates this process with centralized inventory and automatic asset classification, including criticality tagging, but it still requires organizations to be intentional in how they apply coverage.
From an operational perspective, visibility is the first step. You can review server workloads directly in the Azure portal and, once integrated, in the Microsoft Defender portal alongside your other assets. You should evaluate cost early, using the Defender for Cloud cost estimator workbook and the Microsoft Sentinel cost estimator to understand how licensing choices and data ingestion, especially the Plan 2 data allowance, impact overall spend. For organizations that do not have a complete view of their environment, enabling Defender for Servers Plan 2 on a limited basis can provide immediate value through agentless discovery and vulnerability scanning, helping establish a clearer understanding of the server estate before scaling deployment.
Defender for Cloud provides flexibility to secure workloads across hybrid and multi-cloud environments, but that flexibility requires intentional planning, design, and governance. Workload protection is fundamentally different from endpoint protection. While the adversaries may be the same, the attack surface is not, and that difference drives the need for purpose-built capabilities. Defender for Servers gives organizations the ability to align protection to the specific needs of each system, rather than forcing a one-size-fits-all approach. While including Defender for Servers Plan 1 within the Microsoft 365 device entitlement could simplify adoption, the current model reflects the broader reality of enterprise environments, where workloads require different levels of protection, visibility, and control. The priority is to recognize that distinction and design accordingly.
Depending on where an organization is on its journey, there are multiple ways to approach Defender for Cloud. A Defender for Cloud Envisioning Workshop is often the best place to start. These workshops go beyond just servers and cover broader cloud workloads, including CSPM, helping establish a clear understanding of current state, gaps, and a forward‑looking security strategy. For organizations that qualify, these engagements can be funded by Microsoft or delivered as a structured paid engagement.
For organizations just getting started, a few practical steps can help build momentum:
For organizations ready to take the next step, Avertium can help you define and implement a Defender for Cloud workload strategy focused on aligning server, database, and cloud protections to real business and compliance requirements, while ensuring the environment is optimized for visibility, coverage, and cost.
You might also enjoy...