Skip to main content

Compliance hub

NIS2 is already in force. Most OT environments aren't ready for what it asks of the edge layer.

Reference architectures, obligation maps, and audit-ready control patterns for essential-entity operators. Covers NIS2 Article 21, the EU Cyber Resilience Act, and IEC 62443, with practical implementation guidance for distributed OT fleets.

At a glance

10
Article 21 measures. Legally binding for essential and important entities. Five are routinely missed in OT.
24h / 72h
Incident clock. Early warning within 24 hours, full notification within 72 hours of detection.
Sept 2026
CRA obligations start. Vulnerability handling first, full product compliance from September 2027.
Talk to an OT security engineer

TL;DR

  • NIS2 and the EU CRA impose overlapping obligations on industrial operators. The controls that fail audits are rarely in the SCADA. They sit in the edge layer, where devices connect without certificates, vendor sessions run ungoverned, and patch status is anyone's guess.
  • NIS2 Article 21 requires ten specific technical measures. Five are routinely missed in OT deployments.
  • The CRA's essential requirements apply to any product with a digital element, including industrial edge hardware and embedded software, from September 2026.
  • One operator built real-time compliance visibility across 100+ vessels through Helin. That audit-readiness directly supported a major tender.
  • Compliance is a structural property when security is in the runtime, not configured site by site before each audit.

Obligation map

NIS2 Article 21 for OT operators

The ten measures in Article 21 are legal requirements for essential and important entities, not guidelines. The table below maps each to the OT gap that generates the most audit findings.

Art. 21 measureThe OT-specific gap
(a) Risk analysis and security policiesOT assets excluded from the corporate risk register; no documented OT threat model
(b) Incident handlingNo OT-side telemetry ingested into SIEM; incidents invisible until process impact
(c) Business continuity and backupsPLC configurations not version-controlled or backed up off-site
(d) Supply chain securityVendor remote-access sessions unlogged, ungoverned, often via shared VPN credentials
(e) Network security and segmentationFlat OT network; IT/OT boundary documented in policy but not enforced at the network layer
(f) Vulnerability handling and disclosureNo centralized patch cadence for OT; end-of-support dates unknown for the installed base
(g) Cybersecurity trainingTraining covers IT; OT operators excluded
(h) Cryptography and access controlShared HMI credentials; no MFA on remote access to OT systems
(i) Asset managementNo complete OT asset inventory; firmware versions undocumented
(j) Multi-factor authenticationMFA stops at the IT boundary; OT remote access uses plain credentials

NIS2 vs. CRA — what each framework requires, and who it targets

NIS2 DirectiveEU Cyber Resilience Act
Who it targetsOperators of essential and important entitiesManufacturers and importers of products with a digital element
If you are bothBoth apply simultaneouslyBoth apply simultaneously
Key OT obligationTen Article 21 security measures; 24-hour incident notification, 72-hour reportCertificate-based device identity, SBOM, vulnerability disclosure process, documented support period
Enforcement startActive across EU member states; national competent authorities vary by stateCRA vulnerability handling obligations from September 2026; full product compliance from September 2027
Penalty ceiling€10M or 2% global turnover for essential entities; €7M or 1.4% for important entitiesVaries by member state transposition; market withdrawal and recall powers for non-compliant products
IEC 62443 relationshipNIS2 Annex references IEC 62443 as a recognized standard; compliance with it supports NIS2 Article 21CRA Annex I essential requirements align closely with IEC 62443 security levels

Reference architecture

NIS2-compliant OT stack

A compliant OT architecture has four layers. Most audit findings come from Layer 2, the edge layer, because that's where OT meets IT and neither team has historically owned the controls.

Layer 1 — Field / sensor

Assets
PLCs, RTUs, sensors, actuators, ATEX-rated devices in hazardous zones.
Required controls
Asset inventory with firmware versions, physical access controls, no internet-facing interfaces.
Audit artifact
Asset register with firmware version and last-seen timestamp per device.

Layer 2 — Industrial edge

where most audit findings originate

Assets
Edge compute nodes, protocol gateways, OT data brokers, vision AI nodes.
Required controls
Network segmentation enforced at the node, not just at the firewall; zero-trust remote access with per-session logging; certificate-based device identity; governed OTA update delivery with deployment confirmation per node.
Audit artifact
Session logs with full attribution, configuration change history, segmentation diagram with named enforcement points, OTA deployment record showing current version per node.

Helin's platform addresses this layer.

Layer 3 — OT DMZ / plant network

Assets
Historians, SCADA servers, engineering workstations.
Required controls
Unidirectional data flows where possible, IDS/IPS on the IT/OT boundary, documented patch management cadence.
Audit artifact
Data flow diagrams, patch log with dates and outcomes, boundary device configuration.

Layer 4 — Enterprise / cloud

Assets
SIEM, SOC, ERP integrations.
Required controls
OT telemetry ingested and correlated, incident response runbooks with OT-side procedures, NIS2 notification workflow documented.
Audit artifact
SIEM ingestion confirmation, IR runbook with OT section, notification log.

Audit-ready control patterns

Five patterns that cover the Article 21 measures where OT operators most often fail. Each one states what auditors look for, how to implement it, and what artifact to produce.

