IEC 61850 Explained: GOOSE, Sampled Values, MMS and IEC 62351 Security

IEC 61850 is the IEC Technical Committee 57 standard series for communication in power utility automation, used mainly inside electrical substations. It gives every protection relay, breaker controller and merging unit a shared data model, a shared configuration language (SCL) and three main ways to talk: MMS client and server reporting, GOOSE multicast for fast trips and Sampled Values for digitised currents and voltages. Classic IEC 61850 has no built-in authentication; the IEC 62351 series adds TLS for MMS, message authentication for GOOSE and Sampled Values, role based access control and key management.

This post sits beside our other one protocol per post explainers for operational technology: DNP3, Modbus, OPC UA and PROFINET. For the regulatory side, see energy sector software security and NERC CIP, NERC CIP-013 and smart grid and AMI software. Here we stay on IEC 61850 itself, ending with a passive test bench workflow for inventorying a 61850 system without touching live protection.

Key takeaways

• IEC 61850 is a series of more than 60 documents. The core parts cover the data model (7-x), the configuration language (6), the MMS and GOOSE mapping (8-1) and Sampled Values (9-2), mostly edition 2 texts consolidated with 2020 amendments.
• The data model is the heart of the standard. Logical nodes such as XCBR (circuit breaker), PTOC (time overcurrent protection) and MMXU (measurements) give every vendor's device the same names for the same functions.
• SCL (IEC 61850-6) is an XML format describing devices, data, addresses and who subscribes to which GOOSE stream. The SCD file is the best single inventory of a 61850 system.
• MMS runs over TCP/IP for client and server traffic such as reporting and control. GOOSE and Sampled Values are Layer 2 Ethernet multicast with no IP header, built for protection timing measured in milliseconds and microseconds.
• Plain GOOSE and Sampled Values carry no authentication; their sequence numbers serve reliability, not security.
• IEC 62351-6:2020 secures GOOSE and SV, 62351-3 and 62351-4 secure TCP/IP and MMS, 62351-8 adds role based access control and 62351-9 handles keys, including GDOI group keys. Adoption is slow for practical reasons: timing, device lifetimes, key management and multivendor testing.
• Time for Sampled Values comes from the IEC/IEEE 61850-9-3 profile of IEEE 1588 PTP.
• VLANs organise traffic. They are not a security boundary.

What IEC 61850 is, why it was created and how the series is organised

Before IEC 61850, a substation was a patchwork. Relays from one manufacturer spoke one serial protocol, bay controllers spoke another, gateways translated, and every signal one relay needed from another ("breaker failed to open", "block this zone") was a pair of copper wires and a contact. Engineering meant mapping thousands of points by hand.

IEC 61850 fixed three things at once: what the data means (a semantic model, so a breaker position looks the same on every device), how a system is described (a machine readable configuration language) and a small set of protocols to carry it. The IEC's own IEC 61850 portal says the standard anticipated early that standardising protocols alone "was not enough" for interoperability across a system's life. Because the parts can be used largely independently, the data model now also appears in wind, hydro and distributed energy resources.

The series is maintained by IEC Technical Committee 57, "Power systems management and associated information exchange", mainly through working group 10. TC 57 also owns IEC 60870-5 (including 104), IEC 60870-6 (ICCP), the Common Information Model (IEC 61968 and 61970) and the IEC 62351 security series.

When was IEC 61850 first published?

Sources differ slightly. The IEC 61850 portal says "originally published in 2004", while the encyclopedia entry lists the first part on 28 April 2003; the first edition parts came out in stages. Edition 2 of the core parts followed between 2009 and 2011, and amendments in 2018, 2020 and 2024 produced the consolidated texts sold today.

The parts you actually need to know

Most engineers work with a handful of the series. Identifiers, editions and dates below are from each part's IEC webstore page in October 2026.

Parts 7-4xx extend the model to other domains (7-410 hydro, 7-420 distributed energy resources), 80-x documents map 61850 to other protocols, and the 90-x Technical Reports cover use cases such as inter-substation communication. IEC PAS 61850-90-19, listed in 2026, carries the role based access control work for IEC 61850 that the IEC portal mentions. Part 8-2 maps ACSI to XMPP.

