How does an Intelligent Electronic Device (IED) work?

How an IED turns raw signals into protection or control

An IED sits between the physical process and the control or protection logic. It samples inputs from sensors and current or voltage transducers, evaluates them against configured settings or rules, then decides whether to trip, open, close, alarm, log, or pass data onward. In practice, it is both a measurement point and an enforcement point, so timing and configuration matter as much as the hardware itself.

What makes the device “intelligent” is not general-purpose computing, but deterministic decision-making around a defined process. The logic may be local to the device, coordinated with a supervisory system, or part of a larger protection scheme. That is why the same class of device can protect a feeder, control a breaker, or provide event records and status visibility for operators.

IEDs often expose serial or Ethernet communications, relay logic, firmware, and engineering interfaces. Those capabilities are useful because they let the device exchange telemetry and receive configuration, but they also mean the device must preserve integrity under operational load. If its settings, time source, or communications are altered, the resulting action can be incorrect even when the underlying sensor data is valid.

Where IEDs are used in industrial and power environments

IEDs are common wherever an environment needs fast local decisions, especially in substations, switchgear, protection panels, motor control centres, and industrial automation systems. They reduce dependence on remote operators by acting quickly when thresholds, fault conditions, or interlocks are met. That local autonomy is useful for safety and continuity, but it also means an IED can become a point of failure if it is misconfigured or unavailable.

In power systems, an IED may protect equipment from fault currents, isolate damaged sections, or coordinate with other relays to limit outages. In industrial control, it may supervise process conditions, issue alarms, or interlock equipment so a sequence cannot proceed out of order. The same core pattern applies: observe a condition, compare it to expected limits, and execute a pre-approved action.

Because IEDs sit close to process control, their configuration is not just an IT concern. Protection settings, logic tables, firmware versions, and communication paths all influence how the environment behaves under stress. A well-run deployment treats those elements as operationally critical assets, not just device options.

What defenders need to verify before they trust an IED

Trust starts with knowing what the device is allowed to do, what it is actually connected to, and which inputs it depends on. Defenders should confirm the approved configuration baseline, validate who can change settings, and check that engineering access is restricted to authorised workflows. The OT Security Guide is a useful starting point for the surrounding environment because IEDs rarely operate alone, they depend on segmentation, protocol control, and disciplined remote access.

Firmware and communications deserve the same attention as logic. If an IED accepts remote updates, vendor tooling, or protocol messages that can alter parameters, those paths should be authenticated, logged, and tested under change control. Configuration drift, stale firmware, and unaudited exception settings are common ways a device that once behaved correctly starts making unsafe decisions.

Operators also need to know what “normal” looks like in the device’s event log and telemetry. A change in trip behaviour, an unexpected reset, or a new engineering session can be more meaningful than a single alarming packet. For that reason, IED monitoring should focus on state changes, not just network volume.

Risk and Threat Considerations

IEDs are high-consequence devices because compromise can affect protection, availability, and physical process safety. An attacker or mistaken operator does not need to break the underlying sensor to cause damage, tampering with settings, logic, or firmware can be enough to suppress an alarm, delay a trip, or trigger an unnecessary shutdown.

Failure mechanism: Weak access control, exposed engineering interfaces, or unvalidated configuration changes let an adversary or insider alter how the IED interprets inputs and executes actions. That can disrupt protection coordination, create denial of control, or produce dangerous process conditions even when field equipment is otherwise healthy.

Impact: The result can be equipment damage, process interruption, loss of protective function, or cascading operational outage. In power and industrial environments, the business impact often follows the physical impact, so a single device compromise can become a site-level or system-level event.

Practitioner Guidance

What to prioritise: Treat the configuration surface as the primary attack and failure surface. If the IED can change how it trips, alarms, or interlocks, that control path deserves tighter review than ordinary status telemetry.

What to verify: Confirm three things before relying on the device, the active settings match the engineering intent, the firmware provenance is known, and the communications path cannot be casually modified. If any of those are uncertain, the device is not fully trustworthy yet.

Practitioner takeaway: An IED is dependable only when its logic, configuration, and communications remain tightly controlled, because the most serious failures come from altered decisions, not just from failed hardware.

Related resources from NHI Mgmt Group

• Intelligent Electronic Device (IED)
• Who should own identity and device governance in a consolidated work platform?
• Who is accountable for credential and device security when organisations support remote and flexible work?
• How should security teams prevent account takeover when identity, device, and behavioural signals all need to work together?