Before replacing Qualys scanner appliance scans with Cloud Agents, how do you check which QIDs the agents can actually detect?

## Two sensors, one KnowledgeBase Qualys VMDR collects vulnerability data mainly through two kinds of sensor: - **Cloud Agent**: a lightweight agent on the host. It continuously collects metadata and sends it to the cloud agent platform, where the assessment runs. It needs no network credentials. It reaches the Qualys platform outbound over HTTPS port 443, through a proxy if needed. It installs with local administrator rights on Windows; on Linux, Mac and AIX it needs root, sudo root delegation, or a non-root account with sufficient privileges. Enabling an agent for VMDR also activates a patch-detection engine: a 20 MB download needing 100 MB of free space on each host. - **Scanner appliance**: a physical, virtual or containerized appliance on your network. It runs authenticated and unauthenticated network scans against everything it can route to. Both report findings as QIDs, the KnowledgeBase's unit of detection. But they do not detect the same set. The Qualys onboarding guide says agents suit laptops, cloud instances, roaming hosts and short-lived workloads. Scanner appliances suit network devices, legacy systems, printers and hosts that cannot run an agent. **The general trade-off between agents and network scanners is not the question here. The question is what Qualys's agent modules are documented to detect.** ## Asking the KnowledgeBase The authority is the KnowledgeBase's Supported Modules attribute. The VMDR help page "How to find QIDs that can be detected by Cloud Agents" gives two searches: 1. **Agent-supported QIDs.** Go to VMDR > KnowledgeBase > Search. Select **CA-Windows Agent** and **CA-Linux Agent** in Supported Modules. Click Search. The list shows every QID those agent modules support. 2. **Deep Scan QIDs.** Same search page. Select **Deep Scan - Windows** under Cloud Agent Scan Type to list the Deep Scan QIDs. The same attribute exists as a QQL token. You can ask it of the findings you already hold: ``` vulnerabilities.vulnerability.supportedBy: CA-Linux Agent ``` A QID's discovery type (`vulnerabilities.vulnerability.discoveryTypes`, Remote or Authenticated) tells you how a check can run. It does not tell you whether an agent module supports it. Supported Modules is the field that answers that. ## Running the comparison before you retire scans | Step | What you do | What it tells you | |---|---|---| | 1 | Export the QIDs your appliance scans reported on the pilot group | The detections you rely on today | | 2 | Filter them by `supportedBy` for the agent module of each OS | Which of those an agent will keep reporting | | 3 | List the unsupported QIDs, highest severity first | The coverage you would lose | | 4 | List assets that cannot run an agent | Devices that need an appliance whatever you decide | The usual result is a mixed estate. Agents give continuous data on the hosts they run on, even off the corporate network. Appliances keep scanning network infrastructure and anything that cannot run an agent, and keep confirming findings from the network side. Record the result per segment, not per estate. For each asset, the **Sources** column in the asset view shows which kinds of scan have assessed it. During the pilot, that column is how you prove an agent-only host is still being assessed, rather than just inventoried. Keep the list of unsupported QIDs with the decision. When the KnowledgeBase adds agent support for a QID later, the same search tells you a segment can drop its appliance scans. ## Two behaviours to know before you mix them - **Agent results can close scanner findings.** The same KnowledgeBase page notes that the Cloud Agent closes vulnerabilities the scanner found when the appliance scan is unauthenticated or has limited permissions. On a host covered by both, a status change may come from the agent's view, not from a new appliance scan. - **Agent check-in is not a scan result.** After installing, check the Last Activity column in the Cloud Agent UI to confirm the host appears. Then confirm VMDR shows vulnerability data for it, because enabling the agent for VMDR is a separate activation. ## What a strong answer avoids - Saying "the agent sees everything because it runs as root". The supported-module list is the boundary, not the agent's privileges. - Retiring all appliance scans because agent check-ins look healthy. - Comparing totals rather than QIDs. Two sensors can report similar counts while covering different detections.