A dated timeline

The IEC 61850 data model: logical devices, logical nodes and data objects

In DNP3 or IEC 60870-5-104, a point is a number whose meaning lives in a spreadsheet. In IEC 61850, the meaning is in the name.

The model is a hierarchy:

1. Physical device. The box on the panel, called an IED (intelligent electronic device). A protection relay, a bay controller, a merging unit or a gateway.
2. Logical device (LD). A group of related functions inside the IED, for example a protection logical device and a control logical device. Each logical device has an instance name such as PROT or CTRL.
3. Logical node (LN). One function, named with a four letter class from IEC 61850-7-4 plus an optional prefix and an instance number. Every logical device contains LLN0 (logical node zero, which holds the control blocks and settings for the device) and usually LPHD (the physical device information).
4. Data object (DO). A piece of information that the function exposes, typed by a common data class from IEC 61850-7-3. A breaker's position is Pos, a protection operate signal is Op, a start (pickup) signal is Str.
5. Data attribute (DA). The actual values, such as stVal (status value), q (quality) and t (timestamp), each tagged with a functional constraint (ST for status, MX for measurements, CO for control, SP and SG for settings, CF for configuration, DC for description).

The logical node classes are grouped by their first letter. A few you will see on every substation:

An object reference reads like a path. RELAY1PROT/PTOC1.Op.general is the operate flag of the first time overcurrent function in the protection logical device of IED RELAY1; BAY1CTRL/XCBR1.Pos.stVal is a breaker's position. Any vendor's tool can read either and know what it means. The model keeps growing: 7-4 edition 2.1 added logical nodes for power quality, statistics and IEC 62271 monitoring, per its webstore summary.

Datasets are named lists of data; control blocks in LLN0 say how a dataset is sent: report control blocks to MMS clients, GOOSE control blocks (GoCB) as GOOSE, and sampled value control blocks (MSVCB, USVCB) as SV. Control blocks tell you who sends what.

What ACSI is

IEC 61850-7-2 defines the Abstract Communication Service Interface (ACSI): reading, writing, reporting, logging, control, file transfer, GOOSE and Sampled Values, with no wire format. Specific communication service mappings then map ACSI to MMS and Ethernet (8-1), XMPP (8-2) and Ethernet for SV (9-2). The 7-2 webstore summary says security issues "are solved by the IEC 62351 series": ACSI itself carries none.

How SCL describes a substation

SCL is the XML format defined in IEC 61850-6, which its webstore summary says exchanges IED and system descriptions "between IED engineering tools and the system engineering tool(s) of different manufacturers". An SCL file has up to five main sections:

The engineering process moves through several file types, all of them SCL:

• ICD (IED Capability Description): what a device type can do, shipped by the manufacturer.
• IID (Instantiated IED Description): one configured IED, exported from its tool.
• SSD (System Specification Description): the single line diagram and required functions, before devices are chosen.
• SCD (Substation Configuration Description): the complete, configured substation with every IED, address and GOOSE subscription. This is the file that matters most for inventory and security review.
• CID (Configured IED Description): the slice of the SCD that is loaded into one IED.
• SED (System Exchange Description): data exchanged between two projects, for example at a boundary between substations.

Two consequences matter for security. The SCD is a near complete map of protection and control, so treat it as sensitive, keep it under version and access control, and know who has copies. And it is the authoritative statement of what should be on the network: a GOOSE stream or MMS client it does not describe is a finding. IEC 62351-11 covers security for XML files, and the IEC 62351-6:2020 summary lists IEC 61850-6 in its scope.

How MMS, GOOSE and Sampled Values work

The station bus links IEDs to each other, the HMI and the gateway. The process bus, in newer designs, links IEDs to primary equipment through merging units, replacing copper from instrument transformers and breakers.

MMS: client and server

