Microsoft Defender for Cloud: Finding Weak Spots and Stopping Attacks Across Your Cloud
An intermediate guide to Microsoft Defender for Cloud: how it measures your security posture, protects workloads, detects threats and connects to the rest of your security tools, and how to roll it out without drowning in noise or cost.
Imagine you own a large shopping mall. You need two kinds of protection. First, you walk the building regularly to check that doors have locks, windows are closed, fire exits are clear and cameras work. That is about prevention and good habits. Second, you employ guards who watch the cameras, notice a stranger testing door handles at midnight and call for help. That is about detecting and stopping real attacks.
Microsoft Defender for Cloud does both jobs for your cloud. It inspects your resources and tells you which locks are missing, and it watches your workloads for signs that someone is attacking them. It works across Azure, other clouds and your own servers, and it ranks problems so that you can fix the most dangerous ones first. This tutorial explains each part from the beginning and shows how teams turn it from a noisy dashboard into a working security routine.
1What Defender for Cloud Is and Why It Exists
Defender for Cloud is Microsoft’s service for improving the security posture of your cloud environments and protecting the workloads running in them.
The problem it solves
Cloud environments grow fast and change constantly. A developer creates a storage account for a quick test and forgets to restrict who can reach it. A virtual machine is deployed without the latest patches. A container image contains a library with a known weakness. None of these mistakes is dramatic on its own, but attackers use automated tools to scan the internet for exactly such openings, often within minutes of a resource appearing.
Checking every resource by hand is impossible once an organization has thousands of them. Defender for Cloud solves this by automatically evaluating resources against security rules, scoring the result, and pointing to the specific fixes that matter most. It also watches for signs of active attacks, such as a sudden burst of failed sign-in attempts against a server.
Defender for Cloud is like a building inspector and a security guard rolled into one. The inspector finds unlocked doors and broken alarms before anything happens, and the guard raises the alarm when someone is actually trying to break in.
Where the name comes from
The service has had several names over the years, and older articles may call it Azure Security Center or Azure Defender. These are earlier names of the same family of capabilities. Today the posture features and the workload protection plans live together under the name Microsoft Defender for Cloud, which is part of the larger Microsoft Defender family of security products.
Not only for Azure
Although it is built into the Azure portal, Defender for Cloud can also connect to Amazon Web Services and Google Cloud, to code repositories and to servers in data centers. This is useful because most large companies do not live in a single cloud, and security teams want one view of risk across everything.
Basic posture assessment is available without paying for the advanced plans. This means every Azure subscription can already show a security score and a list of recommendations, which makes it an easy place to begin.
2CNAPP, CSPM and CWPP in Plain Words
Security vendors love acronyms, but three of them explain the whole shape of Defender for Cloud.
CSPM
Cloud Security Posture Management. It checks configuration and shows what is set up unsafely, before an attack happens.
CWPP
Cloud Workload Protection Platform. It protects running workloads such as servers, containers and databases from active threats.
CNAPP
Cloud-Native Application Protection Platform. The umbrella that joins posture, workload protection and code security into one approach.
Shift left
Finding security problems earlier, while code is being written, instead of after it runs in production.
flowchart TD
CN["CNAPP: protect cloud applications from code to runtime"] --> C1["Code security: DevOps scanning, shift left"]
CN --> C2["CSPM: posture, recommendations, attack paths"]
CN --> C3["CWPP: workload protection plans and threat detection"]
C1 --> OUT["One connected view of risk"]
C2 --> OUT
C3 --> OUT
Think of looking after a car. CSPM is the regular check of tires, oil and brakes. CWPP is the alarm and tracking system that reacts if a thief tries to steal it. Code security is the quality check on the factory line. CNAPP is the whole plan that covers all three.
Why the split matters
Posture and protection answer different questions. Posture asks how exposed you are right now and what to fix first. Protection asks whether anything bad is happening right now. A company that does only posture can be perfectly configured and still blind to a stolen password. A company that does only protection may be catching attacks constantly while leaving the same open doors that invite them. Strong programs use both.
Believing that a high secure score means you cannot be attacked. A good score means common weaknesses are fixed, which lowers risk, but you still need detection and a plan for when something slips through.
3Shared Responsibility and Where Defender for Cloud Fits
Security in the cloud is shared between the provider and the customer, and knowing the split shows what Defender for Cloud is for.
The shared responsibility model
Microsoft secures the physical data centers, the hardware and the core cloud platform. You are responsible for how you configure and use the services: who can sign in, which resources are open to the internet, whether data is encrypted, and whether the software you run is patched. The more control a service gives you, the more you must secure. A virtual machine leaves most of the work to you, while a fully managed database leaves less.
It is like renting an apartment. The landlord is responsible for the building’s structure and the main entrance, but you are responsible for locking your own door and not leaving your keys in the hallway.
Defender for Cloud and its neighbours
Microsoft has several security products with similar names, and beginners often mix them up. The table shows how they differ.
| Product | Main Focus | Typical Question |
|---|---|---|
| Defender for Cloud | Posture and workload protection for cloud resources | Which of my cloud resources are risky or under attack? |
| Defender for Endpoint | Protection of laptops, desktops and servers | Is this device compromised? |
| Defender for Cloud Apps | Control of software-as-a-service use and data sharing | Which cloud apps are my staff using and are they safe? |
| Defender for Identity and Entra ID Protection | Protection of accounts and sign-ins | Is this account being abused? |
| Microsoft Sentinel | Collecting, correlating and responding to security events | What is happening across everything, and how do we respond? |
| Azure Policy | Enforcing rules on how resources are configured | Is this resource configured according to our rules? |
These products work together. Defender for Cloud feeds alerts to Sentinel and to the unified Defender portal, uses Defender for Endpoint for server protection, and relies on Azure Policy under the hood for many of its checks. Thinking of Defender for Cloud as the cloud-resource specialist in a larger team makes the picture clearer.
When someone says “Defender” in a meeting, ask which one. Most confusion in security projects begins with two people talking about different products under the same family name.
4How Defender for Cloud Works
The service follows a simple loop: discover resources, assess them, protect them and report what it finds.
flowchart LR
ENV["Environments: Azure, AWS, GCP, code repositories, servers"] --> DISC["Discover and inventory resources"]
DISC --> ASS["Assess configuration against security standards"]
DISC --> PRO["Protect workloads with enabled plans"]
ASS --> REC["Recommendations and secure score"]
PRO --> ALR["Security alerts and incidents"]
REC --> ACT["Fix, assign, exempt or automate"]
ALR --> RESP["Investigate and respond"]
RESP --> OUT["Export to Sentinel and other tools"]
The core steps
Connect environments
Azure subscriptions are included by default, while other clouds and code platforms are added through connectors.
Assess posture
Resources are checked against security standards, and each failing check becomes a recommendation.
Enable protection plans
For resource types you care about, you switch on plans that add threat detection and deeper scanning.
Prioritize and fix
Teams work through recommendations, guided by the secure score and by the attack paths that show real exposure.
Detect and respond
Alerts and incidents are investigated, and responses can be automated or sent to other security tools.
It resembles a regular health check-up program. First you register the patients, then you run the tests, then you give extra monitoring to the high-risk ones, then you tell each patient what to improve, and finally you respond quickly if someone becomes ill.
Agents and agentless methods
To look inside a resource, Defender for Cloud uses two broad approaches. Agentless methods read information through the cloud platform itself, such as taking a snapshot of a disk and scanning it, so nothing needs to be installed. Agent-based methods run a small piece of software on the machine or cluster to collect deeper, real-time information. Modern deployments try to use agentless scanning where it is enough and add agents only where they provide something agentless cannot.
Start with agentless features. They deliver visibility quickly with no change to your machines, and they reduce the risk and effort of rolling out software everywhere.
5Foundational CSPM and Defender CSPM
Posture management comes in a free baseline and a paid advanced tier, and it helps to know what each includes.
The free baseline
Foundational CSPM is available on connected environments without extra charge. It continuously assesses resources against Microsoft’s recommended security benchmark, produces recommendations with remediation steps, calculates a secure score and shows an inventory of your assets. For many small teams this alone is a major step forward from having no visibility.
The advanced tier
Defender CSPM is the paid tier that adds deeper analysis. It includes attack path analysis, which shows how an attacker could chain weaknesses together, and the cloud security explorer, which lets you query the relationships between your resources. It also adds agentless scanning for machines and containers, data-aware posture that finds sensitive data, governance tools for assigning fixes, and extra regulatory compliance standards. Exact features change over time, so confirm the current comparison in Microsoft’s documentation before deciding.
| Capability | Foundational CSPM | Defender CSPM |
|---|---|---|
| Secure score and recommendations | Yes | Yes |
| Asset inventory | Yes | Yes |
| Security benchmark assessment | Yes | Yes |
| Attack path analysis | No | Yes |
| Cloud security explorer | No | Yes |
| Agentless machine and container scanning | No | Yes |
| Sensitive data discovery in posture | No | Yes |
| Governance rules with owners and due dates | Limited | Yes |
| Extended compliance standards | Limited | Yes |
| Code-to-cloud contextual mapping | No | Yes |
The free tier is like a basic home inspection checklist. The advanced tier is like hiring an investigator who not only lists the problems but also shows how a burglar could link a broken window, a hidden key and an unlocked garage to reach the safe.
Turning on every paid feature on every subscription on the first day. Start with the environments that hold your most important data, learn the tool and expand once the team can actually act on the findings.
6Secure Score and Recommendations
The secure score turns a long list of findings into a single number, and recommendations explain how to move it.
What the score means
The secure score is a percentage that reflects how many of the recommended security controls your resources satisfy. A higher percentage means fewer open weaknesses. The score is calculated per environment and can be viewed in aggregate, which allows leaders to track progress over months and to compare teams in a fair way. It is a measure of configuration health, not a guarantee of safety.
Anatomy of a recommendation
Each recommendation names the problem, lists the affected resources, explains why it matters, gives the steps to fix it and shows severity and effort. Recommendations are grouped under security controls, so that a team can work through a theme, such as restricting access to management ports, in one effort. Fixing every resource in a control earns the points for that control.
Description
What is wrong and why it increases the chance of an attack.
Affected resources
The exact resources that fail the check, grouped by status.
Remediation steps
Manual instructions, and for some recommendations a quick fix option.
Severity and risk level
How serious the issue is, often adjusted by whether an attack path exists.
Owner and due date
Optional governance information assigning who fixes it and by when.
Exemption option
A documented way to accept or waive a finding with a reason and an expiry.
Quick fix, enforce and deny
For certain recommendations, Defender for Cloud offers a quick fix button that applies the change for you across many resources. Some also support enforce and deny modes, which use Azure Policy to automatically correct new resources or block the creation of non-compliant ones. These are powerful because they stop the same mistake from returning, but they must be used carefully, since blocking a deployment can interrupt a team’s work.
A recommendation list is like a doctor’s advice sheet. Some items are simple and can be done right in the clinic, which is the quick fix. Others change daily habits, which is the deny setting that stops unhealthy choices from being made at all.
Do not chase points. Fix what protects the most valuable and most exposed resources first, even if another control would raise the score faster. The goal is reduced risk, not a pretty number.
7Security Standards, Initiatives and Azure Policy
Behind every recommendation is a rule, and those rules are organized into standards.
Microsoft cloud security benchmark
By default, Defender for Cloud assesses Azure resources against the Microsoft cloud security benchmark. This is a set of security best practices covering areas such as identity, network security, data protection, logging and incident response, mapped to well-known frameworks. It gives you a sensible starting standard without any configuration.
How the rules are delivered
Technically, a standard is delivered as an Azure Policy initiative, which is a bundle of policy definitions assigned to a scope such as a subscription or a management group. Each policy checks one setting. When a resource fails, the result flows into Defender for Cloud as part of a recommendation. This is why people with Azure Policy experience find Defender for Cloud familiar.
flowchart TD
STD["Security standard, for example the Microsoft cloud security benchmark"] --> INI["Policy initiative assigned to a scope"]
INI --> P1["Policy: storage must require secure transfer"]
INI --> P2["Policy: management ports must be restricted"]
INI --> P3["Policy: disks must be encrypted"]
P1 --> REC["Recommendation in Defender for Cloud"]
P2 --> REC
P3 --> REC
A standard is like a building code, an initiative is the checklist an inspector carries, and each policy is a single line on that checklist, such as “every stairwell must have a handrail”.
Custom standards
Organizations often have their own rules beyond the standard benchmark, such as requiring a certain tag or a specific encryption setting. You can create custom standards that combine built-in and custom policies, and assign them to chosen scopes. The results appear alongside the default recommendations, so your internal rules receive the same visibility as the global ones.
Assigning many overlapping standards at the same scope. The same weakness can then appear as several recommendations, which inflates the list and makes the team feel overwhelmed. Choose the standards you truly need.
8Regulatory Compliance
Many organizations must prove that their cloud setup follows an industry or legal standard, and Defender for Cloud helps gather that evidence.
The compliance dashboard
The regulatory compliance dashboard maps your resource assessments to the controls of recognized standards. Examples include standards for payment card data, information security management, government security baselines and common industry frameworks. For each control, the dashboard shows which automated checks pass or fail, so you can see how close you are to meeting it.
What it can and cannot prove
Automated checks cover the technical settings that can be read from the cloud. Many compliance controls, however, concern people and process, such as staff training, written policies and physical security. The dashboard marks these as needing manual evidence. Treat it as a strong source of technical evidence and a to-do list, not as a certificate that you are compliant.
Audit preparation
Before an audit, a team exports a compliance report that lists passing and failing controls. They fix the failures, record exemptions with reasons for the rest and hand the auditor a clear, dated record.
Continuous assurance
Instead of scrambling once a year, a team reviews the compliance view monthly. Drift is caught early, because a new resource that breaks a control appears quickly in the dashboard.
Regional and sector requirements
A company operating in several countries enables different standards on different subscriptions, so each environment is measured against the rules that apply to it.
The compliance dashboard is like a school report card for technical controls. It shows your marks in each subject, but it cannot grade the parts that need a teacher’s own judgment, such as classroom behavior.
Record why each exemption was granted, who approved it and when it expires. An auditor trusts a documented, time-limited exception far more than a silent one.
9Attack Path Analysis and the Cloud Security Explorer
Not all weaknesses are equal, and these features show which ones an attacker could really use.
The idea of attack paths
A single weakness is often harmless. A virtual machine with an old, vulnerable program may be unreachable from the internet. But when several small problems line up, such as a machine exposed to the internet, a known vulnerability on it, a powerful identity attached to it and a storage account holding sensitive data that identity can read, they form a path from the outside to something valuable. Attack path analysis finds these chains and ranks them.
flowchart LR
NET["Internet"] --> VM["Virtual machine exposed to the internet"]
VM --> VUL["Known vulnerability on the machine"]
VUL --> ID["Machine has a powerful managed identity"]
ID --> ST["Storage account with sensitive data"]
Think of a burglar planning a break-in. A broken fence alone is not a disaster, and neither is a spare key under a mat. But a broken fence leading to a back door with a key under the mat, next to a safe that is unlocked, is a clear path worth fixing right now.
Why this changes priorities
Without path analysis, a team sees thousands of separate findings and has no reliable way to rank them. With it, the team can focus on the few findings that break the chain, so fixing one setting can close several paths at once. This is how large organizations reduce real risk with limited staff.
The cloud security explorer
The cloud security explorer lets you ask questions of the relationship graph that Defender for Cloud builds from your environment. You can look for patterns such as virtual machines that are exposed to the internet and can read a particular database, or container images that have a serious vulnerability and are running in production. Query templates help beginners, and the same graph underlies attack paths.
What is exposed?
List internet-facing resources that also have serious vulnerabilities or weak settings.
What can reach my data?
Find identities and machines that have access to storage or databases holding sensitive information.
What is over-privileged?
Identify accounts and machines with far more rights than their job needs.
What runs vulnerable code?
Trace container images and machines carrying known vulnerabilities back to the repository that produced them.
Review attack paths weekly and assign the top few for fixing. Because one fix often closes several paths, a short regular routine produces a visible drop in real exposure.
10The Defender Plans at a Glance
Workload protection comes as separate plans, each aimed at one kind of resource, which you can enable independently.
Defender for Servers
Threat detection, vulnerability assessment and hardening features for virtual machines and servers in any cloud or data center.
Defender for Containers
Protection for Kubernetes clusters, container registries and running containers, including image scanning.
Defender for Storage
Detects suspicious access to storage accounts, can scan uploaded files for malware and helps spot sensitive data exposure.
Defender for Databases
Detects unusual activity and attacks against managed databases and database software on machines.
Defender for App Service
Watches web apps and their hosting for signs of attacks and suspicious behavior.
Defender for Key Vault
Alerts on unusual attempts to read secrets, keys and certificates.
Defender for Resource Manager
Monitors management operations for risky behavior, such as suspicious changes made with stolen credentials.
Defender for APIs
Discovers and protects application programming interfaces published through Azure API Management.
The plans are like specialist guards in a museum. One watches the paintings, another the jewelry, another the vault and another the main gate. Each knows the tricks used against the thing it protects.
Choosing plans
Plans are priced by the resource they protect, so choose them according to value and risk. A subscription full of production databases and public web apps deserves the matching plans. A temporary sandbox may need only the free posture features. Microsoft regularly adds, merges and retires plans and features, so read the current plan list when you decide and revisit your choices every few months.
Enabling plans on resources nobody owns or ever looks at. A plan generates alerts only as useful as the people reading them, so match every enabled plan with an owner and a response routine.
11Defender for Servers
Servers are among the most common targets, and this plan brings several protections together.
What it offers
Defender for Servers protects virtual machines and physical servers, whether in Azure, other clouds or on-premises through Azure Arc. It integrates Microsoft Defender for Endpoint, which detects malicious behavior on the machine itself. It adds vulnerability assessment, which finds missing patches and weak configurations, and a set of hardening tools. It comes in two plan levels, with the higher level adding more capabilities. Check the current comparison to see exactly which features sit in which level.
Endpoint detection
Spots malware, suspicious processes and attacker behavior on the server.
Vulnerability assessment
Finds missing patches and vulnerable software, with agentless scanning available.
Just-in-time access
Keeps management ports closed and opens them briefly, for approved users, only when needed.
File integrity monitoring
Tracks changes to important system and application files, helping detect tampering.
Secret and malware scanning
Looks for exposed secrets and malicious files on disks without installing extra software, where agentless scanning is used.
Adaptive network hardening
Suggests tighter network rules based on how machines actually communicate.
Just-in-time access explained
Attackers constantly try to connect to remote management ports, such as those used for remote desktop and secure shell, because a guessed password gives them full control. Just-in-time access keeps those ports closed by default. When an authorized person needs access, they request it for a chosen time and from a chosen address, the port opens, and then it closes again automatically.
sequenceDiagram
participant A as Administrator
participant D as Defender for Cloud
participant N as Network rules
participant V as Virtual machine
A->>D: Request access for two hours from my address
D->>D: Check permissions and policy
D->>N: Open management port for that address only
A->>V: Connect and do the work
D->>N: Close port when time expires
Just-in-time access is like a hotel giving you a room key only for the nights you booked. The door exists all year, but the key works only when you are an expected guest.
Exposed management ports are a very common cause of server compromise. Closing them with just-in-time access, or by removing public access entirely, is one of the most valuable early fixes.
12Defender for Containers
Containers change quickly and come from many sources, so protection must cover the image, the cluster and the running workload.
Three stages of protection
Defender for Containers works across the life of a container. Before it runs, images in container registries are scanned for known vulnerabilities. While it is being scheduled, the cluster’s configuration is checked against security recommendations, and policies can block unsafe deployments. While it runs, a sensor on the cluster watches behavior for signs of attack, such as unexpected programs launching inside a container.
Build and store
Images are scanned in the registry for known vulnerabilities, and findings are tied back to the code repository that produced them where connected.
Deploy
Cluster configuration is assessed, and admission controls can reject workloads that break security rules.
Run
Runtime threat detection watches for suspicious behavior, and alerts name the cluster, node and container involved.
It is like food safety in a restaurant supply chain. Ingredients are checked on arrival, the kitchen is inspected before service, and a supervisor watches the cooking line for anything unusual during service.
Supported platforms
The plan covers Azure Kubernetes Service and also Kubernetes clusters in other clouds and on-premises, often through Azure Arc or through the cloud connectors. The exact feature set varies by platform, so check which capabilities apply to each cluster type in your estate.
Advantages
- Covers images, clusters and running workloads in one plan
- Agentless scanning reduces rollout effort for visibility
- Findings can link a vulnerable image back to its source repository
- Works across several clouds and on-premises clusters
Trade-offs
- Runtime detection needs a sensor deployed on clusters
- Image scanning produces many findings that need triage
- Admission controls can block deployments if rules are too strict
Treating every image vulnerability as equally urgent. Focus first on those in images that are actually running, are exposed to the internet and have a fix available.
13Protecting Data, Apps, Secrets and Management Operations
Several plans guard the places where your most valuable information and control points live.
Defender for Storage
Storage accounts often hold sensitive files and are a favourite target. The plan detects unusual access, such as downloads from anonymous locations or access from suspicious addresses. It can also scan files for malware as they are uploaded and can flag potential exposure of sensitive data, so a harmful file does not quietly spread through your applications.
Defender for Databases
This plan watches managed databases and database software on machines for signs of attack, such as attempts to guess passwords, unusual queries that look like injection attempts, and access from unfamiliar places. It brings database-specific knowledge that general network monitoring does not have.
Defender for App Service
Web applications face constant probing. The plan analyzes the activity of hosted apps and the underlying service, and raises alerts for behavior such as attempts to run suspicious commands or connections to known malicious addresses.
Defender for Key Vault
A key vault holds the secrets that unlock everything else. The plan alerts on unusual patterns of access, such as a user suddenly reading many secrets from a new location, which may mean credentials were stolen.
Defender for Resource Manager
Every action that creates, changes or deletes a resource passes through the management layer. The plan looks for risky operations, such as a flood of changes from an unusual place or the use of known attacker tools, helping catch attacks that use stolen administrator credentials.
Defender for APIs
Interfaces are how applications talk to each other, and they are often left unprotected or forgotten. The plan helps find published interfaces, assess their risks and detect abnormal use, such as unusually high volumes of requests or attempts to access data in unexpected ways.
If your cloud is a bank, storage and databases are the vault rooms, the key vault is the key cabinet, the management layer is the manager’s office, and the interfaces are the teller windows. Each needs its own watchful guard.
If budget is limited, protect the management layer and the key vault early. Stolen administrator rights and stolen secrets let attackers undo almost every other control.
14Agentless Scanning and Agent-Based Protection
Choosing between reading from the outside and running software inside is a recurring design decision.
How agentless scanning works
For virtual machines, agentless scanning takes a snapshot of the machine’s disks, scans the copy in a secure Microsoft-managed environment and then deletes the copy. Nothing is installed on the machine and nothing slows it down. The scan can find vulnerabilities, installed software, secrets left on disk and malware. Because it works from the platform side, it also covers machines that your teams forgot to set up with agents.
flowchart LR
VM["Virtual machine and its disks"] --> SNAP["Snapshot of the disks"]
SNAP --> SCAN["Scan in secure managed environment"]
SCAN --> FIND["Findings: vulnerabilities, secrets, malware, software inventory"]
SCAN --> DEL["Snapshot copy deleted"]
FIND --> DASH["Recommendations and attack paths"]
When agents still matter
Agentless scanning looks at stored data at intervals, so it does not see what is happening inside the machine in real time. Agent-based protection, such as Defender for Endpoint, observes live processes, network connections and behavior, which is essential for catching an attack while it is in progress. Most mature setups combine both: agentless for broad, effortless coverage of posture, and agents for real-time threat detection on important workloads.
| Aspect | Agentless | Agent-Based |
|---|---|---|
| Installation | None; works through the cloud platform | Software must be deployed and maintained |
| Coverage speed | Quick across whole environments | Depends on rollout progress |
| Real-time behavior | Limited; periodic scans | Strong; watches live activity |
| Performance impact | Very low on the machine | Small but present |
| Typical use | Posture, vulnerabilities, discovery | Threat detection and response |
Agentless scanning is like a photograph of a room taken from the doorway: you see what is there without disturbing anyone. An agent is like a guard standing inside the room, who sees every movement as it happens.
Assuming that agentless scanning replaces real-time protection. It tells you where the weak points are, but it will not catch an attacker moving through a machine at this moment.
15DevOps Security: From Code to Cloud
The cheapest time to fix a security problem is before it ever reaches production, and DevOps security brings that idea into Defender for Cloud.
Connecting code platforms
Defender for Cloud can connect to code platforms such as GitHub, Azure DevOps and GitLab. Once connected, it inventories repositories and pipelines, assesses their security settings and shows findings from scanning tools that run on code. The results appear next to your cloud findings in a single place.
What gets scanned
Infrastructure as code
Templates that create cloud resources are checked for risky settings before they are deployed.
Secrets in code
Passwords, keys and tokens accidentally committed to repositories are detected so they can be revoked.
Code weaknesses
Static analysis finds insecure coding patterns in the application source.
Dependencies
Libraries with known vulnerabilities are listed, showing which projects use them.
Container images
Images built in pipelines are scanned for known weaknesses before they are pushed to a registry.
Repository and pipeline settings
Checks whether protections such as branch rules and access limits are configured safely.
Code-to-cloud mapping
One of the most valuable ideas is connecting what runs in the cloud back to the code that produced it. If a container in production has a serious vulnerability, the mapping can show which repository and pipeline built it, so the right developer receives the fix request. This turns an anonymous finding in the cloud into a specific task for a specific team.
flowchart LR
CODE["Code repository"] --> PIPE["Build pipeline with security scans"]
PIPE --> IMG["Container image in registry"]
IMG --> RUN["Workload running in cloud"]
RUN --> FIND["Cloud finding in Defender for Cloud"]
FIND -.->|Mapped back to| CODE
Code-to-cloud mapping is like a food recall that can trace a contaminated product on a shelf back to the exact farm and batch, so the problem is fixed at its origin instead of only at the shop.
Bring findings to developers where they already work, such as pull request comments, with clear fix guidance. Findings that live only in a security portal are easy to ignore.
16Multicloud and Hybrid Coverage
Most real organizations use more than one cloud, and Defender for Cloud is designed to follow them.
Connectors
To bring Amazon Web Services or Google Cloud under management, you create a connector in Defender for Cloud. The connector uses a controlled, limited-permission identity in the other cloud to read configuration and deploy needed components. After connection, those environments appear in the same inventory, are assessed against standards, produce recommendations and can enable matching protection plans.
Azure
Subscriptions are covered natively, with foundational posture on by default.
Amazon Web Services
Accounts or whole organizations are connected, with posture assessment and selected protection plans.
Google Cloud
Projects or organizations are connected, with similar posture and workload protection capabilities.
On-premises and other servers
Machines are brought in through Azure Arc, so they receive server protection like any cloud machine.
Code platforms
GitHub, Azure DevOps and GitLab connect for code and pipeline security.
Multicloud coverage is like a security company that guards several buildings in different towns from one control room, using the same checklist and the same alarm screen for all of them.
Benefits and limits
Advantages
- One inventory and one measure of risk across clouds
- Common standards applied everywhere
- Attack paths can span resources in connected environments
- Consistent alert and response processes
Trade-offs
- Feature depth can differ between clouds
- Connectors need permissions inside the other cloud, which must be reviewed
- Recommendations must still be fixed using each cloud’s own tools
Assuming that connecting another cloud automatically fixes anything there. Defender for Cloud shows what to fix, but your teams must still make changes in each environment using appropriate processes.
17Security Alerts, Incidents and Investigation
When protection plans detect something suspicious, they raise alerts, and the quality of your response determines how much damage follows.
Anatomy of an alert
An alert describes a suspected threat on a specific resource. It includes a title, a severity, a description of what was detected, the affected resource, a timeline of related activity and suggested next steps. Alerts are also mapped to the MITRE ATT&CK framework, a shared catalogue of attacker tactics, which helps analysts understand where in an attack chain the activity fits, such as initial access or credential theft.
Incidents
Attacks rarely produce one clean alert. A single intrusion might trigger alerts about a suspicious sign-in, an unusual process, a connection to a bad address and a data download. Defender for Cloud correlates related alerts into an incident, which gives the analyst one story to investigate rather than many disconnected notices. This reduces noise and speeds up understanding.
flowchart TD
A1["Alert: suspicious sign-in to virtual machine"] --> INC["Incident: likely compromised server"]
A2["Alert: unusual process started"] --> INC
A3["Alert: connection to known malicious address"] --> INC
A4["Alert: large data download from storage"] --> INC
INC --> INV["Investigate timeline and affected resources"]
INV --> RESP["Contain, remediate and record lessons"]
Separate alerts are like individual witness statements, one about a broken lock, one about footsteps and one about a missing laptop. An incident is the detective’s summary showing that all three belong to the same burglary.
Triage in practice
Read severity and context
Decide quickly whether this looks like a real attack, a test or a normal but unusual activity.
Check the timeline
See what happened before and after the alert, and which accounts and resources are involved.
Contain
Isolate the machine, disable the account or revoke the key, depending on what the evidence suggests.
Remediate and learn
Remove the cause, fix the weakness that allowed it and record what monitoring or posture change would have prevented it.
Suppression and tuning
Some alerts are expected in your environment, such as a security scanner that looks like an attacker. Suppression rules can hide specific alerts that you have reviewed and decided are harmless, in defined scopes and for a defined time. Tuning keeps the alert list focused, but every suppression is also a blind spot, so keep them narrow, documented and reviewed.
Suppressing broad categories of alerts because the volume is annoying. Real attacks hide inside the noise you silenced. Fix the cause of noisy alerts or narrow the suppression tightly.
18Automation, Continuous Export and Sentinel
Findings are most useful when they flow automatically to the people and systems that act on them.
Workflow automation
Workflow automation lets you attach a Logic App to events in Defender for Cloud. The trigger can be a new security alert, a recommendation changing state or a change in regulatory compliance. The workflow can then open a ticket, post to a team chat, ask a manager for approval or start a fix. This turns detection into a repeatable response without anyone watching the portal all day.
Continuous export
Continuous export streams alerts, recommendations, secure score and compliance data to destinations you choose, such as a Log Analytics workspace or an Event Hub. This lets you keep long-term history, build custom dashboards and feed other tools. It is also the route by which data reaches external security platforms.
Microsoft Sentinel and the unified portal
Microsoft Sentinel is a security information and event management service that collects data from many sources and lets analysts search, correlate and respond. Defender for Cloud alerts can flow into Sentinel, where they are combined with identity, network and application events. Microsoft is also bringing Defender products together in a unified security portal, so analysts can see incidents across products in one place.
flowchart LR
DFC["Defender for Cloud alerts and recommendations"] --> WA["Workflow automation with Logic Apps"]
DFC --> CE["Continuous export"]
WA --> TK["Ticket, chat message or approval"]
CE --> LA["Log Analytics workspace"]
CE --> EH["Event Hub for external tools"]
LA --> SEN["Microsoft Sentinel for correlation and response"]
Create tickets
Open a work item for each high-severity recommendation, assigned to the owning team.
Notify the right people
Send alerts about specific resource groups to the team that owns them, instead of to everyone.
Contain automatically
For clear, high-confidence cases, isolate a machine or revoke access, with human approval where risk is high.
Archive for audit
Keep a long-term record of posture and alerts for compliance and trend reporting.
Automation is like a fire alarm connected to the fire station. The alarm does not only ring in the building; it also dials the right people with the address, so help starts moving the moment smoke is detected.
Automate notification and evidence gathering freely. Automate destructive containment only where the detection is reliable, and add an approval step when a wrong action would interrupt critical services.
19Governance: Owners, Due Dates and Exemptions
A finding with no owner is just a wish, and governance is how findings become finished work.
The accountability gap
In many companies, the security team sees the problems, but a different team owns the resources. Without a clear link, findings sit unread for months. Governance rules in Defender for Cloud assign an owner and a due date automatically to recommendations that match certain conditions, for example all high-severity recommendations in the production subscription. Owners receive notifications and the security team can report on overdue items.
Define the rule
Choose the scope and severity of recommendations that need an owner, and how to find that owner, such as a resource tag.
Assign automatically
New matching recommendations receive an owner and a due date without manual effort.
Remind and escalate
Owners and their managers are notified before and after the due date.
Report
Leadership sees how many items are open, overdue or fixed, per team.
Exemptions done properly
Sometimes a recommendation cannot or should not be followed, because the resource is a short-lived test, the risk is accepted by the business or a compensating control exists. An exemption records that decision with a category, a reason, an approver and an expiry date. The recommendation stops lowering the score while the exemption is valid, but the decision remains visible and returns for review when it expires.
Governance is like a repair request system in a building. Every reported fault gets a name next to it and a deadline. If the owner decides not to fix something, the reason is written down and checked again at a later date.
Problem
The security team exempts hundreds of recommendations with no reason and no expiry to make the secure score look healthier before a management review.
Why It’s Harmful
The score no longer reflects reality, real weaknesses are hidden and nobody remembers why items were waived. The organization feels safe when it is not.
Correct Approach
Allow exemptions only with a documented reason, an approver and an expiry date, and review expiring exemptions regularly. Report the score with and without exemptions.
20Access Control, Scale and Enablement with Policy
A tool that protects many subscriptions needs sensible permissions and a consistent way to switch things on.
Roles
Defender for Cloud uses Azure role-based access control. The Security Reader role lets people view recommendations, alerts and scores without changing anything. The Security Admin role allows changing security policies, dismissing alerts and managing plans. Owners and contributors of a subscription can also act on resources. Giving most people read-only access and restricting administrative rights to a small group follows the principle of least privilege.
| Role | Typical Rights | Who Usually Holds It |
|---|---|---|
| Security Reader | View recommendations, alerts and compliance | Auditors, engineers, managers |
| Security Admin | Change policies, plans and alert handling | Security operations leads |
| Contributor or Owner | Change resources to apply fixes | Resource owners and platform teams |
Management groups and scale
Large organizations group subscriptions into management groups, and Defender for Cloud can apply standards and view posture at that level. This lets a central team set a baseline for hundreds of subscriptions at once and see them in one view. It also supports per-team views, so each team sees only what it needs.
Enabling plans consistently
Switching plans on manually in each subscription does not scale and leaves gaps when new subscriptions appear. Azure Policy and infrastructure templates can enable plans automatically for new and existing subscriptions, so the baseline protection is applied by default. Pair this with tags or management group placement to decide which plans go where.
Management groups are like a company’s regional offices. Head office sets the basic safety rules for every office, while each office manager can handle details for their own building.
Define your landing zone, the standard setup for a new subscription, so that security plans, standards and contacts are configured from day one. Retrofitting later is slower and misses resources created in the meantime.
21Cost and a Sensible Rollout Plan
Security spending should follow risk, and a staged rollout keeps both cost and workload under control.
How pricing works
Foundational posture features have no additional charge. Paid plans are usually billed per protected resource over time, such as per server per hour, per storage account or per container core, with details differing by plan. Costs therefore grow with the size of your estate and the number of plans enabled. Microsoft provides a trial period for many plans and a pricing calculator, and the exact prices change, so always check current information.
A staged rollout
See what you have
Connect all environments and review the inventory and the free secure score. Learn the baseline before spending anything.
Protect the crown jewels
Enable plans on the production subscriptions that hold sensitive data and public-facing services first.
Fix the top risks
Use attack paths and high-severity recommendations to focus the first fixing effort, and assign owners.
Connect response
Send alerts to the on-call process, set up automation and integrate with your security monitoring platform.
Expand and refine
Extend to other subscriptions and clouds, tune noisy alerts, review plan choices and track improvement over time.
A rollout is like insuring a growing business. You begin by listing your assets, then guard the most valuable ones first, and add more cover as you learn where the real risks are.
Leaving expensive plans on forgotten development environments. Review which resources truly need paid protection every quarter, and remove plans where the value is low.
22Design Patterns and Anti-Patterns
Teams that use Defender for Cloud well share a few habits, and teams that struggle share a few traps.
Patterns worth adopting
Risk-first prioritization
Work is ordered by exposure and impact, using attack paths and resource importance, not by how many points a fix would add to the score.
Policy-driven baseline
New subscriptions automatically receive the standards, plans and security contacts defined by the central team, so there is no window of unprotected resources.
Owners for everything
Governance rules ensure every important recommendation has an owner and a due date, and progress is reviewed in a regular, short meeting.
Shift-left feedback
Code and infrastructure templates are scanned in pipelines, and developers see findings in pull requests, so weaknesses are fixed before they reach the cloud.
Connected response
Alerts reach the on-call process through automation, and a security monitoring platform correlates them with identity and network signals.
Traps to avoid
Problem
Every plan is enabled everywhere, thousands of recommendations and alerts appear, and nobody is assigned to read them.
Why It’s Harmful
The bill rises, the team is overwhelmed, and real warnings are lost among the noise. Leadership concludes that the tool is not useful.
Correct Approach
Enable plans in stages by risk, assign owners, tune alerts and review progress regularly. Match the number of enabled features to the capacity to act on them.
Problem
The team treats the secure score as the only goal and fixes whatever raises the number fastest, while serious exposed resources remain unaddressed.
Why It’s Harmful
The score improves while real risk stays high. The most dangerous paths to valuable data remain open because their fixes carry few points.
Correct Approach
Use the score for trend reporting, but prioritize by attack paths, internet exposure and data sensitivity.
Problem
Alerts go to a shared mailbox that nobody monitors, and there is no written process for who investigates and how quickly.
Why It’s Harmful
Detection without response is only record-keeping. An attacker can stay inside the environment for weeks while alerts pile up unread.
Correct Approach
Route alerts to an on-call process with defined severities and response times, rehearse incidents and review each real one afterwards.
23Best Practices and Real-World Scenarios
A short checklist, followed by examples of the ideas working together.
Best practices
- Connect every environment so nothing hides outside the inventory
- Prioritize by attack paths, exposure and data sensitivity
- Use governance rules to give every key finding an owner
- Prefer agentless scanning for coverage and agents for live detection
- Enable plans by policy so new subscriptions are protected automatically
- Send alerts into a defined response process and review incidents
Common mistakes
- Chasing score points instead of reducing real risk
- Enabling every paid plan everywhere on day one
- Granting exemptions without reasons or expiry dates
- Suppressing broad alert categories to reduce noise
- Leaving management ports open to the internet
- Assuming connected clouds are fixed automatically
Real-world scenarios
A retailer closing hidden doors
After connecting its subscriptions, a retailer finds dozens of virtual machines with open management ports and several storage accounts reachable from the internet. Attack path analysis shows one machine with a powerful identity linked to customer data. The team closes that path first, enables just-in-time access, and the exposure falls within weeks.
A bank preparing for an audit
A bank maps its production subscriptions to a payment card standard in the compliance dashboard. Automated checks show which technical controls fail. The team fixes them, records time-limited exemptions with approvers for the rest, and exports a dated report for the auditor.
A software company stopping a vulnerable release
A company connects its repositories and registries. A serious library vulnerability is found in an image already running in production. Code-to-cloud mapping names the repository and pipeline, a ticket is raised automatically for the owning team, and a patched image is deployed the same day.
sequenceDiagram
participant X as Attacker
participant VM as Exposed server
participant D as Defender for Cloud
participant S as Security team
participant L as Automation
X->>VM: Repeated attempts to guess remote login
VM-->>D: Suspicious sign-in activity detected
D->>S: High severity alert grouped into an incident
D->>L: Trigger workflow
L->>S: Open ticket with evidence and affected resources
S->>VM: Isolate server and reset credentials
S->>D: Record lessons and close incident
24Frequently Asked Questions
Part of it is. Foundational posture management, including the secure score and recommendations, is available without extra charge. Advanced posture features and the workload protection plans are paid and are generally billed per protected resource.
Defender for Cloud specializes in the security of cloud resources, covering posture and workload protection. Sentinel collects and correlates security data from many sources across the organization and supports investigation and response. They work together, with Defender for Cloud alerts flowing into Sentinel.
No. It can also connect to Amazon Web Services, Google Cloud, on-premises servers through Azure Arc and code platforms such as GitHub, Azure DevOps and GitLab.
It shows the percentage of recommended security controls that your resources satisfy. It is a good trend indicator of configuration health, but it does not guarantee safety, and it should not be the only measure of risk.
They are chains of weaknesses, such as internet exposure, a vulnerability and a powerful identity, that together let an attacker reach something valuable. Showing these chains helps you fix the few issues that matter most.
Not for everything. Agentless scanning gives broad visibility into vulnerabilities and other issues without installing software. Agents such as Defender for Endpoint are still valuable for real-time threat detection on important servers.
Many recommendations come from Azure Policy definitions grouped into initiatives. Policy can also enforce or deny certain configurations, so the two work together for assessment and prevention.
Enable plans in stages, focus on high-severity and high-confidence alerts, use incidents to group related alerts, tune with narrow suppression rules, and route alerts to the teams that own the resources.
For some recommendations it offers quick fixes and enforce or deny options, and workflow automation can start responses. Destructive or disruptive actions should usually include human approval.
Yes, it maps resource checks to many regulatory standards and shows pass or fail status for technical controls. It does not cover process and people controls, which require manual evidence, so it supports compliance but does not certify it.
Open the free secure score and recommendations, connect all your environments, fix exposed management ports and public storage first, and then enable protection plans on your most important production resources.
25Summary and Key Takeaways
Microsoft Defender for Cloud combines posture management and workload protection into a single cloud-native approach. It discovers your resources across Azure, other clouds, servers and code platforms, scores their configuration, ranks the weaknesses that attackers could actually use, and protects servers, containers, data stores, secrets and interfaces with dedicated plans. Alerts and incidents guide investigation, while governance, automation and integration with security monitoring tools turn findings into finished work. The best results come from a staged rollout, clear ownership, risk-based priorities and a tested response process, rather than from switching on every feature at once.
Key Takeaways
- Two jobs in one service — posture management shows what is exposed, and workload protection detects what is under attack.
- Start free, grow deliberately — foundational posture is a quick first step, and paid plans should follow risk and value.
- Prioritize by real exposure — attack paths, internet exposure and data sensitivity matter more than raw score points.
- Mix agentless and agent-based — agentless scanning gives wide coverage cheaply, while agents give real-time detection where it counts.
- Shift left and map to code — DevOps security and code-to-cloud mapping send fixes to the teams that can make them.
- Make findings someone’s job — governance rules, owners, due dates and documented, expiring exemptions turn warnings into action.
- Connect detection to response — route alerts into automation, a monitoring platform and a rehearsed on-call process, and learn from every incident.