Microsoft Defender: A Complete Guide to Cloud and XDR Protection

Two Portals, One Security Strategy

Microsoft's security stack splits across two distinct portals, and the reason isn't arbitrary — it reflects two fundamentally different ownership models.

Azure Portal → Microsoft Defender for Cloud grew out of the Azure platform team. Its job is to protect cloud resources: the VMs, databases, storage accounts, and APIs that you provision and manage in your subscription. The people who care about this are typically cloud engineers, DevOps teams, and infrastructure architects.

Microsoft Defender Portal → Microsoft Defender XDR grew out of the Microsoft 365 / enterprise security team. Its job is to protect people and their tools: the laptops employees use, the email they receive, and the identity they authenticate with. The people who care about this are typically IT admins and security operations teams.

Both portals feed alerts into the same unified incident queue in the Defender Portal, so your security team investigates everything from one place. But configuration still lives in the portal closest to what you're protecting — Azure resources in the Azure Portal, user-facing tools in the Defender Portal. The Defender Portal is becoming the single place to respond and investigate, but it's not yet the single place to configure and enable plans.

The practical takeaway: if you're looking for a security setting and can't find it, ask yourself what am I trying to protect — a cloud resource or a person — and that tells you which portal to open.

---

A note on naming that trips everyone up: Two plans share similar names and are easy to confuse.

• •Defender for Cloud — the CNAPP that protects your Azure, AWS, and GCP infrastructure (VMs, storage, databases, APIs). Lives in the Azure Portal.
• •Defender for Cloud Apps — the CASB that protects your SaaS applications (Salesforce, Slack, Google Workspace, Box). Despite the similar name, it's part of the Defender XDR suite and lives in the Defender Portal.

The simplest way to tell them apart: Cloud = your infrastructure. Cloud Apps = other companies' software your employees are logging into.

---

Understanding which plan lives where — and exactly how to activate it — is the key to building a complete defense.

---

Part 1: Microsoft Defender for Cloud (Infrastructure)

Defender for Cloud is a Cloud Native Application Protection Platform (CNAPP). You enable modular "Plans" to protect specific resource types across Azure, AWS, GCP, or on-premises environments.

The Activation Path

1. •Search for "Microsoft Defender for Cloud" in the Azure Portal top search bar.
2. •In the left sidebar, navigate to Management → Environment settings.
3. •Click your Subscription Name.
4. •Click Defender plans — this is your master switch page.

Each plan targets a specific resource type. Toggle them on individually.

---

Defender for Servers

Protects Virtual Machines (Windows and Linux) running in Azure, AWS, GCP, or on-premises.

What it does:

• •Scans the OS for known vulnerabilities and misconfigurations
• •Includes a full license for Microsoft Defender for Endpoint (EDR) on every onboarded VM
• •Provides Just-In-Time (JIT) VM access to reduce the attack surface on management ports

When to use it: Any workload running on a VM that holds sensitive data or faces the internet.

---

Defender for Storage

A security guard for Blob Storage, Azure Files, and Data Lakes.

What it does:

• •Uses AI to detect anomalous data access patterns (e.g., an unusual spike in downloads, access from a new geography)
• •Scans uploaded files for malware before they're processed by downstream applications
• •Alerts on sensitive data exposure (e.g., a blob container that becomes publicly accessible)

When to use it: Any storage account that receives uploads from external sources or stores business-critical data.

---

Defender for SQL & Databases

Protects Azure SQL, Cosmos DB, and open-source databases (PostgreSQL, MySQL, MariaDB).

What it does:

• •Detects SQL Injection attempts and other query-level attacks in real time
• •Runs vulnerability assessments to flag misconfigured database settings
• •Alerts on unusual access patterns, such as a service account querying tables it has never touched before

When to use it: Every production database, without exception.

---

Defender for APIs

Security for APIs published through Azure API Management (APIM).

The prerequisite: Azure API Management

Before Defender for APIs can protect anything, you need an Azure API Management (APIM) service — and this is where most people get stuck. Defender for APIs doesn't monitor APIs built directly into your App Service or Azure Functions. It only sees APIs that have been imported into APIM.

APIM acts as a gateway that sits in front of your backend APIs. You define your API endpoints inside APIM (by importing an OpenAPI spec, a Function App, or a Logic App), and APIM becomes the single front door that all traffic passes through. Once your APIs live inside APIM, Defender for APIs can inspect them.

To create an APIM service:

1. •In the Azure Portal, search for "API Management services" and click Create.
2. •Choose your subscription, resource group, region, and a globally unique service name.
3. •Select a pricing tier — Developer for non-production testing, Basic or Standard for production.
4. •Once deployed (this takes several minutes), go to APIs → Add API and import your backend — either an OpenAPI/Swagger spec, an Azure Function App, or a manually defined HTTP API.

Once your APIs are registered in APIM, you can enable Defender for APIs.

What Defender for APIs does

The core problem it solves is that API surface area grows faster than anyone tracks it. A developer publishes a new endpoint, forgets to add an auth policy, and it sits there unprotected — often for months. I've seen this happen in environments that considered themselves well-managed. Defender for APIs finds these gaps automatically.

• •Shadow API detection — scans every API registered in APIM and flags any endpoint that's missing an authentication policy entirely. These are live, callable routes with no access control.
• •Security posture checks — identifies APIs with missing rate limiting (vulnerable to abuse and scraping), overly permissive CORS settings (vulnerable to cross-origin attacks), and endpoints that accept HTTP instead of enforcing HTTPS.
• •Runtime threat detection — after onboarding, Defender monitors live API traffic and alerts on patterns like an unusual spike in calls to a single endpoint, calls from IP ranges associated with scanners, or responses that suggest data enumeration (e.g., a client systematically walking through sequential IDs).