IEC 61850-8-1 reuses the Manufacturing Message Specification (ISO 9506) for client and server traffic; its webstore summary describes exchanging "time-critical and non-time-critical data" by mapping ACSI to MMS and Ethernet frames. MMS runs over TCP port 102 using ISO transport over TCP, with OSI session and presentation layers above. Services you will see:

• Association. A client (HMI, gateway or engineering laptop) opens an association with an IED. Without IEC 62351 it has no meaningful authentication.
• Read, write and reporting. Clients read objects by reference, write settings where allowed, and enable report control blocks so the IED pushes changes. Buffered blocks (BRCB) keep events while a client is away; unbuffered ones (URCB) do not.
• Control. Direct operate or select before operate on objects such as CSWI.Pos, which is how a breaker close command travels.
• Logs and files. Event logs and disturbance recordings (COMTRADE) come back over MMS file services.

MMS is routable and connection oriented, so it behaves like any TCP service, which makes it the natural place for TLS under IEC 62351-3 and 62351-4.

GOOSE: multicast for protection signals

GOOSE (Generic Object Oriented Substation Event) replaces relay to relay wiring. An IED publishes a dataset such as "trip" as an Ethernet multicast frame, with no IP header and no acknowledgement, and every configured subscriber acts on it. Frames carry EtherType 0x88B8, usually with an IEEE 802.1Q VLAN tag and high priority. Reliability comes from repetition:

• On a change, the publisher sends at once, repeats at short growing intervals, then settles to a slow heartbeat it sends indefinitely.
• stNum (state number) increments on each change; sqNum (sequence number) increments on each repeat and resets when the state changes.
• timeAllowedtoLive tells subscribers how long to wait before declaring the stream lost.
• gocbRef, datSet, APPID, goID and confRev identify the stream, and test, simulation and ndsCom flags mark its status.

Wireshark's GOOSE dissector exposes these as fields (goose.stNum, goose.sqNum, goose.timeAllowedtoLive, goose.simulation, goose.confRev, goose.gocbRef). IEC 61850-8-1 edition 2.1 added link layer redundancy, GOOSE simulation and a fixed length encoded GOOSE, per its webstore summary.

The security point: stNum and sqNum let a subscriber tell a new event from a repeat. They are not a cryptographic freshness check. A well formed frame with the right identifiers and a higher state number will generally be processed, so anyone able to place frames on the segment could, in principle, imitate a trip or block signal. That is why IEC 62351-6 exists; the defences are architectural and, where devices support it, cryptographic.

Sampled Values: digitised currents and voltages

Sampled Values (SV) carry instantaneous currents and voltages. A merging unit samples the instrument transformer signals, numbers each sample (smpCnt) against a synchronised clock and publishes them as multicast at a fixed rate; protection IEDs compute on the stream instead of copper CT and VT inputs. The 9-2 webstore summary calls this "a mixed stack using direct access to an ISO/IEC 8802-3 link". SV uses EtherType 0x88BA, and Wireshark exposes svID, smpCnt, smpSynch (synchronisation state), confRev, noASDU and smpRate.

SV traffic is continuous and heavy, so it needs its own VLAN or a separate process bus. Every protection decision depends on these frames and the clock behind them, and in the base standard a subscriber cannot tell whether a well formed stream came from the right merging unit. The instrument transformer side is standardised in IEC 61869-9.

Routable GOOSE and SV

IEC TR 61850-90-5 (May 2012), written for synchrophasor transport, also "provides routable profiles" for GOOSE and SV packets (R-GOOSE and R-SV), so they can cross IP networks. Routable GOOSE has the reach of any IP traffic, which makes its security more urgent. The open source libiec61850 C library (GPLv3) implements MMS, GOOSE, SV and R-Session per its README and is handy on a test bench.

Why GOOSE and Sampled Values are Layer 2 multicast, and what that means for authentication

GOOSE and SV skip TCP/IP for time. IEC 61850-5 sets transfer time performance classes, and those for trips and blocking sit in the low single digit milliseconds; SV must be predictable sample after sample. Going straight onto Ethernet avoids IP stacks, connection setup and routing delay, and multicast lets one breaker failure signal reach every relay that needs it at once. The consequences:

