Apply IEC 62443 concepts to substations: OT risk, zones, conduits, asset inventory, remote access, hardening, monitoring, testing and cybersecurity acceptance.

Check it out!

Substation digitalization has expanded protection, control, supervision, remote-assistance, and diagnostic capabilities, but it has also increased the number of programmable assets, communication interfaces, and access paths that need to be governed. Digital relays, IEDs, RTUs, SSCLs, switches, gateways, servers, engineering workstations, SCADA systems, and connections to operation centers form an operational-technology — OT — infrastructure directly linked to the electrical process.

In this environment, a cyber failure is not limited to information loss. It may cause loss of supervision, unavailability of telecommands, alteration of settings, blocking of engineering workstations, degradation of communication channels, or presentation of incorrect states to the operator. Cybersecurity engineering must therefore preserve simultaneously the safety of people, functional integrity, operational availability, and recoverability.

IEC 62443 provides concepts and structures for addressing the security of industrial automation and control systems throughout their life cycle. In substations, it can be combined with power-system-specific references such as IEC 62351, network-engineering guidance from ABNT NBR 16932, and OT security practices consolidated by NIST SP 800-82.

This article presents a method for applying these concepts to distribution, transmission, and generation substations. The objective is not to turn the standard into a generic equipment list, but to show how risks, zones, conduits, access, hardening, monitoring, and testing become design deliverables and contracting criteria.

Why Substations Require Their Own Cybersecurity Approach

Substations combine requirements that normally do not coexist with the same intensity in corporate networks. Certain communications have latency and predictability constraints; assets may remain in operation for decades; maintenance windows are limited; changes must be coordinated with protection, automation, and operations; and failures may affect continuity of electricity supply.

In corporate IT, confidentiality may occupy a central position. In OT, integrity and availability often receive greater weight, with operational safety as an overriding constraint. This does not make confidentiality irrelevant: diagrams, settings, topologies, credentials, and configuration files are also sensitive. It means that every control needs to be analyzed for its effect on the process.

A deep-inspection, authentication, or encryption solution may be technically desirable but unsuitable in a critical communication path if it introduces delay, unavailability, or nondeterministic behavior. IEC 62443 recognizes this conflict by treating performance and continuity as part of the security problem itself.

The correct approach begins with four questions:

1. which electrical and operational functions must be preserved; 2. which assets and communications support those functions; 3. which consequences may result from alteration, unavailability, or unauthorized access; 4. which controls reduce risk without compromising protection, control, and operational safety.

What Is IEC 62443?

IEC 62443 is a family of documents focused on cybersecurity for industrial automation and control systems. The original ISA99 work was used in development of the international series, which is why the expressions ISA/IEC 62443 and ISA IEC 62443 are also common.

The family distributes responsibilities among asset owners, service providers, integrators, and manufacturers. In general terms, its documents address:

  • concepts, models, and terminology;
  • security programs, policies, and procedures;
  • risk assessment and system requirements;
  • secure development life cycle and component requirements.

ABNT IEC/TS 62443-1-1:2023, available in A3A’s technical database, establishes fundamental concepts such as defense in depth, assets, threats, vulnerabilities, zones, conduits, and security levels. It should not be used in isolation as though it contained all detailed requirements from the other parts of the series.

It is also important not to present IEC 62443 as a universal obligation. ABNT technical documents are generally voluntary. They may become mandatory when incorporated into contracts, corporate standards, bidding documents, regulations, or other instruments applicable to the project.

Fundamental Industrial Security Requirements

ABNT IEC/TS 62443-1-1 identifies seven fundamental requirement groups. They help verify whether the design covers the essential dimensions of security.

Fundamental requirementApplication in a substation
Access controlRestrict who or which system can reach IEDs, servers, switches, gateways, and engineering tools
Use controlLimit what an authenticated identity can view, change, command, or administer
Data integrityDetect or prevent unauthorized alteration of commands, settings, files, events, and communications
Data confidentialityProtect sensitive information when the risk or communication path justifies it
Restricted data flowAllow only necessary communications between zones and assets
Timely response to eventsDetect, record, communicate, and address violations or anomalies within a timeframe compatible with risk
Resource availabilityMaintain critical functions and prevent failures or attacks from exhausting resources needed for operation

These requirements are not a product list. Access control, for example, may involve identity, firewall rules, physical protection, vendor policy, and operational approval. Availability may depend on redundancy, DC power, independent routes, backups, and recovery procedures.

IEC 62443, IEC 62351, NIST 800-82 and ISO 27001

The references complement one another, but they do not serve the same purpose.

IEC 62443

Provides a framework for security of industrial automation and control systems, including life cycle, responsibilities, risk, zones, conduits, system requirements, and component security.

