A Vulnerability Scan Isn't a Full OT Security Assessment

A scan can identify exposed systems and known weaknesses within its scope. By itself, it usually can't show how access reaches operational technology, whether IT and control networks are separated, what normal traffic looks like, or whether the utility can investigate an incident.

External exposure
Internal access paths
Network behavior
Investigation readiness

Start with what the scan actually covered.

Security scanning and discovery services vary widely. They may include external scanning, internal or authenticated scanning, passive asset discovery, or a broader analyst-led assessment.

The label doesn't define the result. The scope, scan position, access, test method, and OT safety limits do.

01

Where did it run?

From the public internet, inside IT, inside OT, or from more than one location?

02

What was in scope?

Which plants, remote sites, systems, vendor links, and network segments were included?

03

What access did it have?

Could it authenticate and inspect systems, or only see what responded from its position?

04

What could it safely test?

OT systems may limit active checks because availability and process safety come first.

What the scan may show and what still needs another method.

A useful finding can still lack the architecture, behavior, and operating context needed to judge risk.

Security question What a scan may show What another method adds
External exposure Systems, services, and known weaknesses visible from the scan position. Asset role, ownership, operational importance, and whether the exposure is required.
Known vulnerabilities Detectable conditions that match known vulnerability checks. Reachability, compensating controls, asset criticality, and operational consequence.
Remote access and segmentation An exposed service or selected control, when included in scope. Vendor access, VPNs, jump hosts, cellular links, firewall rules, and permitted routes into OT.
Internal network activity A result from the systems visible during the scan window. Passive monitoring can show communication and changes on the segments where traffic is collected.
Suspicious activity Conditions that may be exploitable; not an investigation of ongoing behavior. Evidence correlation, affected systems, timing, confidence, and recommended next steps.
Incident readiness A findings report and remediation guidance within the scan scope. Who investigates, what evidence exists, how escalation works, and who can authorize action.
Remediation validation A rescan may confirm whether the original detectable condition remains. Authorized retesting can determine whether the original condition or approved IT path remains.

Coverage varies by provider, scanner, credentials, access, statement of work, and OT operating constraints.

The perimeter and the internal network answer different questions.

An external scan looks at what's visible from its position. An internal assessment can map connections, boundaries, and permitted access. Monitoring can show observed activity on network segments where telemetry is available.

External view

  • Which services and interfaces are reachable?
  • Which known weaknesses are detectable?
  • Which systems appear exposed or misconfigured?

Internal view

  • Which systems can communicate with SCADA or OT support systems?
  • Where do vendor, remote site, and cellular connections lead?
  • Has communication changed from expected behavior?
Example water system access path
Access
Remote or external access
Edge
Firewall, VPN, or gateway
Boundary
IT/OT separation point
Control
SCADA, HMI, or engineering system
Field
PLC, RTU, or remote site

Illustrative only. Actual architecture and trust relationships vary by utility.

A severity score isn't the same as operational risk.

The utility still needs to know whether the affected system is reachable, which controls stand in the way, and what a failure or compromise could affect.

01

Find the condition

Identify the exposed service, known vulnerability, weak setting, or control concern.

02

Add environment context

Review reachability, segmentation, asset role, compensating controls, and operational consequence.

03

Decide and verify

Prioritize the fix, document any uncertainty, and retest the approved condition or IT path.

Active testing in OT requires careful planning and approval. CrunchAtlas observes OT passively and limits active validation to authorized IT systems and paths.

Use each layer for what it does best.

A vulnerability scan alone doesn't cover exposure, architecture, behavior, investigation, and validation. Answering those questions requires different methods and evidence sources.

01

Vulnerability scan

Find exposed systems and detectable weaknesses within the approved scope.

02

Internal assessment

Map assets, remote access, boundaries, trust relationships, and control ownership.

03

Monitoring and investigation

Observe approved data sources, identify meaningful changes, and build the evidence record.

04

Remediation and retesting

Fix the issue and verify that the original condition or authorized IT path no longer remains.

Seven questions to ask before calling the environment covered.

These questions help operators, utility leaders, IT teams, integrators, and service providers define who owns what.

Where did the scan run from, and which systems and sites were in scope?
Was it authenticated, and what could it safely inspect?
Are remote access, vendor connections, cellular links, and IT/OT boundaries documented?
Can the team review internal communication on the network segments that matter?
Who investigates suspicious activity, and what evidence would they have?
Are findings prioritized by reachability, controls, asset importance, and operational consequence?
After remediation, is the original issue retested or only marked complete?

An unanswered question isn't proof of a threat. It's a coverage gap that should have an owner.

CrunchAtlas adds context around the scan.

CrunchAtlas works from the approved scope, available telemetry, existing controls, and the questions the utility needs answered.

01

Review the environment

Review architecture, remote access, IT/OT boundaries, existing controls, available telemetry, and investigation readiness.

02

Observe approved data

Analyze copied network traffic, existing security tool output, packet captures, or uploaded evidence without sending commands to OT equipment.

03

Investigate activity

Correlate related evidence, explain why it matters, state confidence and uncertainty, and recommend next steps.

04

Validate authorized IT exposures

Test authorized IT systems and approved paths, then retest approved fixes without actively probing OT controllers or field equipment.

CrunchAtlas can work alongside a state program, scanner, MSP, SCADA integrator, firewall, SIEM, or internal security team. Visibility still depends on sensor placement, available logs, encrypted traffic, active systems, and the approved scope. Missing evidence is reported as a limit. It isn't treated as proof.

Vulnerability scans and OT assessments.

Is a vulnerability scan the same as an OT security assessment?

No. A scan checks for detectable systems, exposures, vulnerabilities, and configuration conditions within its scope. An OT assessment may also review architecture, remote access, segmentation, internal communication, operating constraints, incident readiness, and remediation priorities.

Does an external scan show internal OT network activity?

No. An external scan alone can't observe routine communication between internal systems. Internal telemetry or testing would be additional scope.

Do we still need an assessment if the PLC isn't directly exposed to the internet?

Possibly. The remaining question is whether remote access, IT systems, engineering workstations, cellular connections, or vendor paths can still reach the control environment.

How does passive monitoring avoid interacting with field equipment?

Passive monitoring analyzes copied traffic or approved evidence and doesn't send control commands to OT devices. TAP, SPAN, sensor, and collection changes still require operator and integrator review.

Can CrunchAtlas work with our existing providers?

Yes. CrunchAtlas can work alongside the utility's MSP, SCADA integrator, state program, scanner, and internal team while helping define who owns monitoring, investigation, reporting, remediation, and retesting.

Know what the current scan covers. Map what it doesn't.

Talk with our team about what your current scan covers, which questions remain unanswered, and how CrunchAtlas can work alongside your existing providers.

Talk to Our Team