A trip signal is not secret, so encryption matters less than integrity and authenticity: proof the frame came from a key holder and was not altered. Public key signatures on every GOOSE repeat and SV frame are hard to fit into protection time budgets on embedded processors, so the practical approach is a message authentication code under a group key shared by publisher and subscribers, distributed through GDOI (Group Domain of Interpretation) as IEC 62351-9 specifies. The trade off: any holder of the group key can produce valid frames, so the key server and every keyed IED join the security boundary.

What IEC 62351 adds

IEC 62351 is the TC 57 security series. The IEC 61850 portal says it covers IEC 60870-5 (including DNP3), 60870-6, 61850, 61970 and 61968, that "there is not a one-to-one correlation" between protocol and security parts, and that it profiles existing Internet standards wherever possible.

What each mechanism protects

• MMS. TLS under 62351-3 gives mutual certificate authentication and integrity on the TCP connection; 62351-4 adds application layer and end to end authentication that survives gateways.
• GOOSE and SV. 62351-6 adds an authentication value per frame under a group key. The 9-2 edition 2.1 summary lists a "redefinition of 'reserved' fields in link layer", which is where the extension travels, so older subscribers can still parse frames during migration.
• Keys and people. 62351-9 handles certificates and group keys; 62351-8 lets an IED decide whether an authenticated subject may view, operate, change settings or update firmware.
• The network. 62351-7 gives switches, IEDs and clocks standard management objects so communication faults and security events surface like power system alarms.

Why IEC 62351 deployment is slow

Many substations run IEC 61850 without 62351 GOOSE and SV authentication, for practical reasons:

1. Device lifetimes. Relays stay in service for decades, and many installed IEDs cannot run the extensions. Replacing protection means outages and re-testing.
2. Timing. Every authenticated frame costs processing on publisher and subscribers, and protection must still meet its time budget.
3. Key management. GDOI needs a key server, certificates for every IED and a plan for outages and expiry. An expired certificate must never stop a trip.
4. Interoperability. Security extensions must work across vendors, which needs the 62351-100 conformance tests and interoperability events.
5. Engineering and testing. Keys and settings must flow through SCL tools, and changes touching every protection message need full end to end testing.

The standards exist, several parts are recent (62351-3 and 62351-9 in 2023, 62351-8 in 2026), and device support is uneven. Until authentication covers a whole substation, the realistic defence is architectural: tight Layer 2 segmentation, controlled access, managed engineering laptops, monitoring and strict configuration management.

Time synchronisation and process bus designs

Why time matters more in IEC 61850 than in older protocols

In a digital substation, time is part of the measurement. Samples from different merging units must be aligned before differential protection compares currents at two ends of a transformer; misaligned clocks create a difference current that does not exist.

IEC/IEEE 61850-9-3:2016 specifies a PTP profile of IEC 61588:2009 / IEEE Std 1588-2008 that, per its webstore summary, allows compliance with the highest synchronisation classes of IEC 61850-5 and IEC 61869-9. IEEE 1588, per its IEEE page, supports synchronisation accuracy in the sub-microsecond range. A typical design has GNSS locked grandmasters, PTP aware switches and IEDs and merging units as clients. IEEE C37.238 is the related IEEE power profile; we could not fetch its page, so check its current edition directly.

Protection should block or alarm when smpSynch shows lost synchronisation. Time is also a security asset: whoever can influence PTP on the process bus could degrade protection, which is why IEC 62351-9 edition 2 added GDOI support for PTP under the 61850-9-3 profile. GNSS antennas, holdover and loss of lock monitoring belong in the same review.

Station bus and process bus

Both 8-1 and 9-2 edition 2.1 list link layer redundancy, in practice PRP and HSR from IEC 62439-3, which send every frame over two paths. Redundancy protects availability, not integrity: two copies of a forged frame are still forged.

IEC 61850 compared with DNP3 and IEC 60870-5-104

A common architecture runs IEC 61850 inside the substation and DNP3 or 104 from the gateway to the control centre, so the gateway is where two security models meet and one of the most important devices to harden.

