Microsoft Defender for Cloud can assess supported virtual machines by scanning disk snapshots outside the guest operating system. This agentless model provides software inventory, vulnerability and secret-related analysis in supported plans, and malware scanning in the plans that include that capability, without requiring a scanner process to run inside each VM.
For teams working around Microsoft SC-500 cloud-security responsibilities, agentless scanning is useful because it extends coverage to machines that may not have a healthy security agent. It should not be confused with continuous endpoint detection, however. The scan is periodic and point-in-time, and supported coverage depends on machine state, disk layout, encryption permissions, cloud connector configuration, and service-plan features.
Microsoft’s current architecture creates secure copies of disks, analyzes the operating-system configuration and file system in an isolated regional scanning environment, extracts the required metadata, and removes the temporary snapshot copy. Understanding that workflow helps security teams interpret both the strengths and the gaps.
Agentless scanning complements endpoint agents rather than replacing them
An in-guest endpoint agent can observe runtime processes, network behavior, memory activity, and events as they occur. Agentless scanning examines disk content and configuration from outside the running guest.
The two models answer different questions. Agentless analysis is strong for inventory and posture visibility without deployment friction. Runtime detection remains important for activity that never persists to disk or that must be detected immediately.
The architectural perspective in Defender for Cloud design is useful: security capabilities should be evaluated by the coverage they add and the dependencies they introduce, not by whether they are labeled “agentless” or “agent-based.”
Snapshot-based analysis reduces guest impact
Defender for Cloud uses disk snapshots or equivalent cloud mechanisms so the scan does not need to consume normal VM CPU and memory. The copied snapshot remains regionally controlled according to the service design and is used only long enough to collect the metadata needed for the analysis.
This out-of-band model is valuable for performance-sensitive servers and for environments where installing additional software is difficult. It also means that scan timing matters. The scanner sees a point-in-time representation, not every state the machine passed through between scans.
Security teams should therefore treat findings as periodic posture evidence. A clean scan does not prove that no malicious activity occurred since the last scan.
Plan selection determines which results are available
Agentless machine scanning is associated with Defender CSPM and Defender for Servers Plan 2 for supported capabilities. Agentless malware scanning has more specific plan requirements and is not automatically available simply because some agentless posture features are enabled.
Document which plan each subscription or connected cloud account uses and which findings are expected from that plan. A missing malware alert can be a licensing or feature-configuration issue rather than evidence that the scanner failed.
The broader capability set described in Microsoft Defender cloud security should be mapped to the organization’s actual enabled plans. Product names alone are not enough to define coverage.
Coverage depends on machine and disk support
Not every VM is eligible for full agentless scanning. Current Microsoft guidance lists limits around disk count, total disk size, certain disk types, some file systems, specific storage formats, and resource types.
Large machines can receive partial coverage. For example, when total attached disk size exceeds supported thresholds, only the operating-system disk may be eligible under defined conditions. Unsupported disk types or formats can exclude a machine entirely.
Build a coverage report that distinguishes “feature enabled” from “machine successfully covered.” A subscription-level toggle is not proof that every asset is being scanned.
Running state and scan cadence matter
Agentless scanning is scheduled rather than continuous. Machines that are stopped or deallocated during the scan window may not be assessed in that cycle, and newly enabled environments can take time before results appear.
This matters for ephemeral or cost-optimized workloads that run only briefly. A VM that exists for two hours each night may frequently miss a daily scan schedule. Other security controls may be required for those assets.
Operational dashboards should track the age of the most recent assessment, not just the existence of historical findings. Old results can look current if the team does not display scan freshness.
Customer-managed encryption requires permission design
For encrypted disks that use customer-managed keys, the scanning service needs the documented permissions required to create or access the secure disk copy. Missing Key Vault permissions can silently reduce coverage until the next scan cycle reveals the gap.
Treat these permissions as part of the security architecture, not as an afterthought. Grant only the required role or cryptographic operations to the documented scanner identity and monitor changes that could revoke access.
The identity model should remain consistent with least privilege. Security tooling needs enough access to inspect protected assets, but broad administrative permissions would create unnecessary risk.
Malware scanning is periodic detection, not real-time prevention
Agentless malware scanning can inspect files using Microsoft Defender Antivirus capabilities without running the scanner inside the VM. That can reveal malicious content that another antivirus product missed or excluded.
The service is still periodic. It does not replace real-time malware prevention on workloads that require immediate protection. Large compressed archives, very large file sets, inaccessible files, and other documented conditions can also create partial coverage.
This distinction is why security assessment methods should be treated as complementary. No single scanner proves that a system is secure; each exposes a different class of evidence.
Vulnerability results need prioritization, not just collection
Agentless vulnerability assessment can produce a broad inventory of software and weaknesses across supported machines. The operational challenge is deciding what to fix first.
Prioritize findings using exploitability, internet exposure, asset criticality, available compensating controls, and the business impact of the affected workload. Vulnerability prioritization matters more than raw finding count because remediation capacity is always finite.
Track assets that repeatedly miss scans or remain unsupported. They should have an explicit alternative control rather than disappearing from dashboards.
Exclusions should be governed like any security exception
Defender for Cloud can exclude machines from agentless scanning using supported tagging mechanisms. That is useful for legitimate edge cases, but it creates an obvious bypass if tag assignment is uncontrolled.
Require an owner, reason, scope, and review date for exclusions. Monitor which machines carry exclusion tags and who can modify those tags.
A good exception process makes uncovered assets visible. The objective is not to force scanning on every unsupported system; it is to prevent a temporary workaround from becoming an invisible permanent blind spot.
Integrate findings into investigation and response
Agentless findings become more useful when combined with other Defender signals, asset context, and security operations workflows. A vulnerable package on an isolated test VM is different from the same package on a public production server with suspicious activity.
Use the relationships between Defender for Cloud, Defender XDR, and security operations described in Microsoft security operations to build investigation context rather than treating every scanner finding as an isolated ticket.
Security teams should also validate that alerts and recommendations reach the systems where responders work. A technically successful scan has limited value if its result never becomes part of triage.
Agentless findings are most useful when responders can connect them to the rest of the asset record. Preserve the cloud resource identifier, subscription or account, image or workload ownership, exposure context, and the time of the scan with each triage workflow. A vulnerability on an isolated development VM and the same vulnerability on an internet-facing production system should not enter the response queue with identical urgency.
Because agentless analysis is point-in-time, use it to complement rather than replace continuous signals. Endpoint telemetry can show process execution, network activity, and user behavior between scans; agentless snapshots can reveal software, vulnerabilities, secrets, or malware indicators even where the guest agent is absent or unhealthy. The two collection models answer different questions. A mature investigation asks what each control could have observed during the relevant time window instead of assuming one source is complete.
Coverage reporting should therefore separate eligibility, enablement, successful scanning, and actionable results. A subscription may have the required Defender plan but still contain unsupported disks, machines that are not running when a scan is attempted, encryption configurations that lack required permissions, or deliberately excluded assets. Reporting only “agentless scanning enabled” hides those differences. Measure the percentage of in-scope assets that are actually scannable and recently assessed, then track the exception population as a governed security backlog.
Agentless coverage should be measured as a security control
The useful metric is not “agentless scanning is enabled.” It is the percentage of expected machines that are supported, recently scanned, producing the expected categories of results, and free of unexplained coverage gaps.
Track unsupported configurations, stale assessments, permission failures, excluded machines, and partial malware coverage. Review these metrics after onboarding new subscriptions, changing encryption, or adopting new VM storage types.
Within Microsoft cloud environments, agentless scanning is a strong additional layer because it reduces dependence on guest-agent health. It becomes trustworthy only when teams understand its cadence and limits and continuously verify that the machines they believe are covered are actually producing fresh results.
