SCADA & OT NIS2 Security Assessment

NIS2 governs the program, not a scanner

Article 21 requires in-scope essential and important entities to take appropriate and proportionate technical, operational, and organizational measures based on an all-hazards approach. Its ten subject areas range from risk analysis and incident handling to continuity, supply chains, secure acquisition and maintenance, effectiveness assessment, training, cryptography, access and asset management, and multi-factor or secure communications. See the Directive text.

Confirm entity scope

Identify the legal entity, Member State nexus, Annex I or II activity, size, exceptions, essential or important status, competent authority, and applicable national transposition. A site's presence in a factory or critical sector is not enough by itself.

Approve the risk program

Management bodies approve and oversee measures and receive training. Owners define risk acceptance, safety and availability constraints, incident thresholds, suppliers, continuity objectives, evidence, and review cadence.

Use scanning as evidence

Inventory observations, exposure paths, firmware matches, detected weaknesses, logging gaps, remote access, segmentation, and remediation validation can evidence selected controls—when coverage and limitations are explicit.

Do not apply the digital-provider rulebook to every plant

Implementing Regulation 2024/2690 directly specifies measures and significant-incident cases for a named set of DNS, TLD, cloud, data centre, CDN, managed-service, marketplace, search, social-platform, and trust-service entities. It is useful context, but not a universal industrial control baseline. The ENISA guidance is also expressly non-binding and targeted primarily to those listed entity types.

Collection mode is a safety decision

NIST's final OT guide warns that active scans directly interact with devices and may cause instability or affect process state. Every collection method needs an owner, scope, window, technical constraints, stop criteria, recovery route, and retained approval.

Passive observation

Consume an approved SPAN/TAP or existing sensor feed. Decode only required protocols, bound retention, harden the collector, and document which network paths and time periods were visible.

Record reconciliation

Import engineering drawings, switch and firewall configuration, CMDB, backups, controller projects, historians, remote-access systems, procurement, support contracts, and end-of-life records.

Authenticated read-only

Use documented management APIs or exports with least-privilege accounts, vendor-approved rates, bounded queries, credential rotation, and proof that no write or control function is invoked.

Controlled active validation

Allowlist known targets and methods only after operations, safety, system owner, and change authority approve the test, maintenance window, monitoring, abort threshold, fallback, and recovery plan.

Do not exploit

No proof-of-concept execution, payload delivery, persistence, destructive testing, or safety-function manipulation in production.

Do not guess

No brute force, broad broadcast discovery, unaudited protocol fuzzing, or generic IT scan profile against unknown OT assets.

Do not write

No firmware, configuration, clock, logic, mode, set-point, restart, or acknowledgement operation from an assessment collector.

Do not overclaim

No complete-inventory claim from passive traffic alone and no vulnerability claim without identity and applicability confidence.

Resolve an asset before matching a vulnerability

OT identifiers are messy: one physical component can appear under an IP address, MAC address, chassis slot, station name, serial number, engineering-project reference, and vendor order code. Keep raw observations immutable, resolve them into a canonical asset with a confidence score, and require review when firmware applicability is uncertain.

Observed identity

Addresses, protocol role, vendor markers, model, serial, hardware revision, firmware, modules, certificates, hostnames, rack or cabinet, evidence source, first and last seen.

Operational identity

Site, line or process, function, critical service, safety relationship, asset owner, maintainer, support vendor, maintenance window, recovery dependency, spare availability.

Lifecycle identity

Commissioning date, approved baseline, backups, vendor support, end of sale, end of support, patch qualification state, exception, replacement plan, last restore test.

Zone and conduit

System under consideration, zone, target security level if established, conduit membership, allowed peers and protocols, north-south and east-west paths, remote and temporary access.

Vulnerability evidence

Vendor advisory, CVE or EUVD reference, affected range, matched attributes, confidence, CVSS and vector, known exploitation, publication and change dates, available fix or mitigation.

Control evidence

Segmentation, access path, authentication, logging, allowlisting, backup, redundancy, physical protection, compensating controls, validation time, evidence owner, expiry and review status.

Use zones and conduits as risk context

IEC 62443-3-2 establishes requirements to define the system under consideration, partition it into zones and conduits, assess each, establish target security levels, and document requirements. The companion Part 3-3 defines system security requirements and capability levels. A scanner can populate and test parts of that model; owners and risk teams still approve its boundaries and targets.

{
  "asset": "plc-packaging-07",
  "site": "ostrava-plant",
  "zone": "packaging-cell-b",
  "identity": {
    "vendor": "Example Controls",
    "model": "XC-400",
    "firmware": "4.12.3",
    "confidence": 0.82,
    "evidence": ["passive:dnp3", "backup:project-2026-08"]
  },
  "conduits": ["cell-b-to-scada", "vendor-maintenance"],
  "safetyCritical": true,
  "owner": "packaging-operations"
}