IEC 62351

The IEC 62351 series addresses security of data and communications used for management and information exchange in power systems. ABNT NBR 16932 itself identifies this series as a reference for communication cybersecurity and cites the part dedicated to IEC 61850.

While IEC 62443 helps structure the OT environment’s security program and architecture, IEC 62351 is closer to mechanisms applicable to power-sector protocols and exchanges. Selection of applicable parts should consider the protocols actually used and equipment support.

NIST SP 800-82

NIST SP 800-82 Rev. 3 is an OT security guide covering governance, risks, architectures, segmentation, remote access, monitoring, vendors, vulnerabilities, incidents, and recovery. It is a good-practice reference, not a Brazilian regulation.

The document emphasizes that IT controls need to be adapted to OT performance, availability, and operational-safety constraints. It also recommends a multidisciplinary team bringing together automation, operations, networking, IT, cybersecurity, physical security, management, and vendors when necessary.

ISO/IEC 27001

ISO/IEC 27001 provides the structure for an information security management system. It is useful for governance, risk assessment, responsibilities, audits, and continual improvement. IEC 62443 adds specificity for industrial environments and their operational constraints.

None of these references replaces the asset owner’s requirements, utility procedures, operating philosophy, or project contractual conditions.

Security Is Not a Project with an End Date

IEC 62443 treats security as a life cycle. An architecture may meet requirements at commissioning and later lose effectiveness because of new vulnerabilities, configuration changes, obsolescence, access that was not revoked, or changes in threats.

The cycle needs to include:

  • assessment and definition of requirements;
  • design and specification;
  • implementation and validation;
  • operation and monitoring;
  • maintenance and change management;
  • risk reassessment;
  • modernization, decommissioning, and secure disposal.

This perspective is especially important in substations, where the service life of primary assets and protection systems may exceed the support cycle of operating systems, switches, servers, and software components.

Critical Assets and Functions of a Substation

The inventory should not begin only with IP addresses. Physical, logical, and human assets need to be related to the functions they support.

Physical and Technological Assets

  • protection relays and IEDs;
  • merging units and process-interface equipment;
  • RTUs, SSCLs, and gateways;
  • switches, routers, firewalls, and telecommunications equipment;
  • SCADA servers, historians, and time-synchronization services;
  • operator and engineering workstations;
  • teleprotection systems;
  • VMS, cameras, and operational-video equipment;
  • control panels, optical distribution frames, and links;
  • power supplies, rectifiers, battery banks, and UPS systems.

Logical Assets

  • firmware and software versions;
  • relay settings;
  • protection and control logic;
  • SCL files and databases;
  • switch and firewall configurations;
  • certificates and keys;
  • point lists and telecommand matrices;
  • diagrams, procedures, and backups;
  • event records and histories.

Human and Organizational Assets

  • operators;
  • protection, automation, and telecommunications engineers;
  • maintenance teams;
  • network and server administrators;
  • integrators and manufacturers;
  • managers responsible for risk acceptance.

Compromise of an engineering workstation may be more significant than temporary loss of a read-only station because the former may alter configurations across multiple assets. Criticality must reflect function, authority, and consequence.

OT Asset Inventory and Classification

An inventory useful for engineering and security should include, at minimum:

FieldPurpose
Identification and locationRelate the asset to the bay, panel, room, substation, or operation center
FunctionIndicate protection, control, supervision, telecommunications, video, or management
Manufacturer and modelSupport maintenance, vulnerability analysis, replacement, and compatibility
Hardware, firmware, and softwareDetermine update status and dependencies
Interfaces and addressesMap physical ports, IP and MAC addresses, serial ports, and optical interfaces
Protocols and servicesIdentify MMS, GOOSE, SV, SNMP, NTP, PTP, DNP3, IEC 60870-5-104, and others
Zone and conduitRelate the asset to the security architecture
OwnerDefine technical ownership and change authority
CriticalityRecord the impact of loss of integrity, availability, or control
Support and end of lifePlan upgrades, spares, replacement, and compensating controls
Backup and restorationIdentify where the configuration is stored and how it can be recovered

Automated discovery can help, but active tools need to be used carefully. NIST records that inadequate scanning and testing have caused interruptions in control networks. In operating environments, passive surveys, existing documentation, equipment queries, and controlled windows tend to be safer.

Cybersecurity Risk Analysis

Risk analysis should relate assets, threats, vulnerabilities, consequences, and controls. It is not enough to import an IT matrix and simply rename the servers.

