What Microsoft Defender for Cloud does today
Microsoft Defender for Cloud provides security posture management and cloud workload protection across Azure and supported multicloud environments. Microsoft’s current Defender for Cloud documentation separates foundational posture capabilities, advanced Defender CSPM capabilities, and workload-protection plans for resource types such as servers, containers, databases, storage, APIs and other supported services.
That distinction matters commercially. Foundational posture capabilities can provide assessment and recommendations, while advanced CSPM and workload-protection plans add capabilities that may be billed according to resource or usage models. The correct design should match the security use case to the plan rather than assuming every resource requires every paid capability.
| Decision area | Question | Evidence |
|---|---|---|
| CSPM depth | Do we need foundational recommendations or advanced risk/context capabilities? | Asset inventory, posture process, attack-path and governance needs |
| Servers | Which machines need endpoint/workload protection and what plan fits? | Server inventory, OS, existing endpoint protection, threat model |
| Containers | Which Kubernetes/container workloads need posture and runtime protection? | Clusters, registries, serverless containers, deployment model |
| Databases | Which databases need vulnerability/threat protection? | Database inventory, data sensitivity, existing controls |
| Storage | Which accounts hold sensitive or exposed data and need workload protection? | Storage inventory, sensitivity, public exposure, transaction pattern |
| APIs / App services | Which internet-facing services create meaningful attack surface? | API/app inventory, exposure and business criticality |
| Operations | Who triages alerts and owns recommendations? | SOC/support model, ticketing, escalation and change authority |
Start with coverage mapping, not feature enthusiasm
An assessment should map subscriptions and resources to current Defender plan status. That reveals inconsistent coverage, duplicated tooling, unprotected critical assets, and subscriptions where paid plans are enabled without a clear owner or use case.
Microsoft provides coverage views and workbooks to show which plans are enabled. The consulting layer adds business context: which resources are critical, which are internet-exposed, which contain sensitive data, what other security products already protect them, and who will act on findings.
Decision rule: enable a paid Defender plan when its protection addresses a defined risk and the organization has an operating owner for the resulting recommendations or alerts.
Foundational CSPM versus Defender CSPM
Microsoft’s current Defender for Cloud pricing and documentation state that Foundational CSPM provides core posture capabilities, while Defender CSPM adds advanced capabilities such as attack-path analysis, agentless scanning, richer risk prioritization, cloud security exploration, governance and other advanced posture features. Exact capabilities and billing units can change, so the implementation should validate the current product pages during design.
The business question is whether advanced context changes decisions. A smaller Azure estate with strong manual review may not need every advanced capability immediately. A large or multicloud estate with many recommendations may benefit from risk prioritization that helps security teams focus on the most consequential exposures.
Understand the two secure score experiences
Microsoft’s June 2026 documentation describes a newer risk-based Cloud Secure Score in the Microsoft Defender portal and a classic secure score that remains available in the Azure portal. The newer model incorporates asset risk factors and criticality, while the classic model is calculated differently. Teams should avoid comparing the two numbers as if they were the same metric.
During an assessment, use score as a trend and posture signal, then inspect the recommendations and attack context behind it. A score change may reflect new assets, new recommendations, expanded multicloud coverage or different calculation scope—not simply security deterioration.
Defender for Servers plan selection should match the need
Microsoft currently documents two paid Defender for Servers plans. Plan 1 focuses on entry-level server protection centered on Defender for Endpoint integration, while Plan 2 adds further capabilities. The assessment should compare the current feature matrix with the organization’s existing endpoint, vulnerability, compliance and monitoring capabilities.
The scope also matters for hybrid and multicloud servers. Azure Arc or other onboarding patterns may be relevant depending on the environment. Do not assume every server can be protected identically without checking supported platforms, deployment dependencies and current Microsoft guidance.
Container protection needs platform context
Container security crosses image vulnerability, cluster configuration, identity, control-plane access, runtime behavior and supply chain. Microsoft has continued to expand Defender container capabilities; July 2026 release notes include new generally available container security functions and serverless-container posture coverage.
A Defender for Containers assessment should inventory AKS and other supported container environments, registry and image workflows, admission controls, runtime protection, alert ownership and existing DevSecOps tooling. Enabling the plan without connecting findings to engineering teams can simply create another backlog.
Database and storage plans should follow data risk
Database and storage protection decisions should consider data sensitivity, exposure, threat model and current controls. Some resources may hold regulated or business-critical data; others may be low-risk development assets. The security value and cost justification can differ.
For storage, transaction or data-scanning behavior may affect pricing depending on the enabled capabilities. For databases, product family and deployment model affect plan applicability. Use the current Defender for Cloud pricing page rather than hard-coding rates into a long-lived architecture document.
Pricing should be modeled from the resource inventory
The roadmap topic includes Defender pricing because buyers need to know whether coverage is economically justified. The safest approach is to calculate cost from the actual billable resource inventory and current Microsoft pricing, then add expected growth. Avoid quoting static dollar amounts in an article because rates, plan names and billing meters can change.
| Pricing input | Why it matters |
|---|---|
| Subscription/resource inventory | Determines which resources can be in scope |
| Plan by resource type | Different protection plans use different billing models |
| Server/storage/database/container counts | May drive resource-based billing |
| Storage scanning or usage features | Some capabilities can introduce usage-based cost |
| Existing security licenses/tools | Avoids paying for capability with no operating value |
| Growth forecast | Prevents underestimating future run rate |
| Pilot scope | Allows cost and alert-volume validation before broad rollout |
Risk prioritization should change the remediation order
Defender for Cloud security recommendations now include richer risk context when the applicable Defender CSPM capabilities are enabled. Microsoft describes factors such as internet exposure, sensitive data, lateral movement and attack paths. These help answer a practical question: which configuration weakness is most likely to matter in this environment?
The security team should still add business context. A technically high-risk resource may be an isolated lab, while a medium recommendation may affect a regulated production workload. The final priority should combine Microsoft risk context with customer criticality and control ownership.
Recommendations need governance and owners
Defender for Cloud can continuously identify findings, but continuous assessment creates continuous work. Establish who receives recommendations, how they are assigned, what SLA or target applies to critical/high risk, how exceptions are approved, and how overdue items are escalated.
Governance rules and workflow features can help, but they should implement a human decision model that is already understood. Automating assignment to the wrong owner only makes the wrong process faster.
Alerts need a SOC or support path
Workload protection can generate security alerts. Before enabling broad coverage, define whether alerts go to an internal SOC, managed security provider, IT operations team, or another responder. Severity should map to business impact and containment authority.
If Microsoft Sentinel is part of the security architecture, decide which Defender alerts and incidents flow into the SIEM experience, how duplication is handled, and where analysts investigate. Product integration should simplify response rather than create parallel queues.
Use a plan comparison that starts with security use cases
A useful comparison does not ask which Defender plan is “best.” It asks which security capability is required for a specific resource class and whether the organization can operationalize it. Foundational CSPM can be the right starting point for posture visibility. Defender CSPM can add advanced context and prioritization. Workload plans address runtime or resource-specific protection. The design may use different coverage for production, regulated, internet-facing and low-risk development resources.
| Use case | Capability to evaluate | Operational question |
|---|---|---|
| Prioritize many posture findings | Defender CSPM risk/attack-path capabilities | Who owns remediation and governance? |
| Protect production servers | Defender for Servers plan options | How does this fit existing endpoint/vulnerability operations? |
| Protect Kubernetes/container workloads | Defender for Containers and CSPM container posture | Who remediates images, cluster settings and runtime alerts? |
| Protect sensitive storage | Defender for Storage and relevant scanning features | How will alerts and scanning cost be governed? |
| Protect databases | Applicable Defender database plans | Who owns vulnerability remediation and database alerts? |
| Protect exposed APIs | Defender for APIs / API posture where supported | Who owns API inventory, exposure and application fixes? |
A responsibility matrix should exist before broad rollout
| Activity | Security team | Platform/workload team | Finance/procurement |
|---|---|---|---|
| Select protection use case | Define threat/risk requirement | Confirm resource scope and technical fit | Review recurring cost |
| Enable plan | Approve security design | Implement under change control | Confirm commercial approval where required |
| Review recommendation | Prioritize security risk | Validate affected resource and remediate | — |
| Triage alert | Investigate and coordinate | Provide workload context / containment help | — |
| Review monthly cost | Explain security coverage/value | Explain inventory growth | Review actual vs modeled run rate |
| Review exceptions | Assess residual risk | Provide technical dependency | Approve budget implications if any |
This matrix protects against a common implementation gap: security enables protection centrally, but engineering teams do not know they now own a new class of recommendations or runtime alerts. A rollout is complete only when the receiving teams understand what changes in their daily work.
Common Defender for Cloud deployment anti-patterns
- Enable every plan everywhere. Security scope is driven by convenience rather than risk and operating value.
- Optimize for secure score only. Teams fix low-impact posture issues while exposed critical assets remain.
- Ignore existing tools. Endpoint, vulnerability or SIEM capabilities overlap and analysts get duplicate work.
- No cost owner. Paid plans expand automatically as cloud resources grow without budget forecasting.
- No remediation owner. Recommendations accumulate because the security team cannot change workloads.
- No alert path. Workload protection produces notifications that are never triaged.
- Static documentation. Plan names, pricing models and product capabilities change but architecture records do not.
Measure value without inventing an ROI percentage
Security value is difficult to reduce to a single savings number because the benefit includes reduced exposure, faster prioritization, stronger detection and improved response. A more defensible review can track coverage of high-value assets, aging of critical/high recommendations, attack paths closed, privileged or public exposure reduced, alert triage performance, and remediation ownership.
Cost should be reviewed alongside those outcomes. If a plan adds material recurring spend but produces no decisions, no alerts used by responders, and no high-value posture insight, revisit the scope. Conversely, a low-cost deployment that protects only low-risk assets may not create meaningful security value.
A practical assessment and implementation sequence
- Inventory. Map cloud accounts/subscriptions, resources, criticality and current plan coverage.
- Define use cases. Identify posture, vulnerability, attack-path and workload-protection needs.
- Model cost. Apply current Microsoft pricing to the agreed scope and growth assumptions.
- Pilot. Enable selected plans in representative scope and observe findings, alerts, integrations and operational load.
- Prioritize remediation. Assign high-risk recommendations and validate ownership.
- Expand coverage. Roll out plans that demonstrated value, using policy/automation where appropriate.
- Operate. Review plan coverage, recommendations, secure-score context, alerts, cost and exceptions on a recurring basis.
Pilot exit criteria
- Current and proposed Defender plans are documented by subscription/resource scope.
- Expected pricing is modeled from the actual inventory using current Microsoft rates.
- Representative recommendations are reaching the correct owners.
- High-severity alerts have a tested triage and escalation path.
- Integrations with ticketing, Defender portal, Sentinel or other SOC tooling work as intended.
- Security teams understand the newer Cloud Secure Score versus classic score where both are used.
- Customer approves the trade-off between security value, operational effort and recurring cost.
Current-product changes make periodic review important
Defender for Cloud evolves quickly. Microsoft’s July 2026 release notes include general availability changes, expanded multicloud coverage, new container capabilities, and blocked onboarding through the plan-enablement API for several deprecated plans. Existing automation and old architecture documents can therefore become stale.
A periodic plan review should check whether enabled plans are still supported, whether resource types changed, whether new capabilities replace custom tooling, and whether cost or operating assumptions remain valid.
When Defender for Cloud is not the whole security program
Defender for Cloud is strong for cloud posture and workload protection, but an Azure security program also needs identity governance, application security, data protection, network architecture, recovery, incident response and organizational policy. A high Defender score cannot prove all of those areas are mature.
Likewise, Defender findings should not be treated as a substitute for a workload threat model or regulatory assessment. Use the product as a security platform and evidence source inside a broader operating model.
What BI Cloud Tech can provide
BI Cloud Tech can support a Defender for Cloud engagement through Defender for Cloud expertise, a broader Cloud Security Assessment, and separately scoped Security Deployments. The work can include coverage review, plan selection, pricing assumptions, risk prioritization, pilot design, implementation and operational handoff.
The assessment should recommend plans and scope; it should not silently enable paid coverage. Customer approval is required for recurring cost and production configuration changes.
The final design should also record the date on which plan features and pricing were reviewed. Defender for Cloud changes quickly enough that this timestamp is part of responsible architecture documentation.
A practical next step
Export or inventory every Azure subscription with current Defender plan status and the count of major protected resource types. Add business criticality and the team that will own recommendations or alerts. Where a paid plan has no defined use case or owner—or a critical workload has no coverage decision—you have the first questions for the assessment. Contact BI Cloud Tech to plan the review.