OT Security, Zero Trust & Compliance for Energy Operators

← Energy & Critical Infrastructure
Compliance & Zero Trust

The compliance deadline has passed. The attacker did not wait.

NIS2 is in force. IEC 62443 defines the technical baseline. The EU Cyber Resilience Act is reshaping what security products must deliver. And AI is accelerating attacker capability faster than most OT security teams can track.

For utilities, grid operators, renewable producers and district heating networks, this convergence poses one urgent question: are your OT and IoT assets protected at the device level, or only at the network perimeter?

This page is written for security leads, OT engineers and compliance officers past the awareness stage. It covers how XoT Technology™ maps to the frameworks you are accountable for, and the threat vectors perimeter controls cannot reach.

The threat

AI-accelerated attacks make attack surface reduction non-negotiable

01

Reconnaissance now takes minutes

Automated tools identify exposed OT devices, fingerprint firmware and cross-reference CVEs at machine speed. An RTU once obscure through irrelevance is trivially discoverable.

02

The patch window has closed

Time from CVE publication to active exploitation attempts in OT is measured in days — often before operators have assessed applicability, let alone scheduled a maintenance window.

03

Contractor credentials are the target

Already the most common initial access vector in energy breaches, now pursued through AI-assisted social engineering aimed at the engineers who hold legitimate OT access.

04

The answer is not to out-run it

Remove what the attacker is looking for. A device that does not answer scans cannot be fingerprinted; one that cannot be fingerprinted cannot be matched to a CVE. Invisible beats fast.

Zero trust

Zero trust for OT is not zero trust for IT

IT zero trust assumes things OT cannot do

Identity providers, conditional access and micro-zoning all assume devices can run agents, reach cloud identity infrastructure and be patched on a cycle.

OT breaks every one of those assumptions

A 15-year-old S7 PLC runs no agent. A substation RTU cannot authenticate to a cloud directory. A turbine controller cannot go offline for firmware during peak season.

XoT enforces identity outside the device

The Lock applies PKI certificate identity at the network layer. The PLC, RTU or HMI is never modified and never participates in authentication.

Scope is the asset, not the segment

A technician cleared for one turbine controller cannot reach anything else — not because a firewall rule forbids it, but because everything else is invisible to them.

Verification is continuous

Mutual challenge-response runs inside the tunnel throughout the session. Revoke a key mid-session and access ends immediately.

Network position grants nothing

Being on the OT network gives no access. Being a domain administrator gives no access. Only a valid, policy-matched Key reaches a protected asset.

IEC 62443

How XoT maps to the standard

For energy operators subject to NIS2, IEC 62443 is the recognised technical framework for demonstrating compliance with Article 21 security measures.

62443-3-2

Zones and conduits at device granularity

Each protected asset forms its own logical security zone, with the Lock acting as conduit controller for every communication attempt in or out — not just at network segment level.

SL-T / SL-C

Security Levels

PKI identity, WireGuard encryption and default-deny combine to support Security Level 2 and contribute to Security Level 3 for critical zones — covering intentional violation by simple means and by more sophisticated means with moderate resources.

SR 2.1 / 2.6

Least privilege and session integrity

Access is scoped to a specific asset, identity and time, with nothing broader possible by design. Sessions are logged, time-bounded and immediately terminable through policy revocation, with metadata exportable to SIEM.

62443-2-4

Supply chain security

Time-limited, device-specific access for third-party technicians gives operators verifiable evidence of what each external party accessed, when and for how long.

NIS2 Article 21

Measure by measure

Risk analysis · 21.2a

Asset-level access logging documents who accessed which OT assets, when and from where — feeding risk analysis and posture assessment directly.

Incident handling · 21.2b

Full session logs including failed authentication attempts, in formats compatible with SIEM platforms and NIS2 reporting timelines.

Business continuity · 21.2c

Deployment requires no operational downtime and no changes to existing infrastructure, supporting recovery time objectives for critical assets.

Supply chain security · 21.2d

Every third-party technician, OEM engineer and external integration receives device-specific, time-limited access. Boundaries are enforced technically, not only contractually.

Access control and authentication · 21.2i

PKI certificate identity for every user and device. No shared credentials, no password authentication, strong authentication by design without additional MFA infrastructure.

Encryption · 21.2j

Every session is encrypted with WireGuard, a modern independently audited protocol, end to end between Key and Lock.

EU CRA & NIST

How the product itself is built

Cyber Resilience Act

XoT hardware and software is developed under a Secure Development Lifecycle: threat modelling at design phase, static and dynamic analysis in the CI/CD pipeline, automated dependency management and SBOM generation, and vulnerability response meeting CRA timelines — documented for customer audit.

Supply chain provenance

Hardware designed and manufactured in Sweden with no geopolitical dependencies on US or Chinese component ecosystems. Under Article 21.2d, verifying the provenance of security hardware is a legitimate procurement consideration.

NIST CSF 2.0 and SP 800-207

Contributes to Protect (PR.AA, PR.AC, PR.DS) and Detect (DE.CM), and addresses all seven zero trust tenets — for the legacy PLCs, RTUs and embedded controllers that cannot participate in conventional zero trust infrastructure.

Evaluation

Questions worth asking any OT security vendor

These questions reveal how much of a vendor proposition is architecture diagram and how much is operational reality. We welcome all of them.

On zero trust

Is identity enforced at device level or network segment level? Can it protect a device that cannot run an agent, receive patches or reach cloud infrastructure?

On legacy OT

Does deployment require any modification to the protected device? What is the operational impact during installation? Can it go in without a maintenance window?

On compliance documentation

Can the vendor provide IEC 62443 zone and conduit mapping? Is NIS2 Article 21 mapping available for your audit team? Is an SBOM available for the security product itself?

On AI threat resilience

Does the solution reduce attack surface, or depend on detecting and responding to AI-accelerated threats in real time? What happens when automated scanning hits your OT network?

On supply chain

Where is the product designed and manufactured? What geopolitical dependencies exist in the hardware supply chain? Is the disclosure policy documented and public?

On vendor security maturity

Threat modelling, automated security testing, component-level SBOM, pre-release penetration testing, coordinated disclosure with defined timelines — all auditable, not positioning statements.

Ready for a technical conversation?

Whether you are evaluating XoT for energy infrastructure or building a compliance case for NIS2, IEC 62443 or the EU CRA, we are ready for the detailed discussion.

Request a technical demo