Where IEC 61850 sits in NIST IR 7628, NIST SP 800-82 and NERC CIP

NIST IR 7628 Revision 1 (September 2014), Guidelines for Smart Grid Cybersecurity, is a three volume report whose abstract describes an analytical framework for building cybersecurity strategies tailored to an organisation's smart grid characteristics, risks and vulnerabilities. It is more than a decade old, so pair it with current OT guidance.

NIST SP 800-82 Revision 3 (September 2023), Guide to Operational Technology Security, covers OT topologies, threats and countermeasures. Its NIST page carries a planning note dated 21 September 2026 pointing to the Revision 4 initial public draft, with comments due 30 November 2026.

NERC CIP applies to the North American bulk electric system (BES). It never names IEC 61850, but its requirements land squarely on 61850 substations:

• CIP-002 (BES Cyber System Categorization) decides which relays, controllers and gateways are in scope.
• CIP-005 (Electronic Security Perimeter(s)) applies to systems with External Routable Connectivity. GOOSE and SV are Layer 2, but MMS, R-GOOSE and the gateway are routable, so every routable path into the substation counts.
• CIP-007 (System Security Management) covers ports and services, patching, security event monitoring and access control; for IEDs that means knowing which services (MMS, web, FTP, vendor protocols) are enabled.
• CIP-010 (Configuration Change Management and Vulnerability Assessments) requires baselines that list firmware or operating system versions, commercial and open source application software, custom software, logical network accessible ports and applied patches. An SCD plus a firmware register is a strong start.
• CIP-013 (Supply Chain Risk Management) includes vendor incident notification, verification of software integrity and authenticity, and coordination of vendor remote access.

Step by step: inventory from SCL, capture GOOSE on a test bench and map controls

This walkthrough is passive, for a test bench, factory acceptance setup or approved mirror port. Never connect test laptops to live protection networks without the asset owner's procedure, and never publish GOOSE, SV or MMS commands into a live system.

Step 1: Get the SCD file and check its integrity

Get the current SCD from protection engineering, record its hash and keep it in version control:

mkdir -p ~/61850-review && cd ~/61850-review
cp /path/to/substation.scd ./substation.scd
shasum -a 256 substation.scd | tee substation.scd.sha256
git init -q . && git add substation.scd substation.scd.sha256
git commit -qm "Baseline SCD received from protection engineering"

Note the Header version, revision and last History entry. An SCD that does not match what the IEDs run is itself a finding.

Step 2: Inventory IEDs, GOOSE publishers and SV streams from the SCD

