Most enterprise vulnerability management programs do not run a single scanner. They run two or three, often without ever planning to. A Tenable.io subscription arrives with a cloud migration. A legacy Tenable.sc deployment stays alive because nobody wants to migrate the credentialed scan policies. Qualys VMDR comes in through a compliance mandate. Rapid7 InsightVM lands when a new business unit gets acquired with its own tooling. None of these decisions are wrong on their own. Together they produce a familiar pattern that practitioners call scanner sprawl.
Scanner sprawl is not just a licensing line item. It is three consoles with three login flows, three severity scales, three exports, and three different ways of naming the same host. The cost shows up when someone in leadership asks a simple question. How many critical vulnerabilities do we have right now across the estate. With three disconnected scanners, answering that question honestly takes a spreadsheet, a half day, and a disclaimer about double counting.
This article is about consolidation that goes deeper than a shared dashboard. It covers what it actually takes to treat Tenable, Qualys and Rapid7 as equal inputs to one correlated console, how PMAP normalizes their severity into a single model, how it removes duplicate findings where coverage overlaps, and how scheduling and live status keep every scanner current without anyone logging into a vendor portal. For the broader connector layer that sits underneath all of this, see the security integration layer pillar. For the orchestration process that turns scans into a managed pipeline, see multi-vendor scan orchestration.
The Cost of Three Vulnerability Scanners and Three Consoles
The first cost is reconciliation. Each scanner has its own asset model. Tenable identifies a host by a Tenable UUID and a set of network interfaces. Qualys tracks assets by its own host ID and QID-based detections. Rapid7 InsightVM organizes work around sites and assets within those sites. When the same server is scanned by all three, you have three records that describe one machine. Counting them as three is wrong. Knowing they are the same requires a correlation step that no single vendor console can perform across its competitors.
The second cost is severity drift. A finding rated High by one scanner may be rated Critical by another for the same underlying CVE, because each vendor blends CVSS with its own threat intelligence and scoring weights. A program that triages off raw vendor severity ends up triaging off whichever scanner happened to surface the issue, which is not a defensible prioritization model. The FIRST CVSS specification gives the industry a shared base score, but each vendor layers its own interpretation on top, so the labels you see in three consoles are not directly comparable.
The third cost is operational drag. Someone has to remember which scanner covers which subnet, which credentials are stored where, and which export feeds which report. When a scan fails silently in one console, nobody notices until the monthly metrics look thin. NIST SP 800-40 Rev. 4 frames enterprise patch and vulnerability management as a continuous program rather than a periodic scan, and a continuous program cannot run on three disconnected execution surfaces that each require manual attention.
PMAP treats this as an orchestration problem first. The scan domain is the core orchestration layer, and a scan in PMAP is a single execution context regardless of whether it was launched manually, fired by a schedule, or adopted from a remote scanner. Tenable, Qualys and Rapid7 all feed that one execution context. The console you read is not a federation of three vendor views stitched together at display time. It is one model that all three scanners write into.
What Consolidation Means Beyond a Shared Dashboard
A shared dashboard puts three scanner widgets on one page. Consolidation puts three scanners behind one record model. The difference matters because a dashboard still leaves you with three sources of truth, while a consolidated model gives you one.
In PMAP, every external system is managed through the integration domain, which the product describes as a universal connector hub. A single integration record stores the credentials and configuration for one scanner. The service layer dispatches vendor-specific logic through a registry of connector archetypes, so the core never carries a hardcoded branch for each vendor. Tenable, Qualys and Rapid7 are all registered as scanner connectors, meaning they share the same archetype contract for remote scan operations and results fetch. This is the structural reason they can be treated as equals. They implement the same interface, even though their underlying APIs are completely different.
Consolidation in this sense has four practical properties. Findings from all three scanners land in one normalized model. Duplicate findings are removed where scanners overlap. Severity is governed centrally rather than inherited from whichever vendor reported it. Scan status stays current for every scanner without anyone opening a vendor console. The rest of this article walks through each property in the order a real consolidation project tends to encounter them.
The Three VM Scanners PMAP Treats as Equals
Within PMAP’s vendor catalog, the VM and Scanner category includes Nessus, Tenable.io, Tenable.sc, Qualys VMDR, Rapid7 InsightVM, and Nuclei. The five that matter for this article are the three commercial families that dominate enterprise VM. Each is its own connector sub-package with its own client, importer, enricher, and mapper. The mapper is the important part, because it is where each vendor’s raw output becomes a normalized finding.
Tenable as One Connector Family: Nessus, Tenable.sc and Tenable.io
Tenable is not one product. Most enterprises that run Tenable run more than one variant, and PMAP reflects that with three separate connectors. Nessus covers standalone Nessus scanners. Tenable.sc covers the on-premise Tenable.sc deployment with its repositories and sub-scanner topology. Tenable.io covers the cloud platform, implemented as a thin connector that reuses the Nessus scanner API surface. From PMAP’s side, all three present as scanner connectors with the same remote scan operations, so an operator who has launched a Nessus scan already knows how to launch a Tenable.sc scan.
The Tenable.sc connector carries extra wizard pickers that matter for large deployments. PMAP can list scan folders, list the repositories that Tenable.sc organizes scan data into, and list sub-scanners so a scan can be pinned to a specific child appliance. The scan domain models this directly with sub_scanner_id and sub_scanner_name, which lets you target one Nessus node under a Tenable.sc cluster rather than letting the deployment choose. If you are wiring up Tenable for the first time, the practitioner guide on importing a Tenable Nessus scan end to end walks through the full flow.
Qualys VMDR and Rapid7 InsightVM Side by Side
Qualys VMDR and Rapid7 InsightVM are the other two pillars of enterprise VM, and PMAP supports each as a first-class scanner connector. The vendor APIs could hardly be more different. Qualys works through its detection model, its host assets, and a knowledge base of QIDs. Rapid7 InsightVM organizes scans around sites, with assets living inside those sites. PMAP absorbs both differences in the wizard layer rather than forcing them onto the operator.
For Qualys, the connector exposes the pickers an operator needs to build a real scan: scan templates and policies, asset tags for targeted scanning, and the credential profiles Qualys uses for authenticated checks. For Rapid7, PMAP can list sites and fetch site detail, which is the natural unit of work in InsightVM, alongside scan templates and credentials. The guides for importing Qualys VM with live sync and importing Rapid7 InsightVM and sites cover the vendor-specific setup for each.
One useful detail for evaluation work is that PMAP ships a demo connector for Qualys and Rapid7. When an integration is flagged for demo mode, every connector resolution short-circuits to a demo connector with canned data. That means a team can preview the Qualys and Rapid7 experience in PMAP before handing over production API credentials, which is exactly what most consolidation evaluations want early on.
One Normalized Finding Set Instead of Three Severity Scales
This is the property that makes consolidation worth doing. PMAP never uses vendor severity directly. Each connector produces a normalized finding through its own mapper, and the mapper is where the vendor’s native severity gets translated into PMAP’s model. The product is explicit about this. The normalized severity is produced by the connector, it flows through a threshold filter, and the rule engine may override it further after import. Raw vendor severity is never persisted as the authoritative value.
The practical effect is that a Critical from Tenable, a Critical from Qualys, and a Critical from Rapid7 all mean the same thing in your console, because they all passed through the same normalization model rather than three independent vendor scales. When leadership asks how many criticals exist across the estate, the number is defensible because it was computed against one severity model, not concatenated from three.
The threshold filter is the second half of this. Each integration carries an import severity threshold in its configuration. Findings below the configured minimum are discarded at import time rather than persisted and then hidden. A team that only cares about High and Critical across all three scanners sets one threshold per integration and stops importing the noise floor at the source. This is a meaningfully different posture from importing everything and filtering in the view, because the data that never enters the system never has to be stored, correlated, or explained.
After normalization and thresholding, the optional rule engine can override severity based on your own logic. A finding on an internet-facing asset, or one that matches an entry in the CISA Known Exploited Vulnerabilities catalog, is a candidate for an upward override regardless of what the scanner said. The point is that the prioritization logic lives in PMAP and applies uniformly to all three scanners, instead of being baked into each vendor’s scoring engine where you cannot reach it.
Deduplication Where Scanners Overlap
Overlap is inevitable in a multi-scanner program. If Tenable and Qualys both scan the DMZ, they will both report the same exposures on the same hosts. Without deduplication, consolidation makes the numbers worse, not better, because now you are counting the same issue two or three times.
PMAP’s import pipelines are idempotent by design. The product states that all import pipelines, whether scanner, file, or asset-sync, produce no duplicates when the same vendor scan is re-imported. Findings are matched by fingerprint. Assets are matched by IP, hostname, or external ID. This is the mechanism that lets the same machine reported by Tenable, Qualys and Rapid7 resolve to one asset, and the same underlying vulnerability resolve to one finding rather than three.
Idempotency also protects you operationally. Re-running an import after an interruption hits the same external IDs and upserts rather than duplicating, because connector dispatch is resumable. The raw vendor payloads are archived in object storage, so a replay never loses the original data even after normalization. For a consolidation project, this means you can backfill historical scans aggressively without fear of inflating your counts, which matters during onboarding when you are pulling in months of scan history from three vendors at once.
The correlation layer is where imported findings ultimately land. Findings from every scanner flow through the same correlation pipeline after import, which is what turns three vendor feeds into one deduplicated finding inventory. This is the difference between a console that shows you three scanners and a console that shows you one estate.
Importable Scans and Orphan Adoption Across Vendors
Consolidation is not only about new scans. Most teams already have years of scan history sitting in Tenable, Qualys and Rapid7, and a real consolidation has to bring that history in without manual export gymnastics.
PMAP handles this with two complementary mechanisms. The first is the importable-scan picker. For any scanner integration, PMAP annotates every vendor-side scan with its PMAP adoption status, so an operator can see at a glance which scans are already adopted and which are not, then selectively import or reassign them. This is a deliberate browse-and-choose flow for the cases where you want control over what gets pulled in and where it lands.
The second mechanism is orphan adoption, and it is what makes the Scans page a faithful mirror of the vendor rather than a manual import queue. When a scanner integration is created, PMAP fires an immediate asynchronous sweep that matches existing vendor scans to PMAP and adopts them without waiting. After that, a five-minute ticker queries each active integration for its full vendor scan list and automatically creates PMAP rows for any scan that exists on the vendor but not yet in PMAP. Already-completed adopted scans immediately trigger asset import, findings import, and enrichment in the background. The result is that scans launched directly in the Tenable, Qualys or Rapid7 console still show up in PMAP, with findings, without anyone importing them by hand.
There is a guard rail on this. When a scan is deleted in PMAP, its integration and external scan ID pair is written to a blocklist so orphan adoption never re-adopts it. That prevents the frustrating loop where a scan you intentionally removed keeps reappearing on the next sweep.
Live Status Sync So Every Scanner Stays Current
A consolidated console is only useful if it is current. A scan that is still running in Qualys should show as running in PMAP, with progress, not as a stale completed record from last week.
PMAP runs a live status sync on a thirty-second ticker. It polls every integration-backed scan that is running, queued, paused, or importing, and writes fresh status, progress, host count, findings count, and per-severity counts. Vendor status strings are translated to PMAP’s canonical set through a status map, so a Nessus scan reporting empty becomes queued, a vendor error becomes failed, and a vendor cancelled becomes cancelled. The same translation applies to all three vendors, which is why the status column in the consolidated Scans view reads consistently regardless of which scanner produced the row.
When a scan transitions to completed, the sync loop does not stop at updating a status label. It auto-triggers asset import, findings import, and enrichment in the background. That is the moment a finished Qualys or Rapid7 scan becomes findings in your console, without a separate manual import step. The per-severity counters that feed your dashboards are refreshed from the actual findings in the database after each import, so the critical and high counts you read are authoritative post-import values rather than vendor estimates carried over from the scan summary.
Scheduling Imports From All Three Vendors
Many enterprises schedule scans inside the vendor console already. Consolidation does not require you to abandon those vendor schedules, but it does give you a PMAP-side schedule that ties the import side together.
Each integration carries a cron schedule. A background scheduler ticks every minute, evaluates whether any integration’s cron is due, and fires the appropriate import pipeline, writing a schedule log entry that records status, findings imported, and duration. You set the cron once per integration, enable it, and PMAP auto-imports completed scans on that cadence. The schedule log and a run-now control are exposed so an operator can verify the last run and force an immediate pass without waiting for the next tick.
For a three-scanner program, this means one place to reason about import timing across vendors. You can stagger Tenable, Qualys and Rapid7 imports so they do not all land at once, you can see in a single log whether last night’s imports succeeded for all three, and you can trigger a manual catch-up for any one scanner that fell behind. The operational how-to for setting up this cadence lives in the scan scheduling and live sync cluster article, and the broader import mechanics are covered in multi-vendor scan import.
A Consolidation Checklist for Multi-Scanner Teams
Consolidating Tenable, Qualys and Rapid7 into one console is a project, not a toggle. The following checklist reflects the order in which the mechanics above tend to come into play.
Inventory your scanners honestly. Most teams find more scanner instances than they expected, especially across Tenable variants. Account for Nessus, Tenable.sc and Tenable.io separately, because PMAP treats them as separate connectors and each may hold different scan policies.
Decide your severity threshold per scanner before you import. Setting the import severity threshold up front keeps the noise floor out of the system entirely rather than importing everything and filtering later. This is easier to reason about per integration than globally, because different scanners cover different asset classes.
Plan for overlap. Where two scanners cover the same subnet, expect deduplication to compress the raw count significantly. The fingerprint and asset matching are what make the consolidated number smaller than the sum of the three feeds, which is the whole point.
Backfill history with confidence. Because imports are idempotent and raw payloads are archived, you can pull in months of historical scans across all three vendors during onboarding without inflating counts or losing source data.
Let orphan adoption do the steady-state work. Once the integrations exist, scans launched directly in any vendor console will appear in PMAP on the five-minute sweep, so the consolidated console stays in sync with the vendor without ongoing manual imports.
Move severity logic into the rule engine. Once findings are normalized, encode your own prioritization, such as upgrading anything that matches the CISA KEV catalog or sits on an internet-facing asset, in one place that applies to all three scanners.
How PMAP Unifies VM Scanners Into One Console
The throughline is a single execution context fed by a single connector model. Tenable, Qualys and Rapid7 register as scanner connectors that share one archetype, so the orchestration layer treats them as equals despite three incompatible APIs. Their output passes through per-connector mappers into one normalized finding model, with vendor severity discarded in favor of PMAP’s governed severity and an optional rule-engine override. Idempotent imports and fingerprint-based deduplication collapse overlapping coverage into one finding inventory through the correlation pipeline. Orphan adoption and live status sync keep the console current without anyone logging into a vendor portal, and a PMAP-side cron schedule ties import timing together across all three vendors.
That is what consolidation means in practice. Not three widgets on a page, but one record model, one severity scale, one deduplicated inventory, and one place to answer the question of how many criticals exist across the estate right now. For the connector layer that makes this possible across every category, not just VM, start with the security integration layer pillar. For the consolidation playbook framed as a program rollout, see scanner sprawl consolidation.
See PMAP in action. Review the multi-vendor scan orchestration datasheet and consolidate Tenable, Qualys and Rapid7 into one correlated console.
Frequently Asked Questions
Does PMAP replace Tenable, Qualys or Rapid7?
No. PMAP orchestrates them. The scanners keep doing the scanning, and PMAP becomes the single console that launches scans, imports findings, normalizes severity, removes duplicates, and tracks status across all three. You keep your scanner investments and remove the cost of running three disconnected consoles.
How does PMAP make severity comparable across three scanners?
Each connector produces a normalized severity through its own mapper, and PMAP never persists raw vendor severity as authoritative. Normalized severity passes through a per-integration threshold filter and an optional rule engine that can override it. The result is that a Critical from any of the three scanners is measured against one model rather than three independent vendor scales.
Will consolidating three scanners double or triple my finding counts?
No, the opposite. Import pipelines are idempotent and findings are matched by fingerprint while assets are matched by IP, hostname, or external ID. Where Tenable, Qualys and Rapid7 overlap on the same hosts, the same vulnerability resolves to one finding through the correlation pipeline, so the consolidated count is smaller than the sum of the three raw feeds.
Can I bring in years of historical scans from each vendor?
Yes. The importable-scan picker lets you selectively adopt vendor scans, and orphan adoption sweeps the full vendor scan list automatically. Because imports are idempotent and raw payloads are archived in object storage, you can backfill aggressively during onboarding without inflating counts or losing source data.
Do scans launched directly in the vendor console show up in PMAP?
Yes. A five-minute orphan adoption ticker queries each active integration for its full vendor scan list and creates PMAP rows for any scan that exists on the vendor but not yet in PMAP. Already-completed scans trigger findings import and enrichment automatically, so the console mirrors the vendor without manual imports.
How current is the status of a running scan?
A thirty-second live status sync polls every running, queued, paused, or importing integration-backed scan and writes fresh status, progress, host count, and per-severity counts. Vendor status strings are translated to a canonical PMAP set, so the status column reads consistently across Tenable, Qualys and Rapid7.
Does PMAP support all of Tenable's products?
PMAP ships separate connectors for Nessus, Tenable.sc, and Tenable.io. Tenable.sc adds wizard pickers for scan folders, repositories, and sub-scanners so you can pin a scan to a specific child appliance. Tenable.io is a thin connector that reuses the Nessus scanner API surface. All three present as scanner connectors with the same remote scan operations.
