Scanning Production Systems Without Breaking Them

Most estates have a set of systems nobody scans, protected by a memory of something going wrong years ago. That exclusion list tends to contain the systems that matter most, which means your vulnerability data describes the parts of the business you could afford to lose. NIST’s technical guide to security testing, SP 800-115, is clear that assessment methods should be chosen to match the sensitivity of the target rather than avoided altogether.

What actually causes problems

A modern server handles a vulnerability scan without noticing. The trouble comes from a narrow group: embedded devices with small network stacks, older printers that respond to unusual traffic by printing pages of nonsense, industrial controllers that were never designed for unexpected packets, and legacy appliances with connection limits that a scanner exhausts. Load balancers and intrusion prevention systems can also react by blocking the scanner, which produces incomplete data rather than an outage. Knowing which of your systems fall into these categories is most of the work.

Tuning before you scan

Start conservative and open up as you learn. Use the scanner’s safe check settings, which exclude tests known to be disruptive, and keep denial of service checks disabled unless you are deliberately testing resilience in a maintenance window. Reduce parallel connections per host for fragile targets. Prefer authenticated scanning where you can, since reading the patch state from inside is gentler than probing services from outside. For the most sensitive hosts, an installed agent removes network probing from the equation entirely.

“When a client tells me a scan took a system down, we usually find the scan was the trigger rather than the cause. The service had a fault that would have surfaced the next time anything unusual happened, and better to discover it on a Tuesday afternoon with everyone watching than during an incident. That said, tell operations before you scan. Surprise is what damages the relationship.”

William Fieldhouse, Director, Aardwolf Security Ltd

Agreeing the approach with operations

Bring the people who run the systems into the plan rather than informing them afterwards. Agree a window, share the source addresses so nothing looks like an attack, and arrange a contact who can stop a scan mid-run. Start with a small pilot against a representative host, watch the monitoring while it runs, and expand once the result is boring. Keep a record of what was scanned and when, because the first question after any unrelated outage will be whether security was doing something at the time. This process turns scanning from something imposed on operations into something they can predict, which is what makes the schedule stick.

Handling what genuinely cannot be scanned

Some devices really should be left alone, and those need an alternative rather than an exemption. Use vendor advisories and a documented version inventory to track their exposure, review the network controls around them, and record the position as an accepted risk with an owner and a review date. Production vulnerability scanning covers everything else properly, and where you are unsure how far to push against fragile systems, speak to a tester about scopingbefore the first scan rather than after an incident report.

Frequently asked questions about scanning production

These questions come up whenever a scanning programme meets an operations team.

Should scans run outside business hours?

For fragile systems, yes. For a modern estate it makes little difference and out-of-hours scanning can be worse, since a problem at three in the morning is discovered by whoever is unlucky rather than by the team watching.

Is agent-based scanning always safer?

It removes network probing and adds software to the host, which is its own change. For laptops and cloud workloads it is usually the better option; for appliances you cannot install on, network scanning tuned carefully remains the answer.