An Intelligent Electronic Device (IED) is a microprocessor-based device used in power systems to monitor, control, protect or communicate about electrical equipment. Because it can trip breakers or relay status, attackers target its configuration, communications and firmware, while defenders restrict access and verify settings and logs.
What an IED does in a power system
An Intelligent Electronic Device is more than a sensor or relay, it is an embedded control point that can monitor conditions, issue protective actions, and exchange operational data with surrounding equipment. In power environments, that makes it part of the control plane, not just a passive measurement device.
Because IEDs are used to protect breakers, transformers, feeders, and other critical assets, their behaviour can affect safety, availability, and system stability. A misconfigured or compromised IED can produce an incorrect trip, fail to trip when needed, or report misleading status to operators.
Configuration, communications, and firmware
IEDs usually matter most through three surfaces: configuration logic, network communications, and embedded firmware. Configuration determines how the device interprets thresholds and events, communications determine what data it accepts or forwards, and firmware determines the trusted code that governs both.
That combination is why defenders pay close attention to settings drift, management access, and update provenance. If an attacker can alter relay settings or inject malformed commands, the device may make a protective decision that benefits the attacker rather than the grid operator.
Many environments treat IEDs as specialised endpoints that should be hardened like other critical infrastructure devices. CIS Benchmarks provide a useful hardening reference for the operating systems and network devices that often support or manage this class of equipment.
Why IED exposure is a security problem
The security issue is not only device compromise, but the operational consequence of compromise. IEDs sit close to protection and control logic, so attacker manipulation can create outages, equipment damage, or loss of operator confidence in telemetry and alarms.
Exposure often increases when engineering networks are reachable from broader enterprise environments, when remote maintenance is poorly controlled, or when older protocols are left in place without compensating protections. For a defence-in-depth baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to access control, audit, configuration management, and system integrity expectations.
Security teams also benefit from a least-trust model for operational networks. NIST SP 800-207 Zero Trust Architecture is relevant where access to engineering tools, relays, or supervisory systems must be tightly bounded and continuously verified.
Monitoring, validation, and restoration
IED assurance depends on knowing what each device should be doing and being able to prove it still is. That means validating baseline configuration, reviewing event and audit logs, and checking for unexplained changes in settings, firmware, or network behaviour.
After an incident or maintenance window, teams should compare the device’s current state with approved reference settings and confirm that protection logic still matches the expected relay design. If compromise is suspected, restoration should include firmware integrity review, configuration rebuild from trusted sources, and verification that surrounding control systems were not adjusted to mask the change.
When access to the device relies on credentials, certificates, or other managed secrets, lifecycle discipline matters as much as technical hardening. NIST SP 800-57 Key Management is a useful reference where device trust depends on cryptographic keys and certificate handling.
Risk and Threat Considerations
IEDs are attractive targets because they can influence physical processes, not just data. An attacker who reaches a protection device can disrupt operations, hide abnormal conditions, or trigger unwanted switching and tripping in ways that are expensive and difficult to diagnose.
Failure mechanism: Compromised configuration, unauthorised commands, weak remote access, or tampered firmware can change how the device interprets events and executes protective actions.
Impact: The result can be misoperation of power equipment, service interruption, equipment stress, or delayed detection of a broader intrusion in the operational environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | IED administration needs tightly limited access to reduce control-path abuse. |
| CM-2 — Baseline Configuration | IEDs depend on stable approved settings for protection and control behaviour. | |
| SI-7 — Software, Firmware, and Information Integrity | IED firmware integrity directly affects the trustworthiness of protection logic. | |
| Recommendation — Restrict IED management privileges to approved operators and engineering roles. Define and enforce a trusted baseline for each IED configuration. Verify firmware and configuration integrity before restoring or redeploying an IED. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | IED access should be continuously verified across engineering and operational networks. |
| Recommendation — Apply zero-trust principles to segment and authenticate all IED management access. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | IEDs are often managed through specialised network infrastructure that needs hardening. |
| Recommendation — Harden and monitor the network paths that carry IED management and telemetry traffic. | ||
Practitioner Guidance
Why practitioners should care: IEDs are safety- and availability-sensitive assets, so they should be managed as high-consequence devices with strict ownership, approved change control, and clear recovery expectations.
What to watch for: Unplanned setting changes, unusual engineering workstation access, unexplained firmware updates, or discrepancies between live device state and the documented protection scheme deserve immediate review.
Practitioner takeaway: The safest posture is one that combines tight access, configuration integrity, and continuous verification, because in an IED environment the device itself can become an operational control path.