Pattern 1 — OT asset inventory (Art. 21(1)(i))

What auditors look for: A live register of OT assets with firmware versions, end-of-support status, and last-seen timestamps, updated on every change event. A spreadsheet refreshed quarterly doesn't satisfy a NIS2 auditor.

Implementation

  • Deploy passive asset discovery at the edge layer. Active scanning on OT networks disrupts control loops.
  • Export discovery output to a structured register on every change event, not on a schedule.
  • Cross-reference firmware versions against vendor end-of-support dates at least quarterly.
  • Include the register in your ISMS scope and document the review owner and cadence.

On a fleet of 40 rigs or 500 vessels, keeping separate asset lists per site fails the consistency test auditors apply. You need central visibility across every device at every site from one place, not a collection of local spreadsheets.

Artifact: Asset register with columns — Asset name · IP/MAC · Firmware version · Vendor · End-of-support date · Last seen · Owner · Site.

Pattern 2 — Vendor remote access logging (Art. 21(1)(d))

What auditors look for: Evidence that every vendor remote session was authorized, time-bounded, fully logged, and terminated at session end. A shared VPN with no session record fails. Named-user access with per-session credentials, action-level logging, and automatic session termination passes.

Implementation

  • Route all vendor remote access through a governed access layer. No persistent VPN tunnels, no shared credentials.
  • Issue per-session credentials to named individuals; revoke automatically at session end.
  • Log session start, end, duration, accessor identity, and actions taken to an immutable store.
  • Require a named change ticket for every session; the ticket reference goes in the log.

Attribution is what makes a log auditable. "A vendor accessed the system" tells an auditor nothing. "Vendor name, named technician, session from 09:14 to 09:47 UTC, firmware update to version 4.2.1, change ticket REF-2847" does.

Artifact: Session log extract — Vendor name · Named technician · Session start/end · Duration · Change ticket reference · Actions taken · Node identifier.

Pattern 3 — Network segmentation evidence (Art. 21(1)(e))

What auditors look for: Segmentation enforced at the network layer. They'll ask: "Show me the enforcement point." A policy document isn't one. A firewall ruleset, an edge node configured to block cross-zone traffic, or a unidirectional gateway is.

Implementation

  • Define OT zones by criticality: Safety (SIL-rated assets), Control (process-critical), Operations (SCADA/historian), DMZ (IT/OT boundary).
  • Document permitted data flows between zones in a data flow diagram with named enforcement points.
  • Enforce flows at hardware enforcement points, not only at the corporate firewall.
  • Test segmentation after any topology change and document the test outcome.

Segmentation configured locally at each site varies by site. Centrally managed segmentation, consistent across the full fleet, is what holds in an audit.

Artifact: Data flow diagram with named enforcement points · Firewall or edge node rule extract showing the OT zone ruleset · Last test date and result.

Pattern 4 — Incident detection within NIS2 deadlines (Art. 21(1)(b) + Art. 23)

What auditors look for: That you can detect an OT-side incident and report it within the mandatory windows: 24-hour early warning, 72-hour notification, one-month final report. And that the report is specific: affected systems, operational impact, response actions, cross-border implications.

Implementation

  • Ingest OT telemetry (authentication events, network anomalies, configuration changes) into a SIEM with continuous monitoring. A daily log review doesn't meet a 24-hour detection obligation.
  • Define OT-specific alert thresholds. OT baselines are narrower than IT; borrowing IT thresholds generates false positives and misses real incidents.
  • Document an incident classification process with an explicit decision tree that covers OT events.
  • Assign a named OT incident owner. Include OT response steps in the IR runbook.

An operator managing assets across multiple sites cannot assemble a compliant 72-hour report from siloed historians and manual logs in time. The report has to be specific, and the only way to produce it within the deadline is to have centralized telemetry, with every access event, anomaly, and configuration change logged with full attribution across the full fleet, before an incident occurs.

Artifact: OT alert configuration · IR runbook OT section · Tabletop exercise record with date and findings · Sample 72-hour report structure pre-populated with your fleet topology.

Pattern 5 — CRA SBOM and vulnerability disclosure (CRA Art. 13 + Annex I Part II)

Who this applies to: If you manufacture, import, or substantially modify a connected OT product, including edge compute nodes or embedded controllers, CRA essential requirements apply to you as a manufacturer.

What auditors look for: A current SBOM per product, a continuous CVE review trail, a published disclosure route, and a documented decision for every relevant vulnerability.

Implementation

  • Request SBOMs from all OT hardware and software vendors. A vendor that can't provide one is a supply chain risk that belongs in your supplier assessment.
  • Monitor disclosed CVEs against your SBOM continuously. Periodic scans produce a remediation backlog that grows faster than the team clears it.
  • Publish a vulnerability disclosure contact even if your products are internal-only. CRA's disclosure obligations apply to any product with a digital element placed on the EU market.
  • Document your patch decision for every relevant CVE: patch, mitigate, or accept with written rationale. The decision trail is the compliance artifact, not just the patch.