In substations, consequences may include:

  • loss of process visibility;
  • loss or delay of telecommands;
  • incorrect state indication;
  • alteration of protection settings;
  • teleprotection unavailability;
  • blocking of engineering workstations;
  • loss of records needed for event analysis;
  • propagation to other substations or operation centers;
  • degraded operation for longer than acceptable;
  • need for emergency dispatch of personnel;
  • risk to people and equipment.

A practical assessment can follow this cycle:

1. define scope, boundaries, and critical functions; 2. inventory assets and communications; 3. identify threats and vulnerabilities; 4. assess physical, operational, and digital consequences; 5. estimate initial risk; 6. select technical, administrative, and physical controls; 7. assess the impact of controls on operations; 8. record residual risk and acceptance authority; 9. monitor changes and reassess periodically.

The response may involve avoiding, reducing, sharing, transferring, or accepting risk. Acceptance must be explicit and traceable, particularly when correction depends on a future outage window or asset replacement.

Relevant Threats to Substations

Security should not consider only external attackers. IEC 62443 and NIST address intentional, accidental, structural, and environmental threats.

OriginExamples
Adversarialunauthorized access, malware, command manipulation, data spoofing, denial of service, and credential abuse
Internalunauthorized change, excessive privilege use, log removal, or connection of an unapproved device
Accidentalconfiguration error, incompatible patch deployment, command issued to the wrong installation, or use of an inadequate tool
Structuralhardware, power-supply, switch, software, storage, synchronization, or communication failure
Environmentalsurges, electromagnetic interference, loss of cooling, fire, flooding, or prolonged power failure
Supply chaincompromised component, unsupported software, insecure update, or excessive vendor access

The architecture must also address non-malicious errors and failures. A control that protects against intrusion but creates a single point of failure may reduce overall operational security.

Zones and Conduits

Zones and conduits are central concepts in IEC 62443.

A security zone groups physical, logical, or application assets that share security requirements. It has a boundary, policy, owners, and access criteria. It may be physical, such as a telecommunications room, or logical, such as a set of servers and IEDs separated by function.

A conduit groups communications and mechanisms that enable information flow within a zone or between zones. A conduit may include links, switches, routers, firewalls, gateways, VPNs, and rules protecting the transported channels.

The definition should start from function and risk, not merely from the existing topology.

ElementDesign questions
Zone assetsWhich devices, applications, and people belong to the group?
FunctionWhich process or service does the zone support?
BoundaryWhere do responsibility and control begin and end?
RiskWhat is the consequence of compromise or unavailability?
FlowsWith which zones is communication actually necessary?
ControlsHow will identity, integrity, availability, and flow restriction be implemented?
ManagementWho approves changes and who is responsible for the assets?
MonitoringWhich events and indicators demonstrate the condition of the zone?

A VLAN by itself does not constitute a complete security zone. It may contribute to logical separation, but it needs to be combined with flow controls, port protection, configuration management, monitoring, access rules, and documentation.

A secure architecture starts with inventory, zones, and flow control.

The design needs to convert risk analysis into topology, boundaries, permitted communications, access, monitoring, and acceptance criteria compatible with substation operation.

Learn about Telecommunications Design

Reference Architecture for Substations

Each utility or agent may adopt a corporate reference architecture and detail it by substation family. The model needs to reflect operational reality, not merely a generic level-based diagram.

One possible decomposition is shown below.

ZoneTypical assets and functionsMain considerations
Processsensors, actuators, merging units, and primary interfacesintegrity, availability, latency, and physical access
Protection and controlrelays, IEDs, bay units, and interlocksdeterministic performance, independence, and controlled change
Local supervisionRTU, SSCL, gateways, HMI, and local serversavailability, point list, commands, and logs
Engineering workstationtools, notebooks, and configuration filesprivileged access, integrity, and traceability
Operational telecommunicationsswitches, routers, multiplexers, and WANredundancy, routes, management, and supervision
Teleprotectionrelays, equipment, and dedicated or logical channelslow latency, independence, and end-to-end testing
Operational videocameras, VMS, recording, and event integrationstraffic separation, availability, and controlled access
Physical securityCCTV, access control, perimeter, and intrusionprevent security systems from creating a path into OT
OT DMZjump server, proxy, repository, and controlled transferprevent direct communication between the corporate network and critical OT
Operation centerSCADA, historians, workstations, and management servicesidentity, availability, segregation, and continuity
Corporate networkadministrative applications and general usersshould not directly reach assets at lower operational levels
Remote accessVPN, bastion, authentication, and session recordingapproval, limited duration, least privilege, and revocation

The list is not universal. A small installation may combine functions; a more critical operation may subdivide primary and backup protection, separate engineering workstations by domain, or create distinct zones for synchronization and management.

