Tiza Group

Home / Guides / Standards and studies / Technical standards

IEEE 1686: IED cybersecurity capabilities

What IEEE 1686-2022 requires of a protective relay or IED: access control, roles, audit trail, configuration, firmware and ports, and how to specify it.

By Shadai García, electrical engineer, founder and CEO of Tiza Group. Reviewed by the Tiza Group engineering team · .

engineeringIEDSCADAUserRoleFirmwareRecordPort / serviceIEDwrong passworddeniedsecurity alarmaccount + rolegrantedsettings changechange loggedevery attempt and change is loggedSecurityAccountRoleActionRecordAlarm© tizagrp.comengineeringIEDSCADAUserRoleFirmwareRecordPort / serviceIEDwrong passworddeniedsecurity alarmaccount + rolegrantedsettings changechange loggedevery attempt and change is loggedSecurityAccountRoleActionRecordAlarm© tizagrp.com
IEEE 1686: access control, audit log and security alarm in the IED. Location in the system, operating principle and IEC 61850. Illustrative: actual values come from the nameplate and the manufacturer's manual.
Short answer

IEEE 1686 defines the cybersecurity functions an intelligent electronic device (IED) must provide to support its owner's security program: access, operation, configuration, firmware revision and data retrieval, with an audit trail and alarms. The current edition is 2022, which replaced the 2013 edition. It is used to specify and compare relays and controllers, together with IEC 62443-4-2 for automation components.

What IEEE 1686 is

IEEE 1686, Standard for Intelligent Electronic Devices Cybersecurity Capabilities, defines the cybersecurity functions and features that intelligent electronic devices (IEDs) must offer: protective relays, bay controllers, RTUs, gateways and similar equipment. Its aim is for the IED to have what its owner needs to apply a cybersecurity program.

The current edition is 2022, which replaced the 2013 edition. A corrigendum published in 2025 clarifies the definition of forcing values and updates bibliographic references.

The standard does not tell the utility how to organize its security. It tells the manufacturer which capabilities the device must have and gives the buyer a common language to ask for them.

What it covers

According to its published scope, IEEE 1686 deals with the security of access, operation, configuration, firmware revision and data retrieval of the IED, as well as the confidentiality, integrity and availability of its external interfaces. The manufacturer must provide safeguards, audit mechanisms and alarm indications for those functions. The 2022 edition adds explicit measures for the authenticity, integrity and confidentiality of data at rest and in transit.

In practical terms, that translates into layers of control on the device:

LayerWhat is asked of the IED
UsersIndividual accounts, strong passwords, change of factory credentials, lockout after failed attempts
RolesDifferent permissions to view, operate, configure and administer
Audit trailTime-stamped security events (logins, failed logins, configuration changes, restarts) that cannot be erased from an ordinary account
AlarmsSecurity event alerts to SCADA or a log management system
Configuration and firmwareChange control, integrity of firmware and configuration files
Ports and servicesAbility to disable those not in use
DataProtection of what the IED stores and what it sends

Why it matters in a relay

A protective relay decides when to open a breaker. Whoever changes its settings or logic can prevent a necessary trip or cause an unwanted one. For years relays had one or two passwords shared by level, the same on every device in the substation and often the same as the factory defaults. With that, there is no way to know who changed a setting, or to remove one person’s access without changing it for everyone.

IEEE 1686 pushes manufacturers toward individual accounts, roles and an audit trail, which are the basis for answering, after an incident, what happened, when and from where. They are also the technical basis for making remote access controllable, as we explain in is remote relay configuration secure?.

How to use it in a specification

  • Ask for compliance requirement by requirement. A phrase such as «complies with IEEE 1686» says nothing. Ask the manufacturer for its compliance statement for the model and firmware version offered, stating which requirements it meets, which partially and which not.
  • Choose which capabilities are mandatory for the project, according to its security policy: for example, individual accounts and an exportable audit trail.
  • Require integration with central management when the utility has it: authentication against a central server and forwarding of logs to a monitoring system.
  • Ask for the manufacturer’s firmware update and vulnerability advisory policy over the service life of the device.
  • Verify during the acceptance test that the required functions are present and configured.
From the standard to a secure relay in service
  1. 01SpecificationIEEE 1686 and IEC 62443-4-2 requirements the project demands
  2. 02Manufacturer statementCompliance per requirement for the model and firmware offered
  3. 03ConfigurationAccounts, roles, ports, logs and alarms according to the owner's policy
  4. 04Acceptance testVerification on the device of each required function
  5. 05OperationLog review, account management and firmware updates

Relationship with other standards

  • IEC 62351 protects the protocols (MMS, GOOSE, IEC 60870-5-104, DNP3). Its part 8 defines role-based access control for power system management, in line with the roles IEEE 1686 asks for.
  • IEC 62443-4-2 sets technical security requirements for components of industrial automation systems, organized by security levels. It is more general than IEEE 1686 and is useful for comparing equipment from different industries.
  • IEC 62443-3-3 deals with the security of the complete system, with zones and conduits. The IED is a component within that architecture, protected at its edge by the industrial router and firewall.

None of these standards replaces the others: IEEE 1686 says what the relay must be able to do, IEC 62351 protects what travels and IEC 62443 organizes where it can travel.

What the standard does not solve

A relay with every IEEE 1686 capability and the factory password is still vulnerable. The most common problems in the field are not about capability but about configuration and operation:

  • Factory credentials never changed, or shared accounts.
  • Engineering ports and services enabled that nobody uses.
  • Security logs that nobody reviews or that get overwritten.
  • Firmware not updated for years.
  • Outdated configuration backups.

We help with your IEDs

Tiza Group configures relays and controllers with their security functions (accounts, roles, ports and logs) as part of remote relay configuration, always with access authorized by the owner. We also specify these functions in the secondary engineering of high and extra-high voltage substations and industrial plants. Contact us.

References

  • IEEE 1686-2022, IEEE Standard for Intelligent Electronic Devices Cybersecurity Capabilities, and its corrigendum IEEE 1686-2022/Cor 1-2025.
  • IEC 62443-4-2:2019, Technical security requirements for IACS components.
  • IEC 62443-3-3:2013, System security requirements and security levels.
  • IEC 62351-8, Role-based access control for power system management.

Frequently asked questions

Does IEEE 1686 make a relay secure by itself?

No. It defines the capabilities the IED must offer, such as individual accounts, roles and an audit trail. Real security depends on the owner configuring and using them within a program with network segmentation, account management and log monitoring.

What is the difference between IEEE 1686 and IEC 62443-4-2?

IEEE 1686 is specific to power industry IEDs. IEC 62443-4-2 sets technical security requirements for any component of an industrial automation system, organized by security levels. A specification can ask for both.

How do you check that a relay meets IEEE 1686?

Ask the manufacturer for its requirement-by-requirement compliance statement for the model and firmware version offered, and during the acceptance test verify on the device the functions the project requires: accounts, roles, lockout after failed attempts, security event logging and disabled ports.

WhatsApp