How does GOOSE Messages work?

How GOOSE messages are structured on the wire

GOOSE is a publish-subscribe mechanism in IEC 61850. A sender publishes protection or control state changes onto the local Ethernet segment, and subscribed devices react immediately without waiting for a polling cycle or a routed application exchange. The result is very low latency, deterministic delivery for events such as trips, interlocks, and breaker status changes.

Because the messages are designed for fast event propagation, the payload is narrow and purpose-built. GOOSE is not intended for general data transfer, file movement, or operator interaction. Its value comes from rapid distribution of a small set of time-sensitive state changes to devices that already understand the same substation model.

In practice, that means the protocol depends on the local Layer 2 environment more than on normal client-server assumptions. Devices must share the right VLAN or broadcast domain, and receivers must be subscribed to the right dataset and control logic. The behaviour is event-driven, but the reliability of the system still depends on disciplined network design and consistent engineering of the protection scheme.

Why GOOSE is fast, and what that changes for defenders

GOOSE reduces response time by avoiding request-response chat and by using multicast-style delivery across the substation network. That architectural choice is part of why it is useful, but it also means a defender has to think about who can place traffic on the segment, who can observe it, and whether devices accept messages as genuine because they fit the expected format rather than because they were cryptographically authenticated.

The operational trade-off is straightforward: the protocol is optimised for speed and availability, not for rich transport-layer trust. In a well-run OT environment, segmentation, port control, switch hardening, and careful device engineering become part of the security boundary around the message stream. The protocol itself does not solve trust in the network.

For readers who want the broader OT network context, the OT Security Guide is the right starting point because GOOSE only makes sense inside a controlled industrial communications model, not as a stand-alone security mechanism.

Common failure modes: spoofing, replay, and abnormal event storms

GOOSE becomes risky when an attacker, a misconfigured device, or a faulty engineering change can inject or repeat control events into the protection plane. Spoofed frames can trigger a false trip or suppress the expected response if subscribed relays or controllers accept them. Replay is especially relevant because an old but valid-looking event can still create unsafe state changes if the receiving logic does not detect staleness.

Another practical problem is event flooding. Because the protocol is intended for sparse, meaningful changes, unusually high message rates often indicate a device problem, a loop, a misconfiguration, or hostile activity. At that point the issue is not just network noise, it is potential process impact, because protection logic may be forced into unstable or ambiguous behaviour.

That is why defenders should watch both content and cadence. A GOOSE stream that looks syntactically valid may still be operationally wrong if it arrives from an unexpected source, appears at the wrong frequency, or causes state transitions that do not match the physical process.

Practitioner Guidance

What to verify: Confirm which devices are allowed to publish each event set, which switches carry that traffic, and whether relay logic rejects unexpected senders or stale sequence behaviour. The key question is not only whether the network is up, but whether the protection chain would still behave safely if one frame were forged or repeated.

What to prioritise: Treat segmentation and device legitimacy as the first line of defence, then validate monitoring for abnormal publish rates, source drift, and unexpected event patterns. In substation environments, the most dangerous mistake is assuming that “local traffic” automatically means “trusted traffic.”

Practitioner takeaway: GOOSE is best understood as a low-latency control signalling path, so security should focus on limiting who can speak on that path and detecting when its event behaviour stops matching the physical system.

Related resources from NHI Mgmt Group

• How does packet capture (PCAP) work?
• How does Firewall as a Service (FWaaS) work?
• How does Security Service Edge (SSE) work?
• How does Suricata work?