The zone-and-conduit architecture depends on a well-defined network foundation. Topology, switches, VLANs, routing, protocols, redundancy, and monitoring should be specified together, as detailed in the guide on industrial networks, security, and SCADA integration.

Segmentation Between Protection, Control, SCADA, Video and Management

Segmentation should prevent a failure or compromise in a less critical system from propagating freely to protection and control functions.

Some separations that deserve analysis include:

  • process bus and station bus;
  • primary and backup protection systems;
  • protection and supervision;
  • substation LAN and operational WAN;
  • equipment management and functional traffic;
  • engineering workstations and operator stations;
  • operational video and automation;
  • physical security and OT network;
  • substation and operation center;
  • OT and corporate network.

ABNT NBR 16932 provides engineering guidance for IEC 61850 networks, including topologies, redundancy, VLANs, multicast, performance, synchronization, management, and testing. The standard itself states that it does not detail cybersecurity. Its use should therefore be combined with a risk-based security architecture.

Logical separation may be appropriate in certain applications, provided risk, performance, and common failures are analyzed. Primary and backup protection placed in different VLANs but using the same switches, power supplies, and links remain subject to shared dependencies.

Authorized Flow Matrix

Before configuring firewalls and ACLs, a communication matrix should be produced. It transforms the architecture into verifiable requirements.

SourceDestinationService or protocolDirectionPurposeCriticalityOwner
Bay IEDSSCLMMSaccording to architecturesupervision and controlhighautomation
IEDIEDGOOSElocal multicastinterlocking or protectioncriticalprotection
ClockIEDs and switchesPTP/NTP/IRIG-Bdistributionsynchronizationhighautomation/telecom
SSCLOperation centertelecontrol protocolcontrolled bidirectionaldata and telecommandshighoperations
Engineering workstationIEDmanagement protocolauthorized sessionparameterizationcriticalprotection/automation
OT devicelog serversyslog or supported mechanismoutboundauditmedium/highcybersecurity

The recommended policy is deny by default and allow only what is necessary. Outbound rules also need to be controlled. A compromised asset may use outbound communications for lateral movement, command and control, or exfiltration.

OT DMZ and Communication with the Corporate Network

When integration between OT and IT is required, direct communication between the corporate network and critical levels should be avoided. An OT DMZ may host intermediary services such as:

  • jump server or bastion host;
  • controlled-transfer servers;
  • historian replicas;
  • update proxy;
  • specific authentication services;
  • log collectors;
  • monitoring tools;
  • application gateways.

The DMZ should not be merely a VLAN with a different name. It needs controlled boundaries, distinct policies, minimal rules, monitoring, and administration procedures.

Where flow is required only from OT to upper environments, unidirectional gateways may be considered. The decision depends on required services, the need for commands or maintenance, and risk analysis.

Identities, Profiles and Least Privilege

Access to OT assets should be granted based on role, need, and duration. Operators, engineers, administrators, auditors, and vendors do not need the same permissions.

The design should define:

  • individual identities whenever technically feasible;
  • role-based access profiles;
  • administrative accounts separated from regular-use accounts;
  • technical accounts with owner and purpose;
  • granting, review, and revocation processes;
  • treatment of emergency accounts;
  • protection and rotation of secrets;
  • logging of privileged actions.

Shared accounts reduce traceability. When legacy equipment does not support individual identities, compensating controls may include password vaults, checkout records, session supervision, prior approval, and correlation with a work order.

Corporate authentication should not be automatically applied at all levels. Direct dependence of the OT network on corporate services may compromise availability. The architecture needs to decide which services will be local, replicated, or isolated.

Engineering Workstations

The engineering workstation has high authority because it can change settings, logic, SCL files, network configurations, and device parameters. It should be treated as a critical asset, not as a conventional maintenance notebook.

Possible controls include:

  • dedicated use for the function;
  • inventory of software and versions;
  • blocking unauthorized applications;
  • control of removable media;
  • malware protection compatible with the environment;
  • strong authentication;
  • configuration backups before and after changes;
  • recording who changed what and under which work order;
  • access only to required zones;
  • controlled storage of files and credentials;
  • verification before connecting to different substations.

When vendor notebooks are allowed, the contract needs to define minimum requirements, validation, authorized tools, internet access, malware protection, and quarantine procedures.

Remote Access for Operators and Vendors

Remote access crosses the physical boundary of the substation. A VPN alone does not resolve identity, authorization, duration, destination, logging, and revocation.

A robust architecture may include:

1. request linked to a ticket or work order; 2. operational and technical approval; 3. multifactor authentication at the remote entry point; 4. access to a jump server in the OT DMZ; 5. authorization only for required assets and protocols; 6. defined time window; 7. session monitoring and recording; 8. automatic termination at the end of the activity; 9. validation of the changed configuration; 10. immediate revocation after completion or contract termination.

