Most engineers think…
Most people assume Tenable VM is 'just Nessus running authenticated scans'. That works fine on a flat, always-on server estate — and almost nowhere else.
Modern environments have laptops that leave the office, cloud workloads that spin up and down, IoT and OT devices that reject active scans, and segmented networks with firewall rules that block scanner traffic. Tenable's answer is a three-sensor model: Nessus Agents for hosts that drift or sit behind firewalls, Nessus Network Monitor (NNM) for passive discovery of what you cannot or should not touch with an active scan, and Nessus Scanners for authenticated deep scanning of reachable targets. Linking all three to a central console (Tenable.io or Security Center) is what gives you the unified, deduplicated asset inventory that makes VM work at scale.
① Three sensor types — Agent, Scanner and NNM
Tenable Vulnerability Management is built around three complementary sensor types, each filling a gap the others cannot. A Nessus Agent lives on the host, scans locally and uploads results. A Nessus Scanner sits on the network and fires authenticated plugin checks at remote targets it can reach. Nessus Network Monitor (NNM) never sends a probe — it watches a mirror of your traffic and infers asset existence and vulnerability from observed protocols.
The key interview insight: no single sensor type gives full coverage. Agents catch the transient laptop and the cloud workload. NNM catches the unmanageable printer and the OT controller. The scanner catches the stable server with rich plugin output. All three report back to Tenable.io (cloud) or Tenable Security Center (on-prem) to form a deduplicated asset inventory.
Which Tenable sensor type never sends a probe packet to any host?
② Nessus Agents — when, why, groups & linking
Deploy a Nessus Agent when any of these apply: the host leaves the corporate network (a salesperson's laptop), the host sits in a cloud VPC behind a security group that blocks inbound scan traffic, the host is in a network segment with no scanner and punching firewall rules is impractical, or you need offline scan results for a system that is rarely online during scheduled windows. The agent checks in on a schedule, runs the full plugin set locally against the host itself, and uploads a compressed result package — no inbound TCP to the host required.
Agent groups and scan strategy
Agent groups let you apply different scan policies to different asset classes — for example, 'Windows Workstations', 'Linux Cloud Instances', 'CI/CD Runners'. An agent registers by downloading an install package, running the nessuscli agent link command with a linking key, and completing the linking workflow. After linking, the agent checks in at regular intervals (configurable, typically every few minutes), receives its scan schedule, runs locally, and posts results to the manager.
A lightweight daemon on the target host. Scans locally, uploads results. No inbound network access needed. Ideal for laptops, cloud, and segmented hosts.
An active scanner that fires authenticated plugin checks at reachable targets. Needs credentials and network access. Delivers the deepest plugin coverage per host.
Receives a SPAN/TAP copy of traffic. Discovers assets and vulnerabilities from protocol banners and flow patterns — no probe packets ever sent.
A token used during agent registration (nessuscli agent link) to pair the agent with a manager or group. Determines which scan policy the agent receives.
Agent groups do more than organise assets — they determine which scan policy (plugin set, schedule, scan window) an agent receives. Create groups by asset class (Windows Workstation, Linux Server, CI/CD Runner) so plugin sets stay relevant and you avoid running Windows-only checks on Linux hosts.
A salesperson's laptop leaves the office network for two weeks. Which sensor ensures vulnerability data is still collected?
③ Nessus Network Monitor (NNM) — passive discovery
NNM is Tenable's passive sensor. It receives a copy of network traffic via a SPAN port or network TAP, inspects the protocols flowing through it (HTTP, TLS banners, SMB, FTP, SIP, modbus, and many more), and uses that traffic fingerprint to detect asset existence, software versions, and known-vulnerable protocol behaviours — without sending a single probe packet to any host.
What NNM finds that active scans miss: transient devices that are online only briefly, IoT and OT controllers that crash or misbehave under active scanning, rogue assets talking on the wire that are not in any CMDB, and cleartext credential use or deprecated protocols (Telnet, SNMPv1) detected in traffic. NNM findings are vulnerability data too — they appear in the Tenable console alongside active-scan results and contribute to the asset inventory. NNM does not replace agents or scanners; it adds the dimension of what is actually on the wire.
NNM's passive approach is safe for fragile OT/ICS devices, but passive-only coverage means you only know about vulnerabilities that manifest in observable traffic. Silent, unpatched hosts that are not actively communicating may never be fingerprinted. Supplement NNM with agents on any OT host that has a supported OS and can run the agent safely.
▶ Watch a Nessus Agent scan and upload results
Step through the agent lifecycle end-to-end: link, check-in, local scan, upload. Press Break it to see what happens when the linking key is wrong.
NNM detects Telnet sessions on the wire. What is this an example of?
④ Scanner placement, linking & full-coverage strategy
In a segmented network, a Nessus Scanner can only reach hosts in segments it has a routed and firewall-permitted path to. The standard placement model: one scanner (or a clustered pair for HA) per network zone, each scanner linked to Tenable.io via an outbound HTTPS connection — no inbound firewall holes required. Scanners with no direct path to Tenable.io can chain through a linked scanner relay.
Full-coverage recipe
Combine all three sensors: Agents on every managed endpoint (laptop, cloud VM, container host where the OS is accessible), one NNM sensor per SPAN-capable switch segment for passive discovery, and authenticated Nessus Scanners in each zone for deep server-class checks. Set agent groups by asset class so plugin sets stay relevant and scan windows do not collide with production change freezes. Review the asset inventory weekly for NNM-only hosts (no agent, no scanner result) — those are your blind spots to address next sprint.
Priya at a Mumbai fintech firm faces this
Tenable.io shows a large cloud VPC with hundreds of EC2 instances all marked 'never scanned'. The scheduled Nessus Scanner sits on the on-prem network and cannot reach the VPC because the security group allows only outbound traffic from the instances.
The Nessus Scanner is placed on-prem with no routed, permitted path into the cloud VPC, so active scans never reach the EC2 hosts.
Check Tenable.io ▸ Assets — filter by 'last scan source = none'. Confirm scanner logs show connection refused or timeout for the VPC IP range. The security group only permits outbound, not inbound from scanner IP.
Tenable.io ▸ Settings ▸ Sensors ▸ Agents & Scanners + AWS EC2 Security GroupDeploy Nessus Agents on the EC2 instances via a user-data bootstrap or AWS Systems Manager. Assign the agents to a 'Cloud-Linux' agent group with an appropriate plugin policy. Agents check in outbound to Tenable.io — no inbound security group rule needed.
After next check-in cycle, the EC2 instances appear in Tenable.io with agent scan results and a 'last scan = today' timestamp. The 'never scanned' filter returns zero results for that VPC.
After deploying sensors, filter Tenable.io Assets by 'scan source'. Hosts with only an NNM entry need an agent or scanner. Hosts with no entry at all are completely invisible — check your CMDB against the inventory and add sensors to every segment that shows a gap.
Your audit shows hundreds of NNM-only assets — hosts with no agent and no scanner result. What is the right next step?
🤖 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 does a three-sensor model (agent + scanner + NNM) give better coverage than any one sensor alone? 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
- Nessus Agent
- A lightweight daemon installed on the target host that runs Nessus vulnerability checks locally and uploads results to the manager — requires no inbound network access.
- Nessus Network Monitor (NNM)
- A passive sensor that receives a mirror copy of network traffic (via SPAN or TAP) and fingerprints assets and vulnerabilities from observed protocol behaviour, without sending any probe.
- Agent group
- A logical collection of Nessus Agents sharing a scan policy, plugin set and schedule. Created per asset class (Windows, Linux, cloud) to ensure relevant checks and controlled scan windows.
- Linking key
- A token used during 'nessuscli agent link' to register an agent with a Tenable manager and assign it to an agent group. Must be current and match the target manager.
- SPAN port / TAP
- A Switched Port Analyzer port or hardware TAP that mirrors network traffic to a monitoring sensor like NNM, giving it a read-only copy of all packets on a segment.
- Scanner placement
- The decision of where to deploy Nessus Scanners in a segmented network so they have routed, firewall-permitted access to the target hosts they need to scan.
- Passive discovery
- The NNM technique of inferring asset existence and vulnerability from observed network traffic, without actively probing targets.
- Coverage gap
- An asset that appears in the Tenable inventory with NNM-only data (or no data at all) — meaning no agent or authenticated scanner has ever scanned it.
📚 Sources
- Tenable — Nessus Agent deployment and linking guide. docs.tenable.com/nessus/Content/NessusAgents.htm
- Tenable — Nessus Network Monitor (NNM) overview and deployment. docs.tenable.com/nnm
- Tenable — Tenable.io sensor types: scanners, agents and NNM. docs.tenable.com/tenableio/Content/Sensors.htm
- Tenable — Agent groups: creating, managing and assigning scan policies. docs.tenable.com/tenableio/Content/AgentGroups.htm
- Tenable — Scanner placement and linked scanner relay architecture. docs.tenable.com/tenableio/Content/ScannerDeployment.htm
- Tenable — Tenable Security Center sensor management and coverage best practices. docs.tenable.com/security-center
What's next?
Got the sensor landscape? Next, go deep on Tenable plugin families, CVSS scoring, and how Tenable prioritises vulnerabilities using VPR and Asset Criticality Ratings so your remediation team tackles the right risks first.