IEC 62351-8 defines role-based access control (RBAC) for power system management. Each user is authenticated and receives one or more roles, and each role has permissions over the objects of the device: for example, a viewer can read measurements and events but not change settings. Roles travel in an access token issued by a central identity management system. Edition 2.0, of July 2026, added a profile for obtaining role information from an LDAP directory.
What IEC 62351-8 RBAC is
IEC 62351-8, Role-based access control for power system management, is the part of the IEC 62351 series that defines how to control access to power system devices and applications according to roles. The user is authenticated, receives one or more roles, and each role has permissions over the objects of the device: read measurements, operate a breaker, change settings, administer security.
The introduction of the standard explains why. If each application decides authorization with its own logic, the utility ends up with a patchwork of mechanisms that is hard to administer. If devices consult a trusted source of roles, access is controlled centrally and each device only checks what the person connecting is allowed to do.
The current edition is 2.0, of July 2026, which replaced the 2020 one. Its main technical changes:
- It removed from the document the mapping of roles and permissions to the objects of a specific data model, to allow mappings other than IEC 61850; those mappings go in separate documents.
- It defined combinations of roles and permissions (“operationSet”) for finer assignments to objects.
- It simplified the assignment of roles when they are used with different data models, with examples.
- It included a new profile for obtaining role information from LDAP repositories.
- It defined specific security events throughout the document.
Predefined and custom roles
The standard brings predefined roles, such as VIEWER and SECADM (security administrator), and allows each utility to define custom roles; one of its examples is an operator role limited to a fault recorder. Each role groups permissions, and the standard addresses how many permissions and how many roles a device must support and how they are assigned.
In a substation, a reasonable assignment separates at least:
| Who | What they need | What they should not be able to do |
|---|---|---|
| Operator | See statuses and measurements, send switching commands | Change settings |
| Protection engineer | Read and change settings, download records | Administer accounts |
| Event analyst | Download oscillography and events | Send switching commands or change settings |
| Security administrator | Manage accounts, roles and logs | Change protection settings |
The separation between the person who changes settings and the person who administers security is deliberate: no single person can change a protection and erase the trail.
The standard also considers the operating states of the device and the definition of security events when designing roles and permissions, so that a settings change or a rejected access attempt is logged.
Access tokens and central management
In IEC 62351-8 the user’s role travels in a structure called an access token, created and managed by an identity management system, which can be federated. All tokens have a validity period and expire. Before verifying the token, the device authenticates the user; then it checks that the token is intact, current, issued by someone it trusts and contains a valid role.
The 2026 edition defines five token profiles:
| Profile | How the role information arrives |
|---|---|
| A | X.509 public key certificate |
| B | X.509 attribute certificate |
| C | JSON Web Token (JWT), obtained with OAuth |
| D | Information delivered by a RADIUS server |
| E | Role information obtained from an LDAP directory |
Self-contained tokens (certificates and JWT) allow local verification, without querying the server at each access. The RADIUS and LDAP profiles query a central repository. The choice depends on what the devices support and the identity infrastructure the utility already has. To control who connects to the substation network, see RADIUS and 802.1X: roles, flow, shared secret and common errors.
- The engineer connects to the relay
- Authentication. The relay verifies the user's identity
- Access token. Role issued by central identity management
- Is the token valid and does the role have the permission? Yes: continue; No: Access rejected and security event logged.
- The action allowed by their role is logged
Personal accounts versus shared accounts
The problem that RBAC solves in practice is the shared account: a settings-level password known to all engineers, contractors included, the same on every relay in the fleet. With it you do not know who changed a setting, and withdrawing access from one person means changing the password on every device.
Grid cybersecurity frameworks, such as NERC CIP and the cybersecurity guides of national grid operators, ask you to review the access and privileges of all accounts and roles at least once a year, block access promptly after a termination, revoke accounts, and change shared passwords known to the person who leaves or changes role. When a device does not allow a shared account to be blocked, they ask you to document it with your risk analysis and compensating controls. With central RBAC, those obligations are met by deactivating a person in one place. The same goes for contractors who come in through remote access: one account per person, with just the role needed for their task. Account management (one per person, roles, rotation and removal) is detailed in IED Accounts and Passwords.
Relationship with IEEE 1686 and IEC 62443
IEEE 1686 sets the access control, audit and alarm capabilities an IED must have; IEC 62351-8 sets how roles are represented and transported so that different manufacturers and central systems understand each other. In IEC 62443, identification and authentication and use control are two of the seven foundational requirements, and the mapping of permissions to roles appears among the capabilities of an SL 2 component. All three point to the same result: every action on a relay attributable to a person who has permission to do it.
What to check when implementing it
- Real support in each IED: which token profiles it accepts, how many roles and permissions it admits and whether it allows custom roles.
- Identity infrastructure available: directory, RADIUS server or certificate authority, and how communication with it is protected.
- Time synchronization, because the validity of tokens and certificates depends on the time.
- Local emergency accounts for when the central server does not respond, with their control and logging.
- Security event logging sent to a central server.
- Tests at commissioning: each role can only do what it has been assigned.
The access levels that the most common relays have today are in access levels and passwords of relays, and the rest of the secure configuration of each device (ports, services, logs and baseline) in hardening relays, switches and IEDs.
We configure accounts and roles on your relays
Our team configures the access levels, accounts and roles of your relays, reclosers and controllers, and documents who can do what. We do it remotely with remote relay configuration, with sessions that you authorize and that are logged, or on site with our substation and plant cybersecurity service, in substations and industry in Colombia, or elsewhere on request. Tell us the make and model through the contact page.
Related guides
- IEC 62351: cybersecurity for IEC 61850, 104 and DNP3
- Access levels and passwords of protective relays
- IEEE 1686: cybersecurity requirements for IEDs
- Secure remote access to relays and substations
- Is remote relay configuration secure?
- Substation and plant cybersecurity: standards and map
- Hardening relays, switches and IEDs: controls
- CNO Agreement 1960: cybersecurity guide for the Colombian grid
- RADIUS and 802.1X: Authenticating Devices on the OT Network
- IED Accounts and Passwords: Roles and Rotation
References
- IEC 62351-8:2026, ed. 2.0, Power systems management and associated information exchange – Data and communications security – Part 8: Role-based access control for power system management.
- IEEE 1686-2022, Standard for Intelligent Electronic Devices Cybersecurity Capabilities.
- IEC 62443-4-2:2019, technical security requirements for IACS components.
Frequently asked questions
What is the difference between a relay's access levels and the RBAC of IEC 62351-8?
Traditional access levels are usually passwords per level, the same for everyone who knows them. IEC 62351-8 ties permissions to roles and roles to identified people, with tokens that expire and are managed from a central server, so you know who did each action and an access can be withdrawn without changing everyone's password.
Can I use IEC 62351-8 if my relays do not support it?
Not on those devices, but you can approach its principles: personal accounts where the relay supports them, centralized authentication on the devices that support it, access through a jump server with per-person accounts and logging, and changing shared passwords when someone no longer needs access.
What happens if the central authentication server is not available?
It depends on the profile. With self-contained tokens, such as certificates, the device can verify the token locally. With profiles that query a central repository, the design must foresee which local emergency accounts exist, how they are protected and how their use is logged.