Permanent manufacturer connections, forgotten modems, untracked support software, and broad VPN rules are recurring risks. The inventory should include all remote paths, including cloud solutions, cellular links, and tools embedded in equipment.

Remote maintenance also needs a degraded mode. The substation cannot depend on vendor access availability to perform essential functions or restore a basic configuration.

Hardening of IEDs, Relays, Switches and Gateways

Hardening is the definition and application of a reference configuration that reduces the attack surface without preventing the operational function.

IEDs and Relays

  • change default credentials;
  • create profiles according to equipment capabilities;
  • disable unused services and ports;
  • control local, front-panel, and maintenance interfaces;
  • protect settings files and firmware;
  • configure available logs and alarms;
  • document operating modes and physical keys;
  • validate impacts on protection and communication.

Switches and Routers

  • disable unused ports;
  • limit VLANs allowed on each port;
  • control trunks and management interfaces;
  • use secure management protocols when supported;
  • restrict administration sources;
  • configure logs, time, and monitoring;
  • protect configurations and backups;
  • document multicast, QoS, redundancy, and routes.

Servers and Workstations

  • minimal installation;
  • required services only;
  • compatible local firewall;
  • least-privilege service accounts;
  • application control;
  • tested updates;
  • protection of databases and histories;
  • verified backup and restoration.

A baseline needs to identify which requirements are mandatory, recommended, or not applicable. Exceptions should have a justification, risk assessment, compensating control, and approval.

Firmware, Patch and Vulnerability Management

Immediately updating every asset can be as risky as never updating. The process should combine vulnerability intelligence, applicability analysis, and operational validation.

Recommended steps:

1. receive advisories from manufacturers, CISA, vulnerability databases, and sector sources; 2. identify affected models, versions, and assets; 3. assess exposure, function, consequence, and known exploitation; 4. verify compatibility and dependencies; 5. test in a representative environment; 6. plan the maintenance window, backup, and rollback; 7. apply and validate functions; 8. record evidence and update the inventory; 9. implement compensating controls when the fix cannot be applied.

Compensating controls may include additional segmentation, access restriction, blocking a vulnerable service, specific monitoring, or planned replacement. They should not become a permanent excuse to keep unsupported assets in service.

The program also needs to address end of life. Manufacturers and integrators should state support periods, vulnerability policy, firmware availability, and update requirements.

Certificates, Keys and Time Synchronization

Certificates and keys can authenticate devices, users, and communications, but they introduce an infrastructure that also needs to be operated.

The design should define:

  • issuing authority and trust chain;
  • certificate inventory;
  • owners responsible for issuance and renewal;
  • private-key storage;
  • handling of expiration and revocation;
  • equipment replacement;
  • recovery after configuration loss;
  • impact of incorrect time on validation.

Time synchronization also supports events, records, and investigations. Time sources, primary and backup paths, holdover, alarms, and distribution security need to be documented. Improper time changes can impair event correlation and traceability.

Logs, Monitoring and Detection

Monitoring should combine operational and cybersecurity context. In OT networks, traffic tends to be more predictable than in corporate networks, which favors creation of baselines.

Possible sources include:

  • firewalls and routers;
  • switches;
  • servers and workstations;
  • IEDs and gateways that support logging;
  • SCADA and SDSC systems;
  • physical access control;
  • remote-access systems;
  • antivirus, allowlisting, and integrity tools;
  • management and inventory platforms.

Relevant events include:

  • successful or denied authentication;
  • account creation and modification;
  • configuration changes;
  • firmware updates;
  • firewall-rule changes;
  • device connection;
  • communication loss or restoration;
  • route or redundancy changes;
  • synchronization failure;
  • new traffic between assets;
  • use of an unexpected protocol;
  • restart and resource loss.

Passive collection through TAP or SPAN is often preferable as a starting point. Automated IPS responses need careful evaluation because an incorrect block can affect critical communications.

Integration with SIEM or SOC is possible, but use cases should consider OT semantics. A legitimate GOOSE burst, a PRP switchover, or an operational event sequence should not be interpreted without context.

Backup, Restoration and Continuity

Backup needs to cover more than server files. Recovery may depend on:

  • IED settings and firmware;
  • automation projects and SCL files;
  • switch, router, and firewall configurations;
  • databases and point lists;
  • certificates and key documentation;
  • system images and installers;
  • licenses;
  • compatible versions of engineering tools;
  • diagrams, inventories, and procedures.

Copies need to be protected against alteration and unavailability. At least a portion should remain separated from the operational environment to resist destructive incidents.

