Switching Vulnerability Scanners Without Losing Coverage

Switching vulnerability scanners fails when a team treats the project as an installation. The hard part is preserving coverage, decisions, and proof while the source of findings changes underneath the program.

A new scanner will not use the same asset identifiers, check names, severity choices, credential states, or evidence format. Counts will move. Some differences will be improvements. Others will be blind spots. The migration team has to explain which is which before it turns off the old source.

Run both systems against a fixed representative scope. Keep two ledgers. One tracks technical coverage. The other tracks operational continuity. Cut over in slices, verify fresh results, and keep a tested rollback path until the new service survives normal failure.

How should you plan switching vulnerability scanners?

Write the migration contract before deploying anything. Name the asset classes, networks, applications, cloud accounts, remote endpoints, scan methods, credentials, business owners, report consumers, integrations, exceptions, history, and evidence that must survive. Put a measurable acceptance rule beside each one.

Separate replacement from improvement. First prove the new service can perform the old service's required jobs. Then add better priority, automation, or reporting. Teams that mix both goals cannot tell whether a changed result came from a stronger scanner, a new policy, missing access, or a broken migration.

Give one person authority to stop the cutover. That owner needs direct evidence from scanner administrators, network teams, endpoint teams, service owners, and remediation operators. A project plan can be green while an isolated network has not received a successful authenticated scan in three weeks.

Why does scanner continuity matter more in 2026?

CISA's live Known Exploited Vulnerabilities feed reported catalog version 2026.09.10 on September 10, 2026. It contained 1,705 vulnerabilities, marked 359 as used in known ransomware campaigns, and had added 292 entries since September 11, 2025. A migration that pauses current assessment can miss a moving set of exploited flaws.

On June 10, 2026, CISA issued BOD 26-04. Its phases give federal agencies 60 days to update processes and 180 days to begin the new remediation work. It requires continuous tagging of publicly exposed assets and seven day machine readable reporting for agencies without fully automated CDM reporting. Scanner identity and reporting continuity are now control evidence, not migration housekeeping.

A current government rollout shows the right shape. CMS published its CrowdStrike and Tenable One migration plan on March 11, 2026. It separated planning in January and February, repository and vulnerability data migration from February through September, managed scanning migration from April through August, and data center adoption from August through December. Data, scanning, and adoption move on different clocks.

What should you capture before the new scanner arrives?

Freeze a thirty to ninety day baseline. Export the asset inventory, stable identifiers, addresses, names, owners, tags, last successful assessment, credential status, scanner assignment, schedule, exclusions, open findings, closed findings, accepted risk, false positive decisions, ticket links, and repair evidence. Record export time and hash.

Build denominators by asset class and collection method. If the old system knows 4,000 servers, 7,500 employee devices, 600 network devices, and 240 public services, keep those as separate populations. A new dashboard showing 98 percent coverage can hide the complete loss of one small but important class.

Inventory the scanner service too. Document appliances, agents, relay nodes, firewall rules, service accounts, certificates, proxy rules, rate limits, maintenance windows, plugin channels, update settings, and alert routes. Migration estimates often count licenses and ignore the operating system around them.

How do you create a fair scanner truth set?

Select assets that represent awkward reality: a public server, a segmented network, a remote laptop, a domain controller, a network appliance, a cloud workload, a backported Linux package, a system with failed credentials, a host that changes addresses, and a rebuilt machine that reuses a name.

Seed approved conditions where safe. Include known vulnerable software, a fixed version, a configuration error, a service that is installed but stopped, an unreachable target, and a finding under an approved exception. Record the expected observation and why. Neither scanner gets to define truth from its own output.

Compare evidence, not only CVE counts. One product may report a package based on version. Another may run a configuration check. A third may infer exposure from an external probe. Preserve the method, observation time, credential state, and raw result. Ten extra findings are not better if nobody can reproduce them.

How should the parallel run work?

Run at least one complete normal cycle and one change cycle. During the normal cycle, compare discovery, authenticated success, check coverage, feed freshness, performance, and report delivery. During the change cycle, patch a known condition, break one credential, stop one agent, rename a host, and add a new KEV to the test set.

Classify every material disagreement as old source correct, new source correct, both defensible, both wrong, or unresolved. Add an owner and deadline. Do not average the counts. If the old scanner reports 1,200 findings and the new one reports 900, a twenty five percent drop proves only that the outputs differ.

Measure analyst effort. Suppose four analysts spend five hours a week for six weeks reconciling results. That is 120 skilled hours. At $85 per loaded hour, the comparison costs $10,200. That expense is useful when it exposes a blind spot before cutover. It is waste when the project does not retain the disagreement ledger.

