Skip to content

Utilities

A distribution estate is hundreds of small OT sites that must all be answered for.

Substations are unstaffed, nearly identical, and connected to a control centre over links somebody else owns. The assurance question is rarely about one site: it is whether the same statement can be made about all of them, and whether the answer still holds when the next one is added.

Available
An electrical utility environment: substation switchgear and control infrastructure.
  • Substation, control centre and enterprise as canonical zones, not as a drawing
  • The protection and control boundary modelled as conduits with their own channels
  • IEC 62443-3-2 risk and 3-3 requirements against a confirmed target per zone
  • NIS2 readiness on the same estate, not a second exercise
The OTReady estate inventory for an energy distribution demo project, listing substation zones and subzones across the estate.
Real OTReady product screenshot using demo data. A regional distribution estate, listed as canonical Sites, Zones and Subzones rather than drawn.

Understand the environment

The estate is the problem, not the site.

A single substation is not hard to describe: a station bus, a set of protection and control IEDs, a gateway to the regional control centre, and a small number of links that leave the fence. What makes distribution difficult is that there are a hundred of them, they were commissioned across three decades, and no two are quite the same despite being described in the same standard drawing.

So the questions that matter are estate questions. Which stations still carry an unauthenticated telecontrol protocol. Which ones have a vendor path that nobody has reviewed since commissioning. Which are inside the scope of the assessment that was signed off last quarter, and which were added after it. Those are answerable only if every station is the same kind of object in the same model.

Availability is the operating constraint behind all of it. A substation cannot be taken out of service to be assessed, a protection relay cannot be scanned, and a maintenance window is measured in hours per year. Assurance work in this environment is largely documentary and architectural, which is precisely what this product is for.

  • Brownfield is the normal case, not the exception
  • The same zone pattern repeated across many sites, with real local variation
  • Remote sites with no operator present during an incident
  • Third-party links: telecoms carriers, protection vendors, metering providers

Terminology

What OTReady calls things here.

The objects are the product's own. The names in them are the operator's, because a model that renames a customer's estate is a model they have to translate before they can use it.

Site
A substation, a control centre, a regional depot. Physical grouping only: a Site confers no security scope and inherits nothing.
Zone and Subzone
Station bus, protection and control, telecontrol gateway, station services. A Subzone is a zone inside a zone, with its own target and its own conclusions.
Conduit
The security relationship between two zones. The telecontrol path from station to control centre is one conduit, whatever it physically runs over.
Communication Channel
What that conduit actually carries: IEC 60870-5-104 telecontrol, IEC 61850 station bus traffic, an engineering session, syslog. Protocol, direction and encryption state live here, per channel.
OT Domain
Functional context in the operator's words: protection, telecontrol, metering, station services. Assigned across zones, conduits, channels and assets at once.

Conduit and channel

One telecontrol link, several different behaviours.

A distribution operator will describe the link between a substation and the control centre as one thing. Inside it there are usually several: the telecontrol protocol itself, a file transfer somebody set up for fault records, a vendor session for protection settings, and a log feed.

OTReady keeps the relationship and the traffic apart. The Conduit is the relationship and carries the target; each Channel carries its own protocol, direction and encryption state. Collapsing them would hide exactly the one channel that matters, and encryption is three-valued: encrypted, not encrypted, and not recorded, which is never read as safe.

An OTReady conduit detail view for an energy distribution demo project, listing the communication channels the conduit carries.
Real OTReady product screenshot using demo data.

How OTReady applies

The same chain, on a distribution estate.

Nothing about the product changes for a sector. What changes is what the objects are called and what the answers turn out to be.

  1. OT context
  2. Architecture
  3. Risk
  4. Targets
  5. Assessments
  6. Findings & Evidence
  7. Remediation
  8. Reports

Each step points back at the part of the estate it is about: a Finding names the substation zone or the conduit it concerns, and stays pointed at it through remediation and into the issued report.

Assurance

One reading of the estate, with the reason beside it.

Nine dimensions, each stated as a word with its reason, and no overall score. A distribution estate mid-programme does not have a single number, and a page that printed one would be inventing the part the reader most wants.

The OTReady assurance cockpit for an energy distribution demo project, showing each dimension with its band and the reason for it.
Real OTReady product screenshot using demo data. UNKNOWN appears where the state genuinely could not be established, never as a quiet pass.
The OTReady governed findings list for an energy distribution demo project, each finding attributed to the architecture object it concerns.
Real OTReady product screenshot using demo data.

Findings

Every finding names the part of the network it is about.

A finding that says "weak remote access" for a hundred substations is a sentence, not a work item. Here each one is attributed to a canonical object: this zone, this conduit, this channel. That is what lets a regional programme be planned by site and still be reported as one position.

Findings are governed: a treatment decision is recorded, verified closure requires linked and approved work, and none of it is asserted.

Representative use cases

What operators actually bring to it.

A regional distribution estate
Many substations, one control centre, one repeated zone pattern with real local variation. The question is consistency across sites, not depth at one.
The protection and control boundary
Where station bus traffic meets telecontrol, and where an engineering session crosses a boundary that was drawn before anyone asked about it.
Control centre and enterprise separation
The conduits between operations and corporate, and what each of them genuinely carries once the channels are written down.
NIS2 as an essential entity
Readiness assessed on the same estate the IEC 62443 work used, so the two are answers about one plant rather than two exercises.

What this page does and does not claim.

OTReady is one platform configured for this environment, with an accepted demo estate behind the screenshots above. It is not a utilities edition, not a substation template, and not a certification. It does not read from your SCADA, your protection relays or your telecontrol network, and it changes nothing on the plant.

Where the detail lives

  • OT architecture

    Sites, Zones, Subzones, Conduits and the Channels inside them.

  • Risk and targets

    IEC 62443-3-2 risk, and confirmed Target Security Levels per zone.

  • Assurance

    The nine dimensions, and why there is no score.

See OTReady against your own distribution estate.

A working session on your substations, your control centre and the conduits between them.