Restoration should be tested. The test needs to answer:

  • is the file intact;
  • is a compatible tool available to open it;
  • can the version be loaded into the equipment;
  • are licenses and certificates available;
  • is the recovery sequence documented;
  • does restoration time meet operational needs.

Continuity also involves degraded operation. Procedures need to indicate how the substation will be operated during loss of SCADA, WAN, server, synchronization, engineering workstation, or part of cybersecurity monitoring.

Incident Response in OT Environments

The response plan should be prepared before an incident occurs. IT-style containment based on immediately shutting down or isolating equipment may be inappropriate when the asset supports protection, control, or safety.

The procedure should define:

  • incident classification;
  • roles and authorities;
  • contacts for operations, protection, automation, telecommunications, IT, and vendors;
  • isolation criteria;
  • evidence preservation;
  • internal and external communication;
  • safe operation during response;
  • restoration and validation;
  • return to normal condition;
  • root-cause analysis and improvement.

Useful exercise scenarios include:

  • compromised vendor credential;
  • malware on an engineering workstation;
  • unauthorized change to a relay;
  • loss of visibility at the operation center;
  • abnormal traffic on the station network;
  • SCADA server unavailability;
  • VPN compromise;
  • ransomware in the corporate environment with risk of propagation to OT;
  • loss of switch or firewall configuration.

Tabletop exercises make it possible to verify decisions and responsibilities without affecting the installation. Technical tests need to be planned so they do not interrupt active functions.

Physical Security and Cybersecurity

The cyber boundary can be crossed physically. Switch ports, serial interfaces, USB, panels, racks, splice boxes, and equipment at remote locations need protection proportional to criticality.

Integration with access control, intrusion detection, and CCTV can help correlate:

  • a person entering a technical room;
  • a panel being opened;
  • equipment being connected;
  • an administrative session starting;
  • a configuration change;
  • departure from the location.

Physical-security systems themselves are connected assets. Cameras, controllers, and panels should not create an uncontrolled bridge into automation networks. Operational video and physical security should have defined zones and flows.

Vendor and Supply-Chain Security

Substations depend on manufacturers, integrators, developers, and maintenance providers. Risk does not end when the equipment is delivered.

Contractual requirements may include:

  • secure development practices;
  • vulnerability-disclosure process;
  • notification deadline to the contracting party;
  • patch and firmware policy;
  • support period and end of life;
  • software composition or SBOM when applicable;
  • required accounts and access;
  • protection of development and support environments;
  • control of subcontractors;
  • return or deletion of data;
  • transfer of configurations, passwords, and certificates;
  • support during incidents;
  • security-test evidence.

A certified product or one with security features does not by itself guarantee that the installation will reach the intended level. Security results from the combination of component capabilities, architecture, configuration, processes, and operations.

OT Cybersecurity Design and Documentation

The engagement needs to produce documents that can be used by implementation, operations, and supervision.

Possible deliverables include:

  • scope and boundary definition;
  • OT asset inventory;
  • criticality classification;
  • risk and treatment matrix;
  • reference architecture;
  • zone and conduit map;
  • authorized-flow matrix;
  • port and protocol table;
  • access and profile matrix;
  • remote-access policy;
  • hardening baseline by asset family;
  • logging and monitoring requirements;
  • certificate and key strategy;
  • vulnerability and update plan;
  • backup and recovery strategy;
  • incident-response plan;
  • vendor requirements;
  • procurement specifications;
  • modernization plan;
  • FAT and SAT procedures;
  • test matrix and acceptance criteria;
  • as-built documentation.

The design should clearly identify what belongs to the utility, the automation integrator, the telecommunications provider, the relay manufacturer, and the cybersecurity team. Undefined interfaces tend to create gaps.

Modernizing Existing Substations

In existing installations, implementation should begin with diagnosis and a transition plan. Legacy equipment may not support individual authentication, encryption, logging, or current firmware.

Modernization needs to consider:

  • permitted outages;
  • migration sequence;
  • coexistence of new and old equipment;
  • outage windows;
  • compensating controls;
  • rollback to the previous condition;
  • operation-center updates;
  • tool compatibility;
  • team training;
  • procedure review.

Segmentation may be implemented progressively, starting with critical boundaries, remote access, and paths between IT and OT. The objective is to reduce risk without creating an unfeasible transformation or a parallel architecture that is impossible to maintain.

FAT, SAT and Cybersecurity Commissioning

Security controls need to be tested as part of the system. FAT can verify configurations, profiles, flows, hardening, logs, backups, and component behavior before installation. SAT validates the actual architecture, including links, addresses, rules, integrations, and field conditions.