How to activate

Enabling the plan on the Defender plans page is only the first step. The plan being "On" means Microsoft is ready to protect your APIs — it doesn't automatically start monitoring them. You have to complete a second onboarding step to tell Defender which specific APIs to watch.

1. •Go to Defender plans and toggle APIs to On.
2. •In the left sidebar, click Recommendations.
3. •Search for "Microsoft Defender for APIs should be enabled" — this recommendation appears for each API Collection in your APIM instances.
4. •Click the recommendation, select your API Collections, and click Fix.
5. •After a few minutes, your APIs appear in Workload protections → API Security with a security posture score and any active alerts.

The reason it works this way — toggle then fix — is that the plan is billed per API collection. The Recommendations blade is where you explicitly choose which collections to onboard and accept the associated cost, rather than Microsoft automatically onboarding everything and billing you without confirmation.

---

Defender for Containers

Security for Azure Kubernetes Service (AKS) and Azure Container Registry (ACR).

What it does:

• •Scans container images in ACR for OS and application-layer vulnerabilities before they're deployed
• •Monitors the Kubernetes API server for suspicious activity (e.g., a pod attempting to escape to the host)
• •Provides runtime threat detection inside running pods

When to use it: Any Kubernetes cluster running in production, regardless of workload type.

---

Defender for DevOps

Security for your source code and pipelines across GitHub, Azure DevOps, and GitLab.

What it does:

• •Scans repositories for exposed secrets (API keys, connection strings, tokens committed by mistake)
• •Analyzes Infrastructure-as-Code (Terraform, Bicep, ARM) for misconfigurations before they reach production
• •Surfaces findings as security recommendations directly in the Azure Portal

How to activate:

1. •In Defender for Cloud, click Environment settings → Add environment.
2. •Select your source control provider (GitHub, Azure DevOps, or GitLab).
3. •Follow the OAuth connection wizard to grant repository access.

---

Part 2: Microsoft Defender XDR (Users & Devices)

Defender XDR lives at security.microsoft.com. It protects the human layer — the employees, their machines, and the communication tools they rely on every day. This is where most attacks actually land.

---

Defender for Endpoint

Advanced EDR and antivirus for laptops, desktops, and mobile devices.

What it does:

• •Behavioral analysis that stops ransomware before encryption begins, even for zero-day variants
• •Attack surface reduction (ASR) rules that block common malware delivery techniques
• •Full device timeline so you can reconstruct exactly what happened on a machine during an incident

How to activate:

1. •Go to Settings → Endpoints → Onboarding.
2. •Select your operating system.
3. •Download and run the onboarding script on the target device.

---

Defender for Office 365

Security for Email, Microsoft Teams, and SharePoint.

What it does:

• •Safe Links — rewrites every URL in email and Teams messages and checks the destination at click time, not just at delivery. This matters because attackers change destinations after an email lands.
• •Safe Attachments — detonates every attachment in a sandbox before it reaches the recipient's inbox
• •Anti-phishing policies that detect impersonation of your executives or trusted domains

How to activate:

1. •Go to Email & collaboration → Policies & rules → Threat policies.
2. •Click Preset security policies.
3. •Apply either the Standard or Strict protection profile to your users.

---

Defender for Identity

Protection for your on-premises Active Directory.

What it does:

• •Detects Lateral Movement — when an attacker compromises one account and uses it to hop across the network to higher-privilege accounts
• •Identifies Pass-the-Hash and Kerberoasting attacks in real time
• •Builds a behavioral baseline for every user so anomalies stand out immediately

How to activate:

1. •Go to Settings → Identities.
2. •Download the Sensor installer.
3. •Install the Sensor on every Domain Controller in your environment.

---

Defender for Cloud Apps

A Cloud Access Security Broker (CASB) that sits between your users and their SaaS applications — think Salesforce, Slack, Google Workspace, Box, and GitHub. This is not the same as Defender for Cloud (which protects your Azure infrastructure). Despite the overlapping name, Defender for Cloud Apps is entirely focused on third-party SaaS tools your employees log into, and it lives here in the Defender XDR suite, not in the Azure Portal.

What it does:

• •Discovers Shadow IT — every cloud application your employees are using that IT hasn't approved or reviewed
• •Applies data loss prevention (DLP) policies inside sanctioned apps like Salesforce, Box, and GitHub
• •Can block uploads of sensitive files to personal cloud storage accounts in real time

How to activate:

1. •Go to Cloud apps → Cloud discovery.
2. •Toggle the Microsoft Defender for Endpoint integration to On.
3. •Network traffic data from enrolled devices will begin populating the discovery dashboard automatically.

---

Quick Reference Guide

Azure Portal — Defender for Cloud (Infrastructure)

Microsoft Defender Portal — Defender XDR (Users & Devices)

---

Where to Start

If you're enabling Defender for the first time and need to prioritize, work in this order:

1. •Defender for Endpoint — get every device enrolled first. Without endpoint visibility you're blind.
2. •Defender for Office 365 — email is still the number one initial access vector.
3. •Defender for Servers — any internet-facing VM is a high-value target.
4. •Defender for Identity — if you have Active Directory, attackers will target it.
5. •Everything else — layer in the remaining plans based on your specific risk profile.

Security coverage is only as strong as the gaps you haven't closed yet.