CVSS is not an OT work queue

Severity is one input. Prioritization also needs match confidence, known exploitation, exposure path, zone, privileges, process and safety consequence, recovery, vendor support, and whether a compensating control actually blocks the scenario.

Decision input	Question	Evidence
Applicability	Is the exact component and configuration affected?	Vendor advisory, model, hardware, firmware, modules, match confidence
Threat	Is exploitation observed or plausible here?	EUVD, CISA KEV, vendor and CSIRT intelligence, exploit preconditions
Exposure	Can a relevant actor reach the vulnerable function?	Zone, conduit, firewall path, remote access, trust relationship, protocol
Consequence	What happens to process, people, environment, quality, or service?	Hazard and process analysis, criticality, dependencies, recovery evidence
Treatment risk	Can the change be applied safely and reversed?	Vendor qualification, test result, outage, backup, spare, rollback and recovery plan
Residual risk	Does the compensating control address the scenario?	Implemented configuration, validation result, owner, exception and expiry

Exploitation data informs—it does not decide

ENISA's EUVD and CISA's KEV catalog add useful public vulnerability and exploitation signals. CISA describes KEV as a prioritization input; its mandatory deadlines apply to US federal civilian agencies under BOD 22-01, not to every EU industrial operator. Preserve source and retrieval time.

A compensating measure needs a test

IEC 62443-2-1:2024 recognizes that legacy systems may lack native capabilities and permits compensating measures within the asset owner's program. Record the requirement, unsupported capability, threat scenario, chosen measure, configuration evidence, validation method, residual risk, approver, and expiry—not merely “segmented” or “risk accepted.”

Map findings to obligations without claiming the whole control

Each scanner output should name the legal or framework requirement it informs, the evidence it actually supplies, and the evidence still missing. This makes the result useful to operations, security, auditors, management, and incident teams without collapsing their responsibilities into one traffic sensor.

Risk analysis

Scanner can support: Asset, topology, exposure, vulnerability and consequence evidence
Still requires: Approved methodology, risk decisions, owners, treatment and management oversight

Incident handling

Scanner can support: Events, anomalous paths, affected assets and retained technical context
Still requires: Significance assessment, national reporting, communications, lessons learned and exercises

Business continuity

Scanner can support: Dependencies, backups, recovery paths, unsupported assets and single points
Still requires: Impact analysis, recovery objectives, tested procedures, crisis roles and alternate operations

Supply-chain security

Scanner can support: Vendors, remote access, components, firmware and support status
Still requires: Supplier assessment, contracts, notification duties, procurement decisions and ongoing review

Secure maintenance

Scanner can support: Configuration drift, advisories, patch and mitigation status, validation result
Still requires: Change approvals, vendor qualification, testing, rollback, exception and end-of-life plan

Effectiveness

Scanner can support: Coverage, rule version, finding closure, segmentation and access observations
Still requires: Control objectives, testing program, metrics, independent review and improvement decisions

Reporting is a separate workflow

NIS2 Article 23 requires in-scope entities to assess significant incidents and use the applicable national reporting route, with staged information including an early warning within 24 hours and incident notification within 72 hours. A technical finding is not automatically a reportable incident. Preserve time of awareness, service impact, evidence, decisions, updates, and authority routing.

Product duties belong to the CRA lane

For manufacturers of PLCs, gateways, HMIs, industrial software, or other products with digital elements, the CRA is a separate product regime. As reviewed, Article 14 reporting is scheduled to apply from 11 September 2026 and the Regulation generally from 11 December 2027. The Commission's reporting page covers the Single Reporting Platform and staged deadlines. Do not merge the operator's NIS2 incident record with the manufacturer's CRA product report without role and scope analysis.

Start with one site and one approved evidence path

A pilot should improve visibility without creating process risk. Bound the site, safety constraints, collection sources, target zones, approval route, output consumers, and remediation workflow before deploying a sensor or sending a packet.

Scope and authority

Entity and site scope, system under consideration, owners, NIS2 and national-law mapping, IEC 62443 use, safety constraints, approvals, and exclusions.

Evidence plan

Passive vantage points, record connectors, read-only credentials, visible and invisible assets, retention, personal data, timestamps, integrity, and coverage measures.

Canonical inventory

Identity resolution, confidence, owner, function, firmware, lifecycle, zone, conduit, allowed paths, remote access, support, backup, and dependencies.

Finding policy