A test matrix may include:

DomainVerification
Inventorymodel, version, address, function, and owner match the design
Zonesassets are connected to intended zones and there are no alternative paths
Flowsonly approved ports, protocols, sources, and destinations are allowed
Identitiesprofiles, administrative accounts, technical accounts, and revocations operate correctly
Remote accessMFA, approval, jump server, time limitation, and logs are demonstrated
Hardeningunnecessary services, default credentials, and unused ports have been addressed
Redundancyfailures of links, equipment, and power supplies do not eliminate critical functions
Performancecontrols do not degrade GOOSE, SV, teleprotection, SCADA, or synchronization beyond permitted limits
Monitoringevents are generated, transported, synchronized, and interpreted correctly
Backupconfigurations are exported, protected, and restored in a controlled environment
Incidentsprocedures, contacts, and degraded operation are exercised
Documentationdiagrams, matrices, configurations, and reports reflect the final installation

Active tests, scans, and simulations need to be authorized and assessed for risk. In production, inappropriate tools may lock controllers or degrade communications.

Controls declared in the design need to be demonstrated during FAT, SAT, and assisted operations.

Tests should validate segmentation, profiles, remote access, hardening, logs, redundancy, recovery, and the impact of controls on GOOSE, SV, teleprotection, SCADA, and synchronization.

Learn about Commissioning and Technical Acceptance

Acceptance Criteria and Technical Dossier

Each requirement should be associated with a method, expected result, tolerance, and evidence. Statements such as “segmented network” or “secure access” are insufficient without demonstration.

The dossier may include:

  • requirements and traceability matrix;
  • approved and as-built diagrams;
  • final inventory;
  • exported configurations;
  • rules and flows report;
  • list of accounts and profiles;
  • hardening evidence;
  • FAT and SAT results;
  • performance measurements;
  • redundancy and recovery tests;
  • remote-access records;
  • backups and restoration report;
  • pending items, accepted risks, and action plans;
  • acceptance documents.

Cybersecurity pending items need an owner, deadline, impact, and temporary control. Energization or entry into operation should not erase traceability of these pending items.

Owner’s Engineering in Substation Programs

In programs involving multiple substations and vendors, Owner’s Engineering can support interface governance and independent verification of requirements.

Possible activities include:

  • review architecture and specifications;
  • verify adherence to corporate standards;
  • analyze technical proposals;
  • coordinate protection, automation, telecommunications, and cybersecurity;
  • control documents and revisions;
  • follow FAT and SAT;
  • verify the test matrix;
  • record pending items and deviations;
  • assess change requests;
  • consolidate acceptance evidence;
  • monitor residual risks.

This function is particularly useful when each vendor demonstrates only its own equipment but no one demonstrates the integrated behavior of the substation and operation center.

Indicators for Continuous Operation

After commissioning, indicators help demonstrate whether the security level is being maintained.

  • percentage of inventoried assets;
  • unsupported assets or assets approaching end of life;
  • vulnerabilities by criticality and deadline;
  • remote-access sessions and exceptions;
  • accounts without periodic review;
  • changes not reconciled with the baseline;
  • backup or restoration failures;
  • unavailable log sources;
  • new or unauthorized communications;
  • incident detection and treatment time;
  • controls and procedures tested;
  • FAT and SAT pending items still open.

The indicator should not encourage unsafe actions. A target for rapid patch deployment, for example, needs to consider testing, maintenance windows, and operational impact.

Common Mistakes

Treating IEC 62443 as an Equipment Checklist

The standard structures risk, responsibilities, architecture, and life cycle. Buying a firewall or NAC does not replace inventory, flows, policies, and testing.

Creating VLANs Without Controlling Communications

VLANs help with organization and logical segmentation, but by themselves they do not ensure flow restriction, identity, or monitoring.

Applying IT Practices Without Assessing Operations

Scanning, patches, IPS, and authentication can introduce unavailability or latency. Each control needs to be tested in the context of the function.

Connecting Support Systems Directly to the Critical Network

Video, access control, maintenance, printing, antivirus, historization, and corporate services can create unplanned paths.

Maintaining Permanent Vendor Access

Access without approval, duration, logging, and revocation expands the attack surface and reduces accountability.

Not Knowing Existing Assets

Without model, version, firmware, function, and owner, it is not possible to assess vulnerability, support, or impact.

Confusing Redundancy with Independence

Two systems sharing a switch, power supply, cable, server, or credential can fail simultaneously.

Testing Only the Nominal Configuration

Acceptance needs to include link loss, authentication failure, service unavailability, restoration, switchover, and degraded operation.

Ending the Program After Implementation