How do you compare findings with different identifiers?

Create a neutral comparison record. Useful fields include internal asset ID, source asset ID, address, platform, software or service identity, CVE, check family, observation method, observed condition, credential state, first seen, last seen, scanner source, and source finding ID.

Do not force every scanner result into a CVE. Configuration findings, unsupported software, weak credentials, and exposed services may not have one. Match at the most specific shared level and retain the original record. The normalization layer should explain uncertainty instead of hiding it.

Stable internal asset identity matters more than either product's ID. Use an owned identifier that survives address changes and product replacement. When no strong match exists, create a review state. A silent merge can attach the wrong exception or closure history to a different machine.

How can you find CVEs the new scanner missed?

Export one CVE per line from the old and new scanner for the same asset set and time window. These commands sort both files, remove duplicates, and print CVEs present only in the old result:

The syntax follows the GNU Coreutils comm documentation. The command is only a triage aid. Review asset scope, observation method, product matching, and fix state before calling an old only result a miss.

What history must survive the scanner change?

Preserve decisions separately from detections. Owners, due dates, exceptions, compensating controls, comments, repair tasks, approvals, and closure proof belong to the vulnerability program. A new scanner can update the observed state without erasing why the organization accepted or repaired it.

Map open records before cutover. Each old finding should become a linked new finding, remain open with an unsupported coverage warning, or close through an approved evidence review. Never bulk close old findings because the new product did not recreate them.

Test ticket behavior with the vulnerability management RFP controls. Create, update, reject, reassign, repair, verify, and reopen a finding. Compare the result with the complete vulnerability management control loop. A connector logo does not prove continuity.

When is it safe to cut over?

Cut one asset group, site, or scan type at a time. Require current coverage, acceptable disagreement, successful integrations, trained operators, documented recovery, and a complete export. Keep old collection running for a defined overlap unless it creates unsafe load.

Set rollback triggers in advance. Examples include more than 3 percent unexplained asset loss, authenticated success below the agreed floor, a missed critical service, broken ticket delivery, stale threat data, or inability to reproduce a closed finding. Your thresholds may differ. Write them before schedule pressure appears.

Retire access carefully. Remove old service accounts, firewall rules, agents, appliances, API tokens, certificates, and vendor support users. Keep the immutable export, mapping ledger, decision record, contract terms, and destruction confirmation. The scanner alternatives guide covers coverage contracts for teams replacing Nessus or a similar engine.

Which metrics belong on the migration review?

Put denominators first. Report current assets assessed divided by approved assets for every class. Beside that, show authenticated success, last successful observation, feed age, unexplained identity differences, and checks that exist in only one system. A single fleet percentage hides where the risk moved.

Add continuity measures: open findings mapped, decisions retained, exceptions reviewed, tickets reconciled, repairs verified, records reopened correctly, and exports tested. Track unresolved differences by age and owner. A disagreement without an owner is an unplanned acceptance decision.

Service health belongs on the same page. Show failed scans, credential errors, connector delay, duplicate delivery, operator hours, support cases, and time to restore a broken source. Compare each measure with the old baseline and the acceptance floor. Improvement in one asset group does not excuse failure in another.

Hold a weekly decision review with the migration owner, scanner administrators, remediation lead, and representatives for affected asset classes. Close only explained differences. Change the cutover date when evidence fails. A schedule slip is cheaper than discovering after retirement that a regulated segment never made it into the new service.

Frequently asked questions about switching vulnerability scanners

How long should two vulnerability scanners run in parallel?

Run long enough to complete normal assessment, repair, feed update, and failure cycles for every material asset class. Four to eight weeks often exposes common gaps, but segmented or infrequently connected estates may need longer.

Should finding counts match exactly?

No. Products use different checks, research, matching, and severity choices. Require every material difference to be explainable. Match coverage and evidence against a buyer owned truth set rather than forcing equal totals.

Can you migrate false positive and exception decisions?

Usually not as a blind import. Map each decision to stable asset and condition identity, preserve its reason and approval, then reassess it against the new scanner's evidence. Unsupported mappings should remain open for review.

What is the biggest cutover risk?

Silent loss of coverage is the biggest risk because a cleaner dashboard looks like progress. Keep explicit denominators, credential health, last successful observations, and an old to new mapping until fresh results pass.

The executive takeaway

Freeze the old truth, run both scanners on the same difficult assets, explain every material disagreement, and preserve program decisions outside product identifiers. Cut over in slices with written rollback triggers. Retire the old service only after coverage and continuity both pass. A migration is complete when the team can prove what it still sees, not when the new dashboard is online.