Advisory matching, exploitation sources, reachability, consequence, safety, compensating controls, treatment choices, false-positive review, exception and expiry.

Safe validation

Lab fixtures, approved devices, maintenance windows, allowlists, traffic limits, monitoring, stop thresholds, recovery evidence, and change records.

Operational handoff

Dashboards by owner and site, evidence export, tickets, remediation verification, drift monitoring, incident context, metrics, runbooks, and ownership training.

Connect supplier risk evidence Separate CRA product reporting

SCADA and OT NIS2 assessment FAQ

Can an OT scanner certify NIS2 compliance?

No. NIS2 requires proportionate technical, operational, and organizational risk-management measures, management oversight, incident processes, supply-chain controls, business continuity, training, access controls, effectiveness assessment, and more. A scanner can produce evidence about assets, exposure, vulnerabilities, configurations, and selected controls. It cannot establish legal scope, prove every measure is effective, or replace governance, documentation, exercises, supplier management, or the competent authority's assessment.

Does NIS2 apply to every factory in the EU?

No. Scope depends on the legal entity, activity and sector in Annex I or II, Member State establishment or service rules, the size-cap threshold, specific exceptions and designations, and national transposition. Annex II includes specified manufacturing subsectors such as certain computer, electrical-equipment, machinery, vehicle, and other transport-equipment manufacturing; that is not a blanket rule for every factory. Confirm scope under the applicable national law.

Is active vulnerability scanning safe on PLC and SCADA networks?

Not by default. NIST warns that active scans introduce traffic and directly interact with devices; sensitive OT equipment can become unstable or have its process state affected. Begin with architecture records, passive monitoring, and management-plane evidence. Any active method should be device-aware, manufacturer-supported where possible, allowlisted, tested, approved by operations and safety owners, scheduled for an appropriate window, monitored, and governed by stop and recovery criteria.

Can passive discovery produce a complete OT asset inventory?

No. Passive discovery only sees devices and attributes represented in observed traffic; quiet, disconnected, serial, encrypted, standby, or rarely used assets may remain invisible. Reconcile passive observations with engineering drawings, switch and firewall data, controller or historian inventories, backups, procurement records, remote-access systems, maintenance laptops, physical walks, and owner attestations. Return coverage and identity confidence instead of claiming completeness.

Does a CVE match mean an OT device must be patched immediately?

No. First verify vendor, model, hardware revision, firmware, installed modules, configuration, advisory applicability, and match confidence. Then consider exploitation evidence, reachability, operational consequence, safety, redundancy, maintenance windows, vendor qualification, and compensating controls. A patch may still be the right treatment, but OT change control must prevent the remediation from creating a larger availability or safety risk.

How should IEC 62443 be used in a NIS2 assessment?

Use the relevant parts by role and purpose. IEC 62443-2-1 addresses the asset owner's IACS security program; 3-2 covers system risk assessment, zones, conduits, and target security levels; 3-3 covers system security requirements and capability levels. IEC 62443 can structure evidence and engineering requirements, but it does not itself determine NIS2 scope or prove compliance with national law unless a legal, contractual, or certification context gives it that role.

What is the difference between NIS2 and the Cyber Resilience Act for OT?

NIS2 governs in-scope entities and their cybersecurity risk management and incident reporting under applicable national law. The CRA governs manufacturers and other economic operators for products with digital elements placed on the EU market. An industrial operator may have NIS2 duties while a PLC, gateway, HMI, or industrial-software manufacturer has CRA duties. Article 14 CRA reporting is scheduled to begin on 11 September 2026; the Regulation generally applies from 11 December 2027.

What should an OT security finding contain?

At minimum: site, asset and owner, zone and conduit, evidence sources and timestamps, identity and firmware confidence, advisory and vulnerability references, exploitation evidence, observed and permitted paths, operational and safety consequence, compensating controls, recommended treatment, approval owner, maintenance window, validation evidence, exception expiry, and links to the applicable risk and control requirements. Keep an observation distinct from the analyst's risk decision.

Primary sources and status

Reviewed 4 September 2026. NIS2 is a binding directive whose entity-level duties must be assessed through applicable national transposition. Regulation 2024/2690 is binding for its specifically listed entity types. The CRA is binding subject to its phased application dates. IEC standards may become normative through a chosen certification, contract, procurement, or legal context but are not NIS2 law by themselves. ENISA and NIST publications are guidance. CISA KEV deadlines bind US federal civilian agencies; other organizations can use KEV as risk intelligence. Yarify's collection modes, data model, mappings, and pilot criteria are engineering recommendations—not legal advice, safety approval, certification, or a claim of compliance.