This standard library script reads an SCD (namespace http://www.iec.ch/61850/2003/SCL) and prints IEDs, GOOSE and SV control blocks with multicast address, APPID and VLAN, and every subscription. It talks to no device.

#!/usr/bin/env python3
"""Inventory an IEC 61850 SCD file: IEDs, GOOSE/SV control blocks, addresses, subscriptions."""
import sys
import xml.etree.ElementTree as ET

NS = {"scl": "http://www.iec.ch/61850/2003/SCL"}

def p_values(addr):
    return {p.get("type"): (p.text or "").strip() for p in addr.findall("scl:P", NS)} if addr is not None else {}

def main(path):
    root = ET.parse(path).getroot()

    print("== IEDs")
    for ied in root.findall("scl:IED", NS):
        print(f"{ied.get('name'):<16} manufacturer={ied.get('manufacturer')} type={ied.get('type')} "
              f"configVersion={ied.get('configVersion')}")

    print("\n== Communication addresses (GSE = GOOSE, SMV = Sampled Values)")
    for cap in root.iterfind(".//scl:ConnectedAP", NS):
        ip = p_values(cap.find("scl:Address", NS)).get("IP", "")
        print(f"{cap.get('iedName'):<16} ap={cap.get('apName')} ip={ip}")
        for kind in ("GSE", "SMV"):
            for cb in cap.findall(f"scl:{kind}", NS):
                p = p_values(cb.find("scl:Address", NS))
                print(f"   {kind:<3} ld={cb.get('ldInst')} cb={cb.get('cbName')} "
                      f"mac={p.get('MAC-Address')} appid={p.get('APPID')} "
                      f"vlan={p.get('VLAN-ID')} prio={p.get('VLAN-PRIORITY')}")

    print("\n== Control blocks defined in IEDs")
    for ied in root.findall("scl:IED", NS):
        for ld in ied.iterfind(".//scl:LDevice", NS):
            ln0 = ld.find("scl:LN0", NS)
            if ln0 is None:
                continue
            for g in ln0.findall("scl:GSEControl", NS):
                print(f"{ied.get('name')}/{ld.get('inst')} GOOSE {g.get('name')} dataset={g.get('datSet')} "
                      f"appID={g.get('appID')} confRev={g.get('confRev')}")
            for s in ln0.findall("scl:SampledValueControl", NS):
                print(f"{ied.get('name')}/{ld.get('inst')} SV {s.get('name')} smvID={s.get('smvID')} "
                      f"smpRate={s.get('smpRate')} nofASDU={s.get('nofASDU')} confRev={s.get('confRev')}")

    print("\n== Subscriptions (who listens to whom)")
    for ied in root.findall("scl:IED", NS):
        for ext in ied.iterfind(".//scl:Inputs/scl:ExtRef", NS):
            src = f"{ext.get('iedName')}/{ext.get('ldInst')}/{ext.get('prefix') or ''}{ext.get('lnClass')}{ext.get('lnInst') or ''}.{ext.get('doName')}"
            print(f"{ied.get('name'):<16} <- {src} service={ext.get('serviceType')} cb={ext.get('srcCBName')}")

if __name__ == "__main__":
    main(sys.argv[1])

Run it and keep the output next to the SCD:

python3 -I scl_inventory.py substation.scd | tee scd-inventory.txt
grep -c "^   GSE" scd-inventory.txt   # number of GOOSE streams with addresses
grep -c "^   SMV" scd-inventory.txt   # number of SV streams with addresses

What to look for:

• IEDs whose configVersion disagrees with the asset register.
• GOOSE or SV sharing a VLAN with unrelated traffic, or using no VLAN.
• Stale ExtRef subscriptions to publishers that no longer exist.
• MMS IP addresses outside the planned address plan.

Step 3: Record IED firmware versions alongside the SCD

The SCD says what IEDs are configured to do, not which firmware they run. Collect versions from engineering tools, the LPHD.PhyNam nameplate data or commissioning records, and keep a CSV beside the SCD:

ied_name,manufacturer,model,firmware_version,firmware_date,location,bay,last_verified
RELAY1,ExampleVendor,ModelA,4.2.1,2025-03-14,Substation North,Bay 1,2026-10-20
MU1,ExampleVendor,MergingUnitB,2.0.7,2024-11-02,Substation North,Bay 1,2026-10-20

When a vendor advisory lands, this file answers "do we run that version, and where?" in minutes.

Step 4: Capture GOOSE and SV on a test bench

Capture passively; the filter matches tagged and untagged frames:

# Confirm the interface is the bench or mirror port you were given before capturing.
ip link show
sudo tcpdump -i enp3s0 -s 0 -w goose-sv-bench.pcap \
  '(ether proto 0x88b8 or ether proto 0x88ba) or (vlan and (ether proto 0x88b8 or ether proto 0x88ba))'

Summarise GOOSE streams, one line per stream:

tshark -r goose-sv-bench.pcap -Y goose -T fields \
  -e eth.src -e eth.dst -e vlan.id -e goose.appid -e goose.gocbRef -e goose.datSet \
  -e goose.confRev -e goose.simulation -e goose.test \
  | sort | uniq -c | sort -rn > goose-streams.txt

Watch one stream's counters:

tshark -r goose-sv-bench.pcap -Y 'goose.gocbRef contains "PROT"' -T fields \
  -e frame.time_relative -e goose.stNum -e goose.sqNum -e goose.timeAllowedtoLive | head -50

Steady state shows a fixed stNum with sqNum climbing at the heartbeat. When a bench test set simulates a fault, stNum increments, sqNum resets and repeats speed up briefly. Then Sampled Values:

tshark -r goose-sv-bench.pcap -Y sv -T fields \
  -e eth.src -e eth.dst -e vlan.id -e sv.appid -e sv.svID -e sv.confRev -e sv.smpSynch \
  | sort | uniq -c | sort -rn > sv-streams.txt

An unsynchronised smpSynch on a protection stream is an immediate question for the protection team.

Step 5: Compare what you saw with what the SCD says

Every captured stream should match a control block in scd-inventory.txt, and every MMS client (tshark -r capture.pcap -Y mms -T fields -e ip.src -e ip.dst | sort -u) should be an HMI, gateway or approved engineering station.

Step 6: Map what you found to NERC CIP and NIST IR 7628

A working aid, not audit advice; confirm wording against current standards.

Common mistakes

• Treating VLANs as a security boundary. VLANs separate traffic; they authenticate no one. Anything on an access port in the right VLAN, or a misconfigured trunk, sees and can send everything. Add port security, disabled unused ports, multicast filtering and monitoring.
• Unmanaged engineering laptops. The laptop with the engineering tools, the SCD and test software has more reach than any remote attacker. Inventory it, patch it, use it only for engineering and connect it only through approved paths.
• No inventory of IED firmware versions. Without one, every vendor advisory becomes a site visit.
• SCD drift. Years of small changes leave the archived SCD out of step with the IEDs. Reconcile after every change.
• Testing in production. Active scans and test injections on live protection networks risk restarting devices or tripping equipment. Use a bench, and passive capture on approved mirror ports in service.
• Leaving test and simulation flags on. Check them at every return to service.
• Treating the gateway as just a protocol converter. It is the main routable path in; harden, monitor and include it in CIP-005 design.
• Ignoring time. GNSS clocks and PTP switches are protection critical once Sampled Values are in use.
• Enabling security without a failure plan. Certificate expiry or a key server outage must not become a reliability incident.

FAQ

What is IEC 61850 used for?

Communication and configuration in power utility automation, mainly substations: relays, bay controllers, merging units, HMIs and gateways. Its data model also appears in wind, hydro and distributed energy resources.

What is the difference between GOOSE and MMS in IEC 61850?

MMS is client and server messaging over TCP/IP for data, reports, settings, commands and files. GOOSE is publisher and subscriber multicast directly on Ethernet (EtherType 0x88B8) for fast trips and interlocks, with no IP header and no acknowledgement.

What are Sampled Values in IEC 61850?

Sampled Values, defined in IEC 61850-9-2, are streams of digitised current and voltage measurements published by merging units as Ethernet multicast. Protection IEDs subscribe to them instead of being wired to instrument transformers, which is the basis of a process bus or digital substation.

Is GOOSE encrypted or authenticated?

Not in the base standard. Plain GOOSE frames carry no authentication and no encryption. IEC 62351-6 defines message authentication for GOOSE and Sampled Values using group keys distributed under IEC 62351-9, but support in installed devices is uneven.

What is an SCD file?

The SCL (XML) file from IEC 61850-6 describing a fully configured substation: every IED, dataset, control block, address and subscription. Handle it as sensitive engineering data.

What does IEC 62351 cover?

IEC 62351 is the IEC TC 57 security series for power system communication protocols. For IEC 61850 the key parts are 62351-3 (TLS), 62351-4 (MMS security), 62351-6 (security for IEC 61850, including GOOSE and SV), 62351-7 (network and system management), 62351-8 (role based access control), 62351-9 (key management) and 62351-14 (security event logging).

Does NERC CIP require IEC 62351?

No. NERC CIP does not name IEC 62351 or IEC 61850. Its requirements (categorisation, electronic security perimeters, systems security management, configuration change management, supply chain risk management) apply to BES Cyber Systems regardless of protocol. IEC 62351 is one way to meet some of them technically.

How is time synchronised in an IEC 61850 substation?

With the precision time protocol. IEC/IEEE 61850-9-3 defines a PTP profile of IEEE 1588-2008 for power utility automation, with grandmaster clocks usually locked to GNSS and PTP aware switches, so merging units and IEDs can align samples within the accuracy that protection needs.

Can GOOSE be routed between substations?

Yes, with the routable profiles in IEC TR 61850-90-5, often called R-GOOSE and R-SV. They were written for synchrophasor and wide area use cases. Routable GOOSE exposes protection signals to IP networks, so its security profile needs to be enabled and the paths need to be controlled.

Where Safeguard fits

Safeguard does not monitor substation networks, inspect GOOSE or Sampled Values, configure switches, manage IEDs or scan relay firmware, and it is not an industrial intrusion detection system. IEC 61850 devices, their firmware and their configuration files are outside what it analyses, and fixes for IED firmware come only from the device manufacturer.

The fit is indirect but real in the software your team builds around the substation: services that forward MMS reports to a historian, SCL processing scripts, test bench tooling built on open source 61850 libraries and analytics container images all carry open source dependencies. Safeguard can scan those repositories, container images and SBOM files with safeguard scan --dir ., --image <name> or --sbom <file>, match their components against vulnerability databases, show which projects contain a given component and version, rank findings with reachability analysis, and evaluate policies and gates in the platform. That supports the software side of CIP-010 baselines and CIP-013 programmes.

A rebuilt historian bridge or engineering workstation pulls its open source libraries again from package registries and base images, and the tools that parse SCL or speak MMS ship open source components of their own. Those dependencies need the same patch discipline as any other software you build, even though the relays and merging units themselves are patched only by their manufacturers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not substation network monitoring or IED security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the repository or container image of a service your team builds to collect MMS reports or process SCL files, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know what to rebuild after a library advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before any command that changes something, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Node.js or Python service that forwards substation data to a historian or dashboard.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory, which is the question a CIP-013 vendor advisory usually starts with.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEC webstore: IEC 61850 series, Communication networks and systems for power utility automation
• IEC webstore: IEC 62351 series, Data and communications security
• IEC 61850 portal (IEC TC 57): home and scope
• IEC 61850 portal: IEC 62351 cybersecurity for IEC 61850
• IEC 61850 portal: communication concepts
• IEC webstore: IEC 61850-6 consolidated edition 2.2
• IEC webstore: IEC 61850-7-2 edition 2.1
• IEC webstore: IEC 61850-7-4 edition 2.1
• IEC webstore: IEC 61850-8-1 edition 2.1
• IEC webstore: IEC 61850-9-2 edition 2.1
• IEC webstore: IEC/IEEE 61850-9-3:2016
• IEC webstore: IEC TR 61850-90-5:2012
• IEC webstore: IEC 62351-3:2023
• IEC webstore: IEC 62351-4:2018+AMD1:2020
• IEC webstore: IEC 62351-6:2020
• IEC webstore: IEC 62351-8:2026
• IEC webstore: IEC 62351-9:2023
• IEEE SA: IEEE 1588, Precision Clock Synchronization Protocol
• NIST CSRC: NIST IR 7628 Revision 1, Guidelines for Smart Grid Cybersecurity
• NIST CSRC: NIST SP 800-82 Revision 3, Guide to Operational Technology Security
• NERC: CIP-002-5.1a BES Cyber System Categorization
• NERC: CIP-005-7 Electronic Security Perimeter(s)
• NERC: CIP-007-6 Systems Security Management
• NERC: CIP-010-4 Configuration Change Management and Vulnerability Assessments
• NERC: CIP-013-2 Supply Chain Risk Management
• Wireshark display filter reference: GOOSE
• Wireshark display filter reference: IEC 61850 Sampled Values
• libiec61850 on GitHub
• Wikipedia: IEC 61850 (first publication date)
• Wikipedia: Generic Substation Events

Last reviewed: 25 October 2026. The IEC 61850 and IEC 62351 series, NERC CIP standards and NIST SP 800-82 are all under active revision; check the pages above for current editions before relying on a specific part number or requirement.