Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control for power system management
IEC 62351-8:2026 (E) is to facilitate role-based access control (RBAC) for power system management. RBAC assigns human users, automated systems, and software applications (collectively called "subjects" in this document) to specified "roles", and restricts their access to only those resources, which the security policies identify as necessary for their roles.
As electric power systems become more automated and cyber security concerns become more prominent, it is becoming increasingly critical to ensure that access to data (read, write, control, etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of running a business. RBAC is not a new concept; in fact, it is used by many operating systems to control access to system resources. Specifically, RBAC provides an alternative to the all-or-nothing super-user model in which all subjects have access to all data, including control commands.
RBAC is a primary method to meet the security principle of least privilege, which states that no subject should be authorized more permissions than necessary for performing that subject’s task. With RBAC, authorization is separated from authentication. RBAC enables an organization to subdivide super-user capabilities and package them into special user accounts' termed roles for assignment to specific individuals according to their associated duties. This subdivision enables security policies to determine who or what systems are permitted access to which data in other systems. RBAC thus provides a means of reallocating system controls as defined by the organization policy. In particular, RBAC can protect sensitive system operations from inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to human users though; it applies equally well to automated systems and software applications, i.e., software parts operating independent of user interactions.
The following interactions are in scope:
– local (direct wired) access to the object by a human user, a local and automated computer agent, or a built-in human machine interface (HMI) or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated computer agent, e.g., another object at another substation, a distributed energy resource at an end-user’s facility, or a control centre application.
While this document defines a set of mandatory roles to be supported, the exchange format for defined specific or custom roles is also in scope of this document. This is achieved by defining two different encoding approaches to handle the definition of custom roles, either based on specific permissions or based on constraints to existing permissions. The definition on handling custom based roles was started in IEC 62351-90-1 and taken over into the IEC 62351-8:2020. Moreover, additionally to the definition of custom roles based on associated permissions, this document also includes options how to assign permissions to objects in a general way. Referencing documents will provide a mapping to a concrete data model to ensure an interoperability for standard roles used in different data models as well as for custom defined roles. Referencing documents might be standards such as IEC PAS 61850-90-19 or IEC 60870 5 7:2025 or also definitions by an operator.
Out of scope for this document are all topics which are not directly related to the definition of roles and access tokens for local and remote access, especially administrative or organizational tasks, such as:
– definition of usernames and password definitions/policies;
– management of keys and/or key exchange;
– engineering process of roles;
– assignment of roles;
– selection of trusted certification authorities issuing credentials (access tokens);
– defining the tasks of a security officer;
– integrating local policies in RBAC.
Existing standards (see ANSI INCITS 359-2004, IEC 62443 (all parts), and IEEE 802.1X-2020) in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient for addressing specifics of power system automation as none of them specify either the exact role name and associated permissions or the format of the access tokens nor the detailed mechanism by which access tokens are transferred to and authenticated by the target system. This is addressed in this document by defining the access token format, distribution and verification based on existing technology.
Throughout the document security events are defined. These security events are intended to support the error handling and thus to increase system resilience. Implementations need to provide a mechanism for announcing security events.
The information about security events and potential detailed information can only be provided by the entity based on the availability of this information through the underlying platform or utilized components.
It is strongly recommended that the security events defined throughout the document are made available to the operational infrastructure by cyber security events as specified in IEC 62351 14 and/or by monitoring objects as specified in IEC 62351-7. Annex A provides a mapping of the defined events in this document to the notion of IEC 62351-14.
Notices, warnings, errors, and alarms are used to indicate the severity of an event from a security point of view. The following notion from IEC 62351-14 is used:
– A notice refers to a cyber security related activity during the routine use or maintenance of an entity. It does not relate to a cyber security breach or attack or deviation from the normal operating condition of an entity.
– A warning is a deviation from the normal operating condition of an entity but not necessary a cyber-attack.
– An error describes an unforeseen condition, which can indicate unauthorized activity. It might not require immediate action.
– An alarm is an indication of a serious problem, which might indicate unauthorized activity. Action is expected to be taken immediately.
In any case, it is expected that an organization’s security policy determines the final handling of events based on the operational environment. For instance, the assessment of one of more alarms could rise to the level of an incident.
This second edition cancels and replaces the first edition published in 2020. This edition constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous edition:
a) Removal of mapping of roles to permission to objects based on the target data model and/or protocol to allow for other mappings than IEC 61850. Mapping is delegated to separate documents;
b) Specification of handling of a combination of roles and permissions as operationSet to allow more fine-grained assignments to objects;
c) Specification of a simplified roles assignment to more efficiently handle situations in which roles are used relating to different data models, including examples;
d) Inclusion of new profile to allow for fetching RBAC information from LDAP repositories;
e) Definition of specific security events throughout the document;
f) Alignment of terminology and enhancement with examples.
