IEC 62541 · Utility

Part 18: Role-Based Security

Document number	OPC 10000-18
IEC designation	IEC 62541-18
Colloquially	Part 18
Group	Utility

Roles are nodes

A server publishes a role set under its ServerCapabilities, with one object per role. Well-known roles are defined so that tools and specifications have a shared vocabulary: Anonymous, AuthenticatedUser, Observer, Operator, Engineer, Supervisor, ConfigureAdmin and SecurityAdmin. Because roles are nodes, a suitably privileged client can browse the role set, see which identities map to which role, and - where the server permits it - change the mapping over OPC UA rather than through a vendor configuration tool.

Identity mapping rules

Each role carries a list of criteria that grant it. A criterion can match a specific user name, an operating-system or directory group, a claim from an issued token, the thumbprint of a user certificate, a subject field from that certificate, or the blanket cases of anonymous and any authenticated user. A role can additionally be restricted to particular applications or particular endpoints, so a role granted over an encrypted endpoint need not be granted over an unencrypted one.

Permissions land on nodes

The enforcement attributes are defined in Part 3 and filled in according to Part 18. RolePermissions on a node is the full table of what each role may do with it - read, write, browse, call, receive events, insert or modify history, and more. UserRolePermissions is the same table reduced to the roles the current session actually holds, which is what a client should read to decide whether to grey out a control. Where a node carries no permissions of its own, the default permissions declared on its namespace metadata apply.

Access restrictions are a separate axis

Alongside permissions, a node can carry access restrictions requiring that the session be signed, encrypted, or authenticated by a trusted application. These are checked regardless of role, so a node the user is fully entitled to read can still be refused because the channel is only signed and the node demands encryption. This is deliberate - it lets a model mark a subset of nodes as requiring a stronger channel - and it produces errors that look like a permissions problem when they are a transport problem.

What it defines

Concept	What it is
RoleSet	The object under ServerCapabilities holding one node per role. Browsable, and the honest way to find out what authorisation a server actually implements.
Well-known roles	Anonymous, AuthenticatedUser, Observer, Operator, Engineer, Supervisor, ConfigureAdmin, SecurityAdmin. Shared names, not shared behaviour.
Identity mapping rules	The criteria that grant a role: user name, group, token claim, certificate thumbprint or subject, plus the anonymous and authenticated-user cases.
Application and endpoint restrictions	Limit a role to named applications or endpoints, so the same user gets different authority depending on how they connected.
Role administration methods	Where the server allows it, methods to add and remove identities, applications and endpoints on a role, performed over OPC UA and expected to be audited.
RolePermissions	The per-node permission table by role: browse, read, write, read and modify history, call, receive events, add and remove references, and node management.
UserRolePermissions	The same table filtered to the current session's roles. This is the attribute a client should read before enabling a write control.
Default role permissions	Declared on a namespace's metadata and applied to nodes that carry none of their own. A namespace with no defaults set is a permissive namespace.
AccessRestrictions	Per-node requirements for signing, encryption or a trusted application, checked independently of role. Refuses access over a channel that is too weak.
TrustedApplication role	A well-known role for a peer that authenticated with a trusted application instance certificate, letting a server distinguish a known application from an arbitrary one.

Do you need to read it?

Anyone hardening a server beyond anonymous read, and anyone whose client has to behave correctly for different logins. It also matters to whoever writes the security requirement: asking for role-based access control per Part 18 with a named role-to-permission matrix is testable, where asking for user authentication is not.

Traps that trace back to this part

• The well-known role names are vocabulary, not semantics. What Operator may actually do is per-server configuration, so the same login can write setpoints on one server and be read-only on the next. Never infer permissions from a role name; read UserRolePermissions.
• A node with no RolePermissions inherits its namespace default, and a namespace with no default set is effectively open to whoever passed authentication. Locking down a server means setting namespace defaults and then relaxing them, not tightening individual nodes from a permissive baseline.
• AccessRestrictions produce authorisation-looking errors from a transport cause. A node requiring encryption returns an access failure on a Sign-only channel for a user with every permission, and the message rarely says so. When a permission looks correct and access is still refused, check the node's restrictions and the channel's security mode.
• Role-based security is only as good as the authentication under it. Roles mapped to user names on a server that also accepts anonymous access, or that accepts credentials on a MessageSecurityMode.None endpoint, are decorative. Close the endpoint before configuring the matrix.

Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.