Governed OTA delivery, where patches are signed, staged to a test group, confirmed, then rolled fleet-wide with a full deployment record, converts a remediation backlog into a documented compliance record.

Artifact: SBOM per product · CVE review log with decisions · Vulnerability disclosure URL · OTA deployment record showing patch coverage per device.

Talk to an OT security engineer

Where Helin's platform fits

A map of where the platform sits relative to the five control patterns above. This isn't a product pitch; it's a reference for operators evaluating whether their current edge layer covers the controls.

Control patternWhat Helin implements in the runtime
OT asset inventoryPassive asset discovery; continuous fleet visibility from one console; firmware version tracking per device across the full fleet
Vendor remote access loggingZero-trust remote access via SSH, HTTPS, or GUI; per-session MFA; full action-level session logging with attribution; no persistent VPN; access revocable per user, session, or node
Network segmentationPurdue-model segmentation enforced at the edge node; centrally managed across all sites; no site-by-site configuration
Incident detectionContinuous security event monitoring across the full fleet; SOC-level threat detection on every edge node; anomalies surface as alerts, not as post-incident findings; OT-specific alert thresholds
OTA update governanceSigned OTA delivery; staged rollout to a test group before fleet-wide deployment; confirmation per node; version drift visible immediately
NIS2 compliance reportingAutomated compliance reporting from the same platform layer managing operations; audit trail produced without a pre-audit preparation exercise
CRA device identityCertificate-based identity using X.509, TPM 2.0, and TLS in the runtime; auto-renewed; a device without a valid platform-issued certificate can't connect; identity managed centrally, not per site
CRA SBOM and code signingEvery application deployed to the fleet is signed at source and runs in a sandboxed container; unsigned code doesn't execute; static analysis at build time before code reaches the fleet

Security is in the runtime, not configured before an audit.

Frequently asked questions

NIS2 applies to operators of essential and important entities across 18 sectors, including energy, maritime transport, water, and digital infrastructure. If your organization operates OT assets in any of these sectors within the EU, you're almost certainly in scope. The test isn't whether you use OT. It's whether your sector and size meet the essential or important entity thresholds set by your national competent authority.

NIS2 targets the operator of a network or service: it sets obligations for how you run your OT environment. The CRA targets the manufacturer or importer of a product with a digital element: it sets obligations for what you put on the EU market. If you buy OT equipment from others and operate it, NIS2 is your primary obligation. If you also build or integrate connected OT products (edge nodes, embedded controllers, connected sensors), both apply simultaneously.

The CRA entered into force in December 2024. Vulnerability handling and disclosure obligations under Article 14 apply from September 2026. Most product categories must demonstrate full compliance by September 2027, with products in the "important" and "critical" categories subject to Notified Body assessment requirements. [Source: Regulation (EU) 2024/2847]

Auditors focus on evidence. They want to see a current OT asset register, session logs for vendor remote access with full attribution, network segmentation diagrams with named enforcement points, alert configurations covering OT-specific events, and an incident response runbook with an OT section. Policies that exist only as documents, with no corresponding technical controls behind them, don't pass.

The edge layer is where devices connect without certificates, where vendor access happens outside governed platforms, where firmware version drift accumulates invisibly, and where OT telemetry stops before it reaches the SIEM. SCADA is usually the most-audited part of the OT estate. The layer between the sensor and the control room is typically the least governed.

Helin's edge platform implements the Layer 2 controls that generate the most OT audit findings: certificate-based device identity at provisioning, governed remote access with per-session logging and attribution, centrally managed network segmentation, continuous security event monitoring across the fleet, governed OTA update delivery with node-level confirmation, and automated compliance reporting. NIS2 and EU CRA audit-readiness is a structural property of the platform, not a pre-audit configuration exercise. Boskalis built real-time compliance visibility across 100+ vessels on Helin's platform. That compliance posture directly supported a major tender.

IEC 62443 is the international series of standards for OT and industrial automation security. NIS2's Annex references it as a recognized standard, so implementing IEC 62443 security levels supports compliance with NIS2 Article 21 measures. The CRA's Annex I essential requirements align closely with IEC 62443 security levels for products. For operators working toward NIS2 and CRA compliance simultaneously, IEC 62443 provides the technical framework that covers both.

For essential entities: up to €10M or 2% of global annual turnover, whichever is higher. For important entities: up to €7M or 1.4% of global turnover. Beyond fines, national competent authorities can impose operational restrictions, require remediation plans, and in some member states hold senior management personally liable. [Source: NIS2 Directive Art. 34]

Bring the edge layer into scope before the audit does.

Talk to an OT security engineer

Sources

  • Directive (EU) 2022/2555 (NIS2 Directive), Art. 21, Art. 23, Art. 34
  • Regulation (EU) 2024/2847 (EU Cyber Resilience Act), Art. 13, Art. 14, Annex I
  • IEC 62443 series — Security for industrial automation and control systems
  • ENISA, NIS2 Implementation Guidance for Operators of Essential Services, 2023

Edge intelligence, once a month.

Field notes from industrial operations running control at the asset: deployment patterns, compliance changes, and what we learn on site. No product marketing.

One email a month. Unsubscribe at any time.

Last updated: . Information is subject to change.