Cybersecurity for digital switchgear must preserve protection dependability and security while controlling who and what can change, publish, subscribe or command. A firewall that blocks a trip path is unsafe; an unrestricted engineering laptop or rogue GOOSE/SV publisher is equally unsafe. The design therefore begins with protection functions, zones, conduits and failure consequences—not a generic IT checklist.
This practical guide applies IEC 62351 and IEC 62443 concepts to protection IEDs, merging/process units, station/process networks, clocks, SCL tools, remote access, maintenance, FAT/SAT and incident recovery.
1. Define the system under consideration
- Protection/control IEDs, MU/SAMU/PIU and breaker interfaces.
- Station/process switches, PRP/HSR boxes, firewalls and routers.
- Grandmasters/GNSS, PTP/SNTP/IRIG distribution.
- HMI, gateway/RTU, historian, engineering and test workstations.
- SCL/settings/network tools, repositories, licence servers and backups.
- Remote support, portable media, vendor laptops and maintenance ports.
- Connections to control center, enterprise and third parties.
2. Consequence-driven risk assessment
| Compromise | Potential consequence | Protection priority |
|---|---|---|
| IED settings/logic | Failure to trip or unwanted trip | Configuration integrity and independent review |
| GOOSE publisher | False/missing trip, block or interlock | Source control, monitoring and fail-safe logic |
| SV publisher/time | False measurement/differential operation | Stream identity, quality, time and plausibility |
| SCADA control | Unauthorized switching | Authority, SBO/interlocks and audit |
| Network/switch | Loss/delay/storm across bays | Segmentation, redundancy and capacity |
| Engineering repository | Common-mode malicious configuration | Signed release, access and provenance |
3. Zones and conduits
- Create zones by trust, function and consequence: process protection, station control, engineering, remote/DMZ and enterprise.
- Define conduits with explicit protocols, sources, destinations, direction and operational owner.
- VLANs help forwarding separation but are not authentication or physical independence.
- Keep routine enterprise/remote traffic out of real-time protection domains.
- Preserve necessary inter-bay GOOSE/SV/PTP paths; deny-by-default must be engineered, not guessed.
- Limit fault/storm domain so one bay cannot overload the station.
- Document every temporary vendor/commissioning conduit and remove it after use.
4. Identity and access
- Use unique named accounts and least privilege for IED, switch, clock, HMI and tools.
- Separate protection-setting approval from network/security administration where feasible.
- Disable/rename defaults and unused accounts; manage service/emergency access.
- Use supported strong authentication for engineering/remote systems and controlled credential vaulting.
- Time-limit vendor access through a monitored jump host; no direct uncontrolled Internet path.
- Record login, configuration, settings and firmware events.
- Maintain an emergency access process that is tested and auditable.
5. IEC 61850 protocol security
IEC 62351-6 specifies security mechanisms for protocols based on IEC 61850, while other IEC 62351 parts address TCP/IP, role-based access, key management and security event concepts. Exact device/profile support and key/certificate lifecycle must be procured and interoperably tested.
- Do not assume “IEC 62351 ready” means every used MMS/GOOSE/SV feature is implemented.
- State protocol, cipher/authentication mode, key/certificate provisioning, renewal and revocation.
- Measure added processing/latency and verify failover/restart behavior.
- Keep clocks and certificate-validity dependencies available and recoverable.
- Use IEC TS 62351-100-6 conformance evidence, then perform project functional/cyber tests.
- Plan coexistence/migration for legacy IEDs through compensating controls.
6. GOOSE, SV and time-specific controls
- Allow only required Layer-2 multicast on defined ports/VLANs.
- Monitor source/destination MAC, APPID, VLAN, rate, ConfRev and unexpected publishers.
- Define subscriber response to timeout, bad quality, test/simulation and mismatch.
- Prevent test equipment/simulation from reaching live outputs without authorization.
- Calculate storm controls from legitimate SV and simultaneous GOOSE bursts.
- Detect rogue/changed PTP grandmaster, time offset and GNSS alarms.
- Test security rules under PRP/HSR failure; both redundant paths need equivalent policy.
7. Configuration and SCL integrity
- Store ICD/IID/SCD/CID/settings/switch/time files in an access-controlled version repository.
- Validate source, malware-scan and use hashes/signatures for releases.
- Run schema/semantic/application diff and independent review of critical trips/interlocks.
- Separate development, FAT and production packages.
- Compare loaded configuration/firmware with the approved baseline.
- Reconcile every field change into the master SCD.
- Protect backups offline/immutably and test restoration to spare equipment.
8. Network hardening
- Disable unused switch ports/services and place management in a controlled zone.
- Use explicit VLAN/trunk allowlists, multicast forwarding and QoS.
- Restrict who may mark/transmit high-priority traffic.
- Protect configurations, SNMP/management credentials and firmware.
- Monitor port errors, drops, queue utilization, redundancy and topology changes.
- Separate LAN A/B power, routes and management failure modes.
- Baseline normal traffic so anomalies are actionable.
9. Patch and vulnerability management
- Maintain asset, firmware, software, library and support-status inventory.
- Receive vendor advisories and assess exploitability/consequence.
- Prioritize by risk; not every patch is safe to install immediately on protection.
- Test in a representative FAT/twin environment with exact SCL/settings/network.
- Back up, define rollback and schedule protection outage/coverage.
- After update, regression-test SV/GOOSE/time/outputs/redundancy.
- Use compensating controls and documented acceptance where patching is deferred.
10. Monitoring and incident response
- Centralize relevant logs without overwhelming IED/network performance.
- Alert unauthorized access, configuration/firmware change, duplicate identities, multicast storm and time-source change.
- Synchronize logs and preserve time-quality evidence.
- Define isolation actions that preserve backup protection and operator control.
- Maintain offline drawings/configurations/contact lists and clean recovery media.
- Practice scenarios: compromised engineering workstation, rogue publisher, network storm and wrong time.
- Preserve forensic captures while restoring safe electrical operation.
11. FAT/SAT and acceptance
- Verify asset/port/service/account inventory and hardening baseline.
- Test roles, failed login, emergency and remote/vendor access.
- Validate allowed/denied conduits and management separation.
- Inject controlled rogue/duplicate GOOSE/SV/time and high-rate traffic.
- Measure protection timing under security controls and redundancy failure.
- Test key/certificate expiry/renewal/revocation and device reboot where applicable.
- Verify logs/alerts contain source, time, object and affected function.
- Restore approved configurations/firmware from backups.
- At SAT, verify physical ports/routes and remove temporary access.
- Approve residual risk, operating procedures and periodic audit/tests.
12. Procurement security schedule
- Supported IEC 62351 parts/features per MMS, GOOSE, SV, SCL and management interface.
- Secure boot/update, package signing, firmware provenance and rollback.
- Account/role model, password/credential policy and external identity integration.
- Key/certificate storage, commissioning, renewal, revocation and expiry behavior.
- Security logs, time synchronization, export format and event retention.
- Disablement/configuration of unused services/ports and documented hardening guide.
- Vulnerability disclosure, advisory, patch/support lifetime and end-of-support notice.
- Backup/restore and replacement-device security provisioning.
- Performance/resource limits with security features enabled.
- SBOM or component-transparency information according to owner procurement policy.
13. Residual-risk examples
| Residual risk | Compensating controls | Required proof |
|---|---|---|
| Legacy unauthenticated GOOSE/SV | Physical/port/VLAN allowlist, anomaly monitoring, independent backup | Rogue/flood containment test |
| Unpatchable legacy IED | Restricted conduit, jump host, monitoring, spare/upgrade plan | Access and recovery test |
| Remote vendor support | Time-limited approval, MFA/jump host, recording and no direct route | Access revoke and incident exercise |
| Shared engineering workstation | Application allowlist, controlled media, backups, role separation | Clean rebuild/restore rehearsal |
| Common signed configuration error | Independent semantic/application review | Traceable FAT/SAT regression |
14. Operational audit checklist
- Asset/firmware/account/service inventory matches the field.
- No temporary ports/accounts/remote routes remain.
- Configuration hashes and security logs show authorized changes only.
- Both redundancy paths, clocks, backups and manual fallback are healthy.
- Open vulnerabilities/deferred patches have owners and compensating controls.
- Incident contacts, clean media, recovery files and exercises are current.
References and further reading
- IEC 62351-6:2020 — Security for IEC 61850
- IEC TS 62351-100-6:2022 — Security conformance testing for IEC 61850
- IEC 62443-3-3:2013 — System security requirements and security levels
- IEC 61850-7-1 consolidated edition — Models and system principles
- IEC 61850-8-1 consolidated edition — MMS/GOOSE
- IEC 61850-9-2 consolidated edition — Sampled values
Engineering note: Cyber controls are protection-system changes. Any firewall, key, certificate, VLAN, switch, account or firmware change affecting a critical path requires protection impact review and end-to-end regression.