Most engineers think…
Most people picture Qualys as 'a scanner box you put in the DMZ'. That gets you 20% of the picture — and the wrong 20% for a modern hybrid environment.
Qualys VMDR is a SaaS platform with a sensor fleet: one multi-tenant cloud brain (no server for you to manage) and up to six types of lightweight sensors you deploy where your assets live. Each sensor sees a different slice — the scanner appliance does credentialed network scans, the cloud agent monitors from inside the host continuously, the passive sensor listens on the wire to catch unmanaged and IoT devices, the container sensor scans Docker and Kubernetes workloads, and API/cloud connectors pull inventory directly from AWS, Azure and GCP. Understanding which sensor to place where is what separates a production-ready VMDR deployment from a gap-ridden one.
① The Qualys Cloud Platform — SaaS backbone, not a box
The single most important idea: Qualys Cloud Platform is 100% SaaS. Qualys operates the data centres, the processing pipeline, the Knowledge Base (QKB), and the UI. You never patch a Qualys server, never size a database, and never manage HA. You only deploy sensors where your assets live and then consume results from your browser or API.
The platform is multi-tenant with logical isolation per subscription. Your data stays in the region you chose at signup (US, EU, India, etc.). The backend receives raw scan findings from every sensor, normalises them, correlates against the QKB, calculates a QDS, and surfaces VMDR findings in the dashboard within minutes of a sensor reporting.
Which statement best describes the Qualys Cloud Platform deployment model?
② Sensor types — six ways to see your assets
Qualys gives you six sensor options; most enterprise deployments use three or more together. The Scanner Appliance (physical or virtual) sits inside a network segment and performs active, credentialed scans over the network — the classic approach, best for on-prem servers you cannot install an agent on. The Cloud Agent is a lightweight binary installed directly on the host (Windows, Linux, macOS); it runs continuously, reports every few hours, and never requires open firewall ports inbound — ideal for laptops and cloud VMs. The Virtual Scanner Appliance is the same scanner packaged as a cloud-marketplace image (AWS AMI, Azure VM, GCP instance) so you get network scanning without shipping a physical box.
The three agentless options
The Passive Sensor (a physical or virtual probe receiving a SPAN/mirror port) listens on network traffic and profiles every device it sees — no credentials, no agent, so perfect for printers, cameras, OT, and IoT. CAPS (Cloud Agent as Passive Sensor) extends this capability by letting a deployed cloud agent listen passively on its local subnet, removing the need for a dedicated passive appliance. The Container Sensor deploys as a DaemonSet on each Kubernetes node (or as a Docker container) and scans all images and running containers for vulnerabilities. Finally, Cloud Connectors and API Connectors use provider APIs (AWS, Azure, GCP, GitHub, etc.) to pull cloud account inventory — no sensor deployed at all, just OAuth or IAM credentials.
Physical or virtual probe deployed inside a network segment. Performs active, credentialed scans and sends findings to the Qualys Cloud Platform. Best for on-prem servers where an agent cannot be installed.
Lightweight binary on the host (Windows/Linux/macOS). Runs continuously, detects vulnerabilities without inbound ports, and syncs to the platform every few hours. Covers laptops, cloud VMs, and off-network assets.
Listens on a SPAN/mirror port (or via a cloud agent's NIC in CAPS mode) to profile every device on the wire — no credentials, no agent. Discovers IoT, printers, and unmanaged devices invisibly.
Deployed as a DaemonSet on every Kubernetes node (or as a Docker container). Scans all images and running containers for vulnerabilities, feeding findings back to the Qualys Cloud Platform.
In a Qualys VMDR interview, never just say 'we use scanners'. Name the sensor type and justify it: cloud agent for managed hosts (continuous, no inbound ports), scanner appliance for agentless on-prem, virtual scanner for cloud VPCs, passive sensor for IoT, container sensor for Kubernetes. That specificity signals production experience.
Which sensor deploys as a DaemonSet on every Kubernetes node to scan container workloads?
③ Data flow — from sensor to VMDR dashboard
Every sensor type converges on the same Qualys Cloud Platform endpoint. After a scan or continuous detection cycle, the sensor compresses and encrypts the raw result payload and sends it outbound to the Qualys Platform (443/HTTPS — no inbound ports required). The platform's ingestion layer dequeues the payload, parses asset metadata (IP, hostname, OS, installed software, registry keys) and queues it for the Detection Engine.
The Detection Engine matches the asset manifest against the QKB, assigns a QID to each vulnerability, looks up the CVSS score, and computes the QDS using asset criticality and threat intelligence (RTIs — Real-Time Threat Indicators such as active exploitation, ransomware association, known malware). Within minutes the finding appears in the VMDR dashboard tagged to the asset, with a remediation patch or workaround linked. The data flow is the same whether the data came from an on-prem scanner appliance, a cloud agent on a laptop, or a container sensor on a Kubernetes node — the platform normalises everything into one unified view.
Treating Qualys as a pure network scanner misses CAPS, cloud connectors, and the container sensor — the very sensors that close visibility gaps on IoT, cloud accounts, and ephemeral containers. An interviewer testing VMDR architecture will probe exactly those three gaps.
▶ Watch a cloud agent finding reach the VMDR dashboard
How vulnerability data flows from an on-host cloud agent to a prioritised VMDR finding. Press Play for the healthy path, then Break it to see the classic failure.
An asset sends a finding to the Qualys Cloud Platform. What happens before the finding appears in the VMDR dashboard?
④ Picking the right sensor — matching asset type to method
The interview question you will definitely get: 'How would you deploy Qualys in a hybrid environment?' The answer is sensor selection by asset type. For on-prem servers and VMs where you can install software, prefer the cloud agent — continuous, no open inbound ports. For servers you cannot install an agent on, deploy a scanner appliance in the same VLAN and scan with credentials. For cloud accounts, start with a cloud connector (free, instant inventory) and add cloud agents or virtual scanners for deep vulnerability data. For containers and Kubernetes, deploy the container sensor as a DaemonSet. For unmanaged and IoT devices, deploy a passive sensor or enable CAPS on agents already on that subnet.
Common mistake to avoid
Relying on network scanning alone leaves you blind to laptops that are off-network, containers that spin up and disappear between scan windows, and cloud workloads that block ICMP. The cloud agent + passive sensor (CAPS) combination closes those gaps. In a VMDR interview, stating that combination — and why — is what separates a senior answer from a junior one.
Arjun at a Mumbai financial services firm faces this
VMDR shows thousands of assets discovered but only 30% have any vulnerability data. Scanners are running but most cloud VMs, laptops, and containers appear as 'host alive, no vuln data'.
The deployment relies entirely on network scanner appliances. Cloud VMs are in private subnets the scanner cannot reach, laptops are off-network most of the time, and the container estate was never onboarded.
Check asset coverage in VMDR: filter by 'last scanned date' — the majority show scan attempts but zero findings due to network unreachability or missing credentials. Cloud and container assets show no sensor type at all.
VMDR ▸ Assets ▸ Asset Coverage ▸ Sensor Type filterDeploy cloud agents on all VMs and laptops (covers both on-prem and cloud VMs in private subnets). Add cloud connectors for AWS/Azure accounts for immediate cloud inventory. Deploy the container sensor as a DaemonSet on each Kubernetes node. Enable CAPS on agents in subnets containing unmanaged devices.
After 24 hours, re-check asset coverage: cloud agents report continuously, cloud connectors pull account inventory, container sensor findings appear under the Container Security module, and asset coverage climbs above 90%.
After deploying any new sensor, check VMDR ▸ Assets and filter by sensor type. Confirm the expected asset count is visible and that findings are flowing. A sensor that deployed but cannot reach the platform (blocked proxy, wrong activation key) looks silent — always verify inbound findings, not just sensor deployment.
A company has 500 on-prem servers it can install software on, plus 200 printers and IP cameras it cannot. Which sensor combination covers both groups best?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the difference between a Qualys cloud agent and a passive sensor, and when would you use each? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Qualys Cloud Platform
- The 100% SaaS backend operated by Qualys — hosts the Knowledge Base, Detection Engine, QDS scoring, and VMDR dashboard. Customers deploy only sensors.
- Scanner Appliance
- Physical or virtual probe deployed inside a network segment that performs active credentialed scans and sends findings to the Qualys Cloud Platform.
- Cloud Agent
- Lightweight binary installed on a host (Windows/Linux/macOS) that continuously detects vulnerabilities and reports outbound on 443 — no inbound ports needed.
- Passive Sensor / CAPS
- Listens to network traffic via a SPAN port (or a cloud agent's NIC in CAPS mode) to discover and profile unmanaged assets — no credentials or agents required.
- Container Sensor
- Deployed as a Kubernetes DaemonSet or Docker container; scans all images and running containers on each node for known vulnerabilities.
- Cloud Connector
- API-based integration with AWS, Azure, or GCP that pulls cloud account inventory into the Qualys Platform without deploying any sensor inside the cloud account.
- QKB (Qualys Knowledge Base)
- Qualys-maintained library of vulnerability signatures (QIDs) with CVE mappings, CVSS scores, remediation guidance, and Real-Time Threat Indicators.
- QDS (Qualys Detection Score)
- A Qualys-proprietary 1–100 risk score combining CVSS base, exploit maturity, active-exploitation RTIs, and asset criticality to prioritise remediation.
📚 Sources
- Qualys Documentation — Get Started with VM/VMDR: scanner appliances, cloud agents and sensor architecture. docs.qualys.com/en/vm/latest/welcome_to_vm.htm
- Qualys Support — Cloud Agents or Scanner Appliances: when to use each sensor type. success.qualys.com/support/s/article/000008349
- Qualys Blog — Qualys CAPS: Cloud Agent as Passive Sensor — closing visibility gaps on IoT and unmanaged assets (2023). blog.qualys.com/product-tech/2023/11/26/closing-the-visibility-gap-how-qualys-cloud-agent-passive-sensor-caps-eliminates-blind-spots
- Qualys Documentation — About Network Passive Sensor: SPAN port setup and asset profiling. qualysguard.qg2.apps.qualys.com/ps/help/get_started/get_started.htm
- Qualys Documentation — Cloud Agent as Passive Sensor (CAPS). docs.qualys.com/en/ca/latest/ca_home/caps_home.htm
- Proppa Security — Qualys Architecture: Network Requirements and Communication Flows. proppasecurity.com/blog/qualys-vmdr-architecture
What's next?
Got the platform and sensors? Next, go deep on Qualys VMDR detection logic — how the QID Knowledge Base, CVSS scores, QDS (Qualys Detection Score) and RTIs (Real-Time Threat Indicators) combine to prioritise which vulnerabilities you fix first.