Most engineers think…
Most people picture Tenable as 'a Nessus box on the network that scans everything'. That mental model will fail you in an interview and when you try to scan cloud workloads, remote laptops, OT devices, or web apps.
Tenable Vulnerability Management is a cloud-native SaaS platform: the console, scheduling, the vulnerability database (VDB), and dashboards all live in Tenable's cloud — you never install or patch them. What you deploy on-prem are sensors — linked Nessus scanners, lightweight agents, the passive NNM, and a web-app scanner. Each sensor type answers a different question about a different part of your estate. Getting that split right is what sets a security engineer apart.
① What Tenable VM actually is — cloud brain, sensor fleet
The single most important idea: Tenable Vulnerability Management is a cloud-native SaaS platform, not a box you rack. Tenable operates the cloud infrastructure — the console, the policy engine, the vulnerability database, and the dashboards. Your job is to deploy sensors that reach your assets and push findings back to that cloud.
The result is one view of your entire attack surface — on-prem servers, cloud VMs, laptops, OT gear, and web apps — in a single dashboard, without managing a central scanning server. Policy, scheduling, and reporting are all in the cloud; only the scanning intelligence is distributed to the sensors closest to each asset class.
Tenable Vulnerability Management is best described as…
② The cloud platform — console, VDB, and dashboards
The Tenable VM cloud platform has four logical layers you must be able to name. The console is the browser-based UI (previously called Tenable.io) where you create scan policies, schedule jobs, manage users, and view results. The scheduling and orchestration engine dispatches scan jobs to the correct sensors and collects the returning results. The Vulnerability Database (VDB) is Tenable's continuously updated library of plugin checks — over 200,000 checks covering CVEs, misconfigurations, and compliance benchmarks. The dashboard and reporting layer aggregates findings, applies VPR scoring, and surfaces the remediation queue.
Why cloud-native matters for architecture questions
Because the platform is cloud-hosted, no inbound firewall rules are required: sensors initiate outbound HTTPS connections to Tenable's cloud (cloud.tenable.com). This also means Tenable pushes plugin updates to every sensor automatically — you never manually patch the VDB.
The cloud-hosted SaaS UI — policies, scheduling, user management, scan history and dashboards. No on-prem install; Tenable runs and patches it.
An active scanner deployed in your network or cloud VPC. Probes target IPs remotely, then pushes encrypted results to the Tenable cloud over outbound HTTPS.
Lightweight software inside the OS. Runs plugins locally, then uploads compressed results when online — works on laptops, transient hosts, and assets behind strict firewalls.
A passive sensor on a SPAN or tap — reads traffic without active probes. The only sensor safe for fragile OT/ICS devices and the best way to discover unknown assets.
In an interview, separate the cloud layers: console (policy and RBAC), scheduling engine (dispatch and collection), VDB (plugin library and CVE enrichment), and the dashboard/reporting layer (VPR ranking and remediation queue). You manage none of them — Tenable does — which is the whole SaaS value proposition.
What does the Tenable VDB (Vulnerability Database) provide?
③ The sensor fleet — four types, four use cases
Tenable VM supports four distinct sensor types. A linked Nessus scanner is a standard active scanner you deploy on-prem (Linux/Windows) or in a cloud VPC. It probes assets remotely over the network — TCP/UDP port scans, banner grabbing, credentialed OS checks — and pushes results to the Tenable cloud. Best for traditional data-centre subnets with predictable IP ranges.
A Tenable agent is lightweight software installed directly on the endpoint (server, laptop, container). It runs locally inside the OS, compiles its own plugin results, then uploads compressed findings to the cloud when a scan window opens. Agents work on assets that are offline, behind strict firewalls, or transient — a remote developer's laptop that never lives on the corporate LAN is a classic agent use case.
The Nessus Network Monitor (NNM) is a passive sensor placed at a network tap or SPAN port. It reads traffic flows without sending any active probes — which makes it the only sensor safe to use on fragile OT devices. NNM also discovers assets that have never been actively scanned, simply by seeing their traffic. The web-app scanner is a specialised active scanner that crawls HTTP/S applications, tests input fields for injection flaws, and checks for OWASP Top 10 vulnerabilities that a standard Nessus plugin would miss.
A linked Nessus scanner only covers assets reachable on the network at scan time. It cannot see offline laptops (use agents), fragile OT devices (use NNM passively), or web-app injection flaws (use the web-app scanner). Full coverage requires the right sensor mix for each asset class.
▶ Watch a Tenable agent scan reach the cloud dashboard
How a remote laptop vulnerability is found and prioritised end-to-end. Press Play for the healthy path, then Break it to see the classic failure.
A fragile OT programmable logic controller on an isolated SCADA segment must be included in vulnerability visibility. Which sensor is safest to use?
④ Data flow — from scan trigger to remediation
The end-to-end flow starts when the scheduling engine fires a scan job. For a linked scanner, the cloud sends the job parameters; the scanner runs the plugins against the target subnet and posts compressed, encrypted results to the Tenable cloud over HTTPS. For an agent, the cloud posts a task notification; the agent runs the plugins locally and uploads results in the same way. For NNM, traffic observations are streamed continuously. For the web-app scanner, the cloud triggers a crawl job.
Once results arrive in the cloud, the VDB enriches each finding with CVE metadata, CVSS base score, and the VPR (Vulnerability Priority Rating) that blends severity with real-world exploitability and asset criticality. Findings appear in the Vulnerabilities dashboard ranked by VPR, ready for the remediation workflow — assign, track, verify fix with a re-scan.
The key interview line
Sensors always push out to the cloud; the cloud never reaches in. This means you can deploy agents and linked scanners behind NAT with no inbound rules, and Tenable's infrastructure still collects every result. That outbound-only pattern is the architectural reason organisations trust Tenable in high-security environments.
Priya at a Mumbai financial services firm faces this
Tenable VM dashboards show hundreds of servers and cloud VMs but none of the 3,000 remote-work laptops that left the office network after the pandemic. The CISO wants full coverage.
All scans use linked Nessus scanners on the LAN. Laptops that are off-network are never reached — the scanner cannot see them through home broadband NAT.
In Tenable VM console ▸ Settings ▸ Sensors — no agents are registered. All coverage is scanner-only. Any asset that is not on the corporate LAN when a scan runs is invisible.
Tenable VM Console ▸ Settings ▸ Sensors ▸ Agents ▸ Agent GroupsDeploy the Tenable agent via MDM (e.g. Intune/Jamf) to all 3,000 laptops. Assign them to an Agent Group, set a scan window, and attach the scan policy. Agents compile results locally and push to the Tenable cloud over HTTPS from anywhere — home broadband, coffee shop, or VPN.
After the first agent scan cycle completes, open the Assets dashboard — all 3,000 laptops should appear with findings. Confirm agent connectivity in Settings ▸ Sensors ▸ Agents: all should show Last Scan within the expected window.
Before closing a coverage gap ticket, check Settings ▸ Sensors in the Tenable VM console. Confirm each sensor's last-check-in time, plugin version, and associated scan policy. A scanner that hasn't checked in recently is silently missing assets — not 'clean'.
How do Tenable sensors communicate with the Tenable cloud platform?
🤖 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: why is Tenable VM called a 'cloud-native' platform rather than a 'scanner'? 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
- Tenable VM (Tenable.io)
- The cloud-native SaaS Vulnerability Management platform — console, VDB, scheduling engine, and dashboards hosted by Tenable.
- Linked Nessus scanner
- An active scanner deployed in your network or cloud VPC that probes assets remotely and pushes results to the Tenable cloud over outbound HTTPS.
- Tenable agent
- Lightweight software installed inside the OS on an endpoint; runs plugins locally and uploads compressed results when online — works offline and behind NAT.
- Nessus Network Monitor (NNM)
- A passive sensor on a SPAN port or tap that reads network traffic without active probes — safe for fragile OT/ICS devices and useful for asset discovery.
- VDB (Vulnerability Database)
- Tenable's cloud-hosted library of 200,000+ plugin checks covering CVEs, misconfigurations, and compliance benchmarks; updated automatically across all sensors.
- VPR (Vulnerability Priority Rating)
- Tenable's proprietary dynamic score that combines CVSS severity with real-world threat intelligence (exploitability, asset criticality) to rank what to fix first.
- Web-app scanner
- A specialised Tenable sensor that crawls HTTP/S applications and tests for OWASP Top 10 vulnerabilities that a standard Nessus scan cannot detect.
- Outbound-only architecture
- The Tenable model where sensors initiate HTTPS connections to cloud.tenable.com — no inbound firewall ports required, works behind NAT.
📚 Sources
- Tenable — Tenable Vulnerability Management product page and documentation. docs.tenable.com/vulnerability-management
- Tenable Docs — Sensors overview: linked scanners, agents, Nessus Network Monitor, web-app scanner. docs.tenable.com/vulnerability-management/Content/Settings/Sensors/Sensors.htm
- Tenable Docs — Tenable agents: offline scanning and transient asset coverage. docs.tenable.com/vulnerability-management/Content/Settings/Sensors/Agents.htm
- NuHarbor Security — Quickstart: Tenable Vulnerability Management Architecture. nuharborsecurity.com/blog/quick-start-tenable-io-architecture
- Tenable — Nessus Network Monitor data sheet: passive OT and traffic-based discovery. tenable.com/data-sheets/nessus-network-monitor
- Tenable — VPR: Vulnerability Priority Rating methodology. tenable.com/products/vulnerability-management
What's next?
Got the architecture? Next, go deep on scan policies, credentialed vs uncredentialed scans, and how Tenable uses the CVSS + VPR scoring model to prioritise the vulnerabilities that actually matter.