The achieved level decreases over time. Auditing, vulnerabilities, changes, training, and revalidation need to continue.

Further Learning Paths in OT Cybersecurity

IEC 62443 provides the risk, zone, conduit, and life-cycle architecture. Specific controls can be explored further through the paths below.

Identity and Access

Monitoring and Protection

Protocols and Architecture

How to Contract a Cybersecurity Design for Substations

The terms of reference should state:

  • types and number of installations;
  • project stage or legacy condition;
  • existing corporate architecture;
  • protection, automation, and telecommunications standards;
  • systems and protocols involved;
  • operation centers and integrations;
  • remote-access requirements;
  • existing vendors;
  • maintenance-window and outage restrictions;
  • deliverables and formats;
  • implementation responsibilities;
  • tests and acceptance criteria;
  • need for procurement support, supervision, or Owner’s Engineering.

Proposals should be compared by method and engineering deliverables, not merely by the number of security devices. The contracting party needs to know who will perform the survey, how risks will be assessed, which documents will be produced, and how controls will be tested.

Conclusion

Applying IEC 62443 to substations means transforming operational risks into architecture decisions, responsibilities, controls, and evidence. The result is not a network isolated indiscriminately, but an infrastructure in which every asset is known, every communication has a purpose, every access has authority, and every change can be traced.

Security needs to preserve protection, control, telecommunications, and operations. The design should therefore integrate electrical engineering, automation, networks, cybersecurity, physical security, and operations from requirements definition through commissioning.

Zones and conduits provide a language for organizing this architecture. Inventory, flow matrices, controlled remote access, hardening, monitoring, recovery, and testing complete the cycle. Continuous maintenance ensures that the achieved level is not lost through vulnerabilities, changes, and obsolescence.

Technical References

[1] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT IEC/TS 62443-1-1:2023 — Security for industrial automation and control systems — Part 1-1: Terminology, concepts and models.

[2] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security. 2023.

[3] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT NBR 16932:2020 — Communication networks and systems for power system automation — Network engineering guidelines.

[4] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT NBR IEC 61850-10:2018 — Communication networks and systems for power system automation — Part 10: Conformance testing.

[5] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST CSWP 28 — Security Segmentation in a Small Manufacturing Environment.

Frequently Asked Questions
What is IEC 62443?

It is a family of documents for cybersecurity of industrial automation and control systems. It addresses concepts, security programs, risk assessment, system requirements, service providers, and components.

Is IEC 62443 mandatory in all substations?

Not universally. Technical standards are normally voluntary, but they may become requirements when incorporated into contracts, corporate standards, bidding documents, regulations, or other applicable instruments.

What are zones and conduits?

A zone groups assets that share security requirements. A conduit groups and protects communications within a zone or between zones, including channels, equipment, rules, and control mechanisms.

Is a VLAN sufficient to create a security zone?

No. A VLAN can contribute to logical separation, but the zone also needs a boundary, policy, flow control, access management, monitoring, owners, and test criteria.

What is the difference between IEC 62443 and IEC 62351?

IEC 62443 structures industrial-system security, its life cycle, risks, zones, and requirements. IEC 62351 focuses on the security of data and communications used in power systems. They are complementary.

How should remote access to a substation work?

Access should be approved, strongly authenticated, limited to required assets, preferably mediated through a jump server or bastion, logged, temporary, and revoked when the activity ends.

Can patches be applied immediately to OT assets?

Not always. Patches need to be assessed and tested for compatibility, performance, and operational safety. When they cannot be applied, compensating controls and a correction or replacement plan should be adopted.

How can an OT network be monitored without disrupting operations?

Passive monitoring through TAP or SPAN is usually the safest starting point. Active tools and automated responses need to be assessed and tested so they do not degrade critical communications.

Can CCTV and access control share the automation network?

Sharing should not be assumed. Video, physical security, and automation have different requirements and should be separated into zones and controlled flows according to risk analysis.

What should be tested during cybersecurity FAT and SAT?

Inventory, zones, flows, profiles, remote access, hardening, logs, redundancy, performance, backup, recovery, failures, and conformity of documentation with the actual installation should be verified.

What is the role of Owner’s Engineering in OT cybersecurity?

Owner’s Engineering can review requirements, coordinate interfaces, analyze proposals, supervise vendors, follow testing, control pending items, and consolidate evidence for technical acceptance.

Which documents make up a cybersecurity design for substations?

Key documents include inventory, risk matrix, architecture, zone and conduit map, flow matrix, access profiles, hardening baseline, remote-access policy, vulnerability plan, monitoring, backup, incident response, and testing.

Additional Technical Materials

Solutions

Engineering